The App Works. Who Gets the Call When It Breaks?

The form submits.

The dashboard loads.

A test payment clears.

You send the link to three people and, for the first time, the idea feels like software instead of a note in your phone.

That's a real improvement.

It's also easy to misprice.

Code generation makes the first build cheap.

Once anybody relies on it, that build is a shrinking part of the cost.

Happy path problem

Production asks ruder questions.

Two people edit the same record.

Who can see the admin page?

Can the app survive a failed API call without charging the customer and losing the order?

Then there's the payment webhook. Stripe's docs say it can occasionally deliver the same event more than once, and tell you to log the event IDs you've processed so repeats get skipped.

Whether your generated checkout does that is worth finding out before a customer does.

These are ordinary customer problems.

They just stayed out of the demo.

Generated code can look finished because software shows its happy path and hides its obligations.

Nobody puts "we haven't tested the restore" in the hero banner.

v0's docs give you two routes: deploy to production straight away, or open a pull request so somebody can review it.

GitHub's own guide to reviewing AI-written code says to watch for tests that were deleted or skipped instead of fixed.

Who rotates the key

The owner doesn't have to write every line.

They do need to get a reliable answer when something stops working.

A prompt can explain an alert.

It doesn't decide who rotates a leaked key, whether production data belongs in a test environment, or which customer has to be told about an incident.

That last one has rules in New Zealand. The Privacy Commissioner says a breach that has or might cause serious harm has to be notified, ideally within 72 hours of you knowing about it.

If whoever prompted the app can't judge the output, the work hasn't gone away.

Somebody else inherits it and has to work out why the code exists and where the data can leak.

Expiry dates

Every app inherits a maintenance calendar, and the dates aren't yours.

The model can help with the upgrade. Somebody still has to notice, approve, test and answer for the result.

For a personal tool or a low-risk workflow, the first build may be enough.

I don't want a useful little app turned into an enterprise project either.

Putting a meal planner through enterprise ceremony would bring the old gatekeeping back wearing a security badge.

Risk should set the process. The presence of generated code shouldn't.

So What.

"Can AI build this?" is becoming the easy question.

Before you send the next link, write one name next to it: who gets the call when it breaks. If it's you, write down what you'd do when the phone goes at 11pm.

If nobody owns that, the cheap build is an unusually convincing estimate of work.

Shout out to all the legends I've ripped info from for this piece:

Stripe | v0 | GitHub Docs: reviewing AI-generated code | NZ Privacy Commissioner | GitHub changelog: Spark deprecation