2690 field guide

From AI prototype to app the team can depend on

The checks and ownership decisions that matter after a promising demo.

An AI-built app can show that an idea is possible. Team use asks a different question: can people rely on it when inputs are messy, access changes, a dependency fails, or the original builder is unavailable?

Define the job and the failure cost

Write down the core task, expected result, and how a person knows it is correct. Then ask what happens if the app is unavailable or wrong. An internal draft helper and an app that changes orders have different acceptance thresholds.

Inspect what the demo hides

Review where credentials live, who can see data, which external services it uses, how changes are deployed, and what is logged when something fails. Check whether the app handles duplicate requests, missing inputs, permission changes, and slow or unavailable integrations. A happy-path demo does not answer those questions.

Agree on observable checks

Use real tasks and representative exceptions. Can a teammate complete the job without the builder sitting beside them? Can an owner tell whether the app succeeded? Can they undo or recover from a failed update? Record the result of each check before declaring the app ready.

Give the team a way to run it

The team needs the source code and a way to run, update, and recover the application. Name who owns access, who receives alerts, who approves changes, and where issues are reported. Practice a small change and one recovery path with the new owner.

Some prototypes need focused fixes. Others are better rebuilt around the learned job. The first review should make that choice explicit before a quote or schedule is promised.