A demo has a small job: show that an idea could work. A product has a much longer job: keep working when the person who built the demo is no longer in the room.

I care about that second job. A screen that looks finished can still leave a lot of unfinished work behind it.

Imagine a generated app with a convincing dashboard. The buttons work with the sample data. The chart looks good. Then you try to use it with your own account, on a different machine, or a week later. Those are different questions from whether the first screen looks right.

Here are four questions I would ask before treating that preview as a product.

Can someone else run it?

Source code matters, but a folder of files is only a starting point. The next person needs to know how to install it, which configuration it expects, and how to start it without guessing.

If it needs a database, the setup needs to explain how the data structure gets created. If it needs a service account, the instructions need to say which one and why. Credentials belong in the environment, not in the repository or an example screenshot.

A short, accurate setup guide makes that handover easier to check.

What happens when the happy path ends?

Try an empty list. Try a failed request. Try leaving halfway through an operation and coming back. Try using the page with a keyboard.

None of those situations is exotic. They are part of using software. A useful error message tells someone what happened and what they can do next. A button should not report success before the action has actually succeeded.

The preview should make these limits visible enough to evaluate.

Can the work be changed?

The important test is a modest change: rename a field, alter a rule, add a page. Can someone follow the code well enough to do it? Can they check that they have not broken the existing behaviour?

This does not require a perfect architecture. It requires enough structure, explanation and checks for the next decision to be manageable.

A product will change. The handover should make that possible.

What has actually been checked?

“Tested” is a very small word for a very large claim.

A successful build answers one question. A browser check answers another. A successful deployment answers another. I want to know which checks were performed and what they establish.

I also want to know what remains uncertain. A useful release note can say that a flow was checked on a particular device and that another environment has not been tried yet. That gives the next person something to work with.

The work I want to put my name on

I’m building Tervane, an AI SaaS builder. Its public site is currently in a coming-soon phase. These questions describe the standard I want to work toward; they are not a claim that every part of the product is finished.

I want to build things people can use, explain the decisions behind them, and be clear about what still needs work.

The demo is useful. What happens next deserves just as much attention.