- Choose a complete journey with observable value.
- Separate access, long-running work and business decisions.
- Measure quality and cost per successful task.
An MVP should demonstrate a useful workflow
Anthropic’s March 2026 work on long-running tasks invites examination of how a system preserves context and checks progress. Next.js documentation describes the separation between server and client components. These technical references inform different decisions; neither defines your product architecture by itself.
Start with one user, situation and outcome. For example, a manager receives a dossier, has it analysed and approves a summary. Describe the journey without assuming every step requires AI. This becomes the guiding thread for prototyping and acceptance.
Draw system boundaries
Separate interface, business rules, data access and model calls. Keep secrets on the server. Authorisation should precede resource access; the interface is not a security boundary. For a shared SaaS, explicitly test that one account cannot read another organisation’s data.
Long-running work needs durable state: queued, running, completed or failed. Give the client a reference to retrieve the work. A retry should not create duplicate invoices, messages or operations. Define an idempotency key and expected behaviour after interruption.
Prepare evidence and limits
Build a small set of representative dossiers with expected outcomes and incomplete cases. Evaluate errors, human rework, latency and cost. A useful measure connects spending to an acceptable task, not just a generated response.
Provide understandable behaviour when a model or integration is unavailable. Show actual state and allow controlled recovery. Document retained data, useful retention duration and deletion procedure. A convincing demonstration becomes an operable product when the team can handle these ordinary situations.
Deliver one complete first slice
Limit the first release to what is needed to perform and verify the selected journey: sign-in, input, processing, approval and tracking. Allow time for observing users and correcting issues. A sophisticated dashboard cannot compensate for an essential step that remains manual and invisible.
At the end of the pilot, decide using evidence: extend the test, address a limitation, expand a workflow or stop a direction. Retain volume assumptions and observed costs. Subsequent decisions can then rest on a real baseline rather than the demonstration’s impression.
| Decision | Discovery question | Verification |
|---|---|---|
| Access | Who can read which data? | Test with two organisations |
| Processing | What happens after interruption? | Interrupt and resume |
| Quality | What result is acceptable? | Annotated dossier set |
| Cost | What does an approved task cost? | Observed spending and rework |
Sources & methodology
This insight combines cited publications with editorial analysis. Illustrative examples are not client results. Vendor features and terms may change.