Going live is the hard part
AI writes the first 90% fast. The last 10% — payments that fail, forms that swallow leads, backups nobody has restored — is where projects quietly die.
There is a lot of writing about building with AI assistants. Almost none about the part that decides whether the thing survives: putting it in front of real people and keeping it alive on a Tuesday when something breaks.
The first 90% arrives faster than it used to. The last 10% costs exactly what it always did.
A demo working is not the same as it working
Here is a failure I have shipped myself, and it is worth describing because it is invisible.
A contact form posts to an endpoint that writes the enquiry to a file. On my machine it works perfectly. Deployed to a typical serverless host, the filesystem is read-only. The write fails, the endpoint shrugs, the visitor sees "thanks, I'll be in touch" — and the enquiry never existed.
Nothing errors. No alert fires. You find out weeks later, if ever, when you wonder why the site never brings anything in.
That is the shape of production bugs: not a crash, a silence. A crash you fix on Tuesday. A silence you discover in November.
Money is where silence costs the most
The worst one I have had to fix: a card is declined, the customer tries again, the second attempt succeeds — and the order is never created. The business has the money. The customer has nothing. Neither side notices until someone turns up expecting what they paid for.
It happened because the happy path was tested thoroughly and the failure path was not tested at all. Declined cards, double submissions, a customer closing the tab mid-payment, a webhook arriving twice: those are not edge cases in a product that takes money. They are Tuesday.
So now the rule is: anything touching payments gets its failure paths tested before its happy path gets praised. And when a payment mechanism breaks, it must break closed — refuse, and say so — never take the money and stay quiet.
Give yourself somewhere to be wrong
You need a place that is a faithful copy of production and costs nothing to break. Not "run it locally" — an environment with the same shape: its own database, its own payment keys in test mode, its own domain.
Two things make it earn its keep:
- Test-mode payment keys, always. The day a staging environment charges a real card is the day you learn this the expensive way.
- Someone who is not you, clicking it. I send builds to a tester who does not know what the app is supposed to do. They find in twenty minutes what I cannot see after three weeks, because I unconsciously avoid the paths I know are fragile.
Decide how you will find out
Before launch, answer one question: when this breaks at 3am, how do I learn about it?
If the answer is "a customer will tell me", you do not have a product yet, you have a hobby. What it takes is unglamorous and takes an afternoon:
- Something that checks every site every few minutes and shouts when one stops answering.
- Certificate expiry watched, because certificates expire on a Sunday.
- Backups of the things that cannot be rebuilt — and here the important part: a backup nobody has ever restored is not a backup, it is a hope. Read the archive back. Mine verifies it can be re-opened before it deletes the previous one.
- An alert that reaches a phone, not a log file nobody opens.
Note what a backup does and does not protect. A copy sitting on the same machine saves you from a bad deploy or a stray rm. It saves you from nothing if the machine itself is gone. Know which one you have.
Write down what actually went live
This one sounds like bureaucracy and it is the cheapest insurance on the list.
After every deploy, note what went out, the commit, and what stayed behind in staging. Because three weeks later someone asks "is this fix in production?" and you will answer from memory — and memory answers wrong with total confidence. Check, do not recall.
Maintenance is a shape, not a mood
Maintenance is not "I'll look at it when it breaks". It is a small, fixed set of things with owners and rhythms:
| What | How often | Why |
|---|---|---|
| Sites answering | Continuously, automated | Downtime nobody sees lasts all weekend |
| Certificates | Automated, with an alert three weeks out | They renew themselves until the day they don't |
| Backups | Daily, verified readable | See above |
| Dependencies | Monthly | Security fixes do not wait for your roadmap |
| What is in production | After every deploy | So the answer is a record, not a guess |
None of it is clever. All of it is the difference between a product and a demo that happens to be on the internet.
What this means if you are hiring
AI-assisted development genuinely compresses the build. What it does not compress is the judgement about what can fail, where money is involved, and who gets woken up. When you are choosing who builds something for you, that is the part worth asking about — not which model they use.
Ask what happens when a payment fails halfway. Ask where the backups go and when they were last restored. Ask how they find out the site is down.
If you want that kind of delivery on something you are planning, try the indicative quote check or tell me what you need.