The prototype works. That's where the questions start.

1. Where does this actually live?

Right now it probably lives in one place: your laptop, or the tool you built it in. "Live" means somewhere it keeps running when your laptop is closed, at an address people can reach, that comes back on its own if it falls over. Hosting, a domain, and a separate copy for testing so you're not editing the thing people are using. The gap between "it runs" and "it stays up" is most of the work nobody sees.

2. Where does the data go?

Every app that remembers anything is writing it down somewhere. The question is where, who else can read it, and what happens the day that place goes away. If the answer is "I'm not sure," that's the honest and common answer, and it's the first thing worth making sure of, because a backup you didn't set up is a backup you don't have.

3. Who can get in?

Logins, roles, and the keys your app uses to talk to other services. This is the thing AI-generated code most often gets quietly wrong: a key left in the open, a page that was supposed to need a password and doesn't, an admin function anyone can reach if they know the address. None of it shows up while you're testing, because you're the only one there.

4. Is it safe for real people's information?

The moment a real person's name, email, or donation goes into your tool, you've taken on a responsibility your board and your auditor will eventually ask about. You don't need to become an expert. You need to know what you're storing, where, and be able to answer the questions before someone asks them under pressure.

5. What does it cost when it works?

Prototypes are cheap because almost nobody uses them. The bill arrives with the tenth user, or the day something loops and calls the model a thousand times. It's worth knowing, roughly, what a busy month costs before you have one, and putting a ceiling on the parts that could run away.

6. What happens when it breaks and the AI can't fix it?

At some point the model will hand you something that doesn't work and confidently tell you it does, or you'll hit a wall it keeps walking you in a circle around. The useful skill is telling "the model is confused" apart from "the system is actually broken," because they need completely different responses, and it's hard to tell from the inside.

7. Can anyone but you run it?

The one a builder feels most and says least. If the tool is you, then your holiday, your sick day, or your attention moving to the next thing is a single point of failure. Handoff isn't a document you write at the end. It's a handful of choices made along the way that decide whether your team inherits something they can run, or something only you understand.

How I'd check yours

Send me what you've built. I go through it and hand back a plain-language write-up: what's solid, what will bite you, and what to fix first, in order. Fixed price, clear start and end, no obligation after. You keep building. I just make sure it holds.

I answer these questions for a living. On my current engagement that has meant sandboxed execution so untrusted code can't reach anything it shouldn't, per-user cost tracking, defences against prompt injection with tests behind them, and moving a live platform onto proper cloud infrastructure without losing a thing.