Custom App, API Integration or AI Workflow: What Should You Build First?
Start with one task your team needs to do better. Describe its input, the person doing the work and the result they need. Then choose whether the gap calls for an existing tool, an integration, a custom app or an AI workflow.
A useful first build ends with a decision: use it with a small group, improve a specific weakness or stop. The following examples are proposed scopes, not measured customer results.
Check what your existing tools can do
Before commissioning software, try the relevant settings, exports and built-in integrations in the systems you already use. If they cover the workflow and its access rules, configuration may be enough.
Write down the remaining gap. “We copy approved orders into a second system” suggests an integration. “Nobody can see which requests need approval” suggests a shared work queue. These are different jobs, even if both start in a spreadsheet.
Three useful first builds
An API integration when people move the same data twice
Problem: approved orders are entered manually into a fulfilment system.
Deliverable: one agreed order flow between two systems, with status tracking and a way to recover failed transfers.
Example acceptance check: an approved test order appears once at the destination; sending the same event again does not create a second order; a failed transfer stays visible for recovery.
Scope boundary: name the systems, fields and event types. Historical migration and additional connectors need their own scope.
An internal app when work needs a shared place
Problem: requests, assignments and approvals are spread across messages and spreadsheets.
Deliverable: one queue where agreed user roles can create, assign, review and export a request.
Example acceptance check: a pilot user completes the agreed journey, a reviewer sees its history and a user without permission cannot approve it.
Scope boundary: agree the roles, screens and deployment environment. A prototype using sample data does not establish production readiness.
An AI workflow when text needs interpretation
Problem: someone reads incoming documents and prepares structured information for review.
Deliverable: a draft extraction or classification, its source material and a review step before any consequential action.
Example acceptance check: compare outputs against reviewer-labelled examples held back from development, report errors and check that missing information reaches the reviewer.
Scope boundary: agree supported formats, languages, data handling and evaluation limits. Do not treat a model's own confidence score as proof of correctness.
Keep the first version simple enough to assess
If the steps are known, start with an explicit workflow. Add autonomous decisions only where the task needs them and the evaluation can test them. Anthropic's engineering guidance also recommends starting with the simplest workable approach before adding agent complexity. Read the guidance.
Our scoping recommendation is to include the main failure and permission checks in the first slice. They help a reviewer judge whether the approach fits everyday work, beyond the successful demonstration.
Choose the next step from what you know
The bottleneck is unclear: map the workflow before choosing a build.
The idea is clear but the result is uncertain: use a paid PoC to test one question with agreed data.
You already have evidence and pilot users: scope the smallest usable app or integration, including its operating requirements.
Prepare the owner, representative examples, access status and a description of the current process. Mark unknowns explicitly. Use the one-page AI PoC brief and agree acceptance criteria before implementation.
Compare the fixed-scope packages to find a starting point for that decision.