Shipping an AI-built app
Part 1 of 6 in Beyond the Demo.
The useful question about an AI-generated app is not whether it runs once.
It is whether you can close the conversation, come back next week, and still trust it.
Imagine asking an assistant for a release-notes tool. It produces a clean interface. You paste in some changes, generate a summary, and click Publish. The preview looks finished.
Now open it on another device. Ask a teammate to review a draft. Change the layout without losing the releases. Retry a publish that timed out. Find out who approved the announcement that went out yesterday.
Those are not features for some hypothetical enterprise edition. They are what makes this small tool an application instead of a demonstration.
The distinction matters because it changes what we should ask AI to build—and what we should expect a platform to provide.
Start with the thing that has to keep being true
A screen is a poor first specification. It describes how the application looks at one moment, not what it must preserve over time.
For a release-notes tool, the important requirements might be these: drafts remain private until approved; published releases retain the exact approved content; changes survive a redeploy; and a lost response does not cause the same announcement to be sent twice.
Start there. The editor, dashboard, and chat interface are different ways to interact with those commitments.
This also helps keep the build small. You do not need a miniature content-management empire. You need somewhere to save a draft, review a particular version, publish it deliberately, and inspect the outcome.
The same exercise works for a reading log, a club directory, or a household maintenance tracker. What should remain true after you close the browser? After someone else edits the record? After the assistant that created it is no longer involved?
Those answers are the beginning of the architecture.
Separate the conversation from the application
A conversation is useful for expressing intent. It should not be the only place your application's identity or operating instructions exist.
Suppose the assistant needs to remember which deployment is current, which project owns the data, and which command publishes a release. A future conversation should be able to recover those facts from the system. Asking the user to paste an old transcript is not a continuity strategy.
Give the application durable identifiers. Give important work a status that can be retrieved. Keep the authoritative record in storage the application controls, rather than in a generated answer that says the operation probably succeeded.
The practical test is simple: could a different authorized assistant pick up the work without reconstructing the entire conversation?
That does not require preserving every message. It requires preserving the facts that matter.
Ask where each responsibility lives
There are four responsibilities worth naming before you approve a build.
State is the information that must outlive the interface: records, files, ownership, versions, and completed work. Browser-local storage may be sufficient for a disposable personal sketch. It is not interchangeable with shared, authenticated storage. Choose intentionally.
Authority determines who may do what. A private-looking screen is not an access-control system. The server must enforce the rules even when the interface is bypassed. For the release tool, permission to draft should not automatically include permission to publish.
Recovery determines what happens when an operation stops halfway through. Returning an error is useful, but it is not the whole answer. The application needs to distinguish “nothing happened,” “it happened,” and “the outcome is not yet known.”
An exit means understanding what you can take with you. Source code, records, files, and configuration are separate things. An export button deserves more scrutiny than a reassuring label: can you use the exported data somewhere else, and are its relationships preserved?
These are questions to ask of any builder or hosting platform, including OpZero. A platform can supply infrastructure without automatically deciding the correct behavior for your application.
Choose the smallest runtime that fits the job
Not every useful tool needs an autonomous agent.
A public reference page may need only static hosting. A private tracker needs identity and persistence. A specialist assistant needs model access and a defined set of tools. Work that must continue independently of a chat may need durable execution and a scheduler.
Treat those as different requirements, not successive levels of sophistication.
OpZero's documentation distinguishes deployable pages, AI-powered applications, assistants, hosted MCP servers, and gateways. The useful architectural distinction is between a model with instructions and a workflow with its own durable execution. Do not assume the first automatically provides the second.
For the release tool, start with persistent drafts and a deterministic publish operation. Add model-generated summaries because they help with writing. Add scheduled delivery only when someone actually needs it. Do not introduce an agent loop to move a record from draft to published.
A smaller operating model is easier to understand when something fails.
Build the workflow you need, not the subscription you dislike
Replacing a whole commercial product is usually the wrong starting brief.
“Replace our project-management system” inherits years of features, integrations, and expectations. “Collect this week's approved changes and produce a reviewable release note” has a boundary you can test.
A good first build has a narrow audience, a clear owner, and mistakes that are recoverable. It should deliver value before it accumulates a large integration footprint.
There are also good reasons to keep buying software. Someone may need to own support, maintain a regulated workflow, provide specialized integrations, or be available when the system breaks. Generating the initial code does not make those responsibilities disappear.
The useful comparison is not subscription price versus the cost of one prompt. It is the value of a better-fitting workflow versus the cost of operating and maintaining it.
Build when the mismatch is specific enough that a small application can remove it. Keep buying when the surrounding service is most of what you need.
Change the definition of done
For a small private app, a better acceptance conversation sounds like this:
Open the app in a new session and recover the saved records. Show that a different account cannot read them. Change the interface and redeploy without deleting the data. Retry an operation after losing its response. Show the saved result, not just a success message. Export the records and demonstrate what the export contains.
The tests should match the stakes. A personal reading log does not need the same controls as a public publishing service. It still deserves a deliberate answer about where its data lives.
Also distinguish code rollback from data recovery. Republishing an older interface does not necessarily reverse records already changed by newer code. OpZero documents deployment snapshots and rollback in its project concepts; application data and migration behavior still need their own plan.
Describe the outcome—and the obligations
Here is a stronger starting prompt than “build me a release-notes app”:
Build a private release-notes tool for a small team. Members can create and edit drafts; only an owner can publish. Preserve drafts across sessions and redeploys. Approval applies to a specific content version. Publishing must return a durable status that can be checked after a timeout. Start without background agents or external notifications. Explain where identity, data, and publish history live, and demonstrate the access and persistence tests before calling it finished.
This is still a small application. It is simply a more complete description of one.
The promise of building with AI should not be that responsibilities vanish. It should be that more people can express those responsibilities—and get working software that honors them.
The code is the beginning. The application is what keeps working after the conversation ends.
Start with one persistent workflow. The OpZero quickstart covers connecting your assistant and making a first deployment. Bring a description of what must stay true, not just a picture of the screen.
Next in the series: Adding MCP to an existing app.