The app is the easy part now. A capable person with no engineering background can build something useful in a weekend, and it will look finished. What the tools do nothing for is everything around it: where it runs, who can get in, what happens to the data, how anyone knows it is working, and what happens when the builder is not there.
This is the checklist for that. Use it two ways: as the builder, it is the homework to do before the business relies on the thing; as the person deciding, it is the questions to ask before saying yes. Every section ends with a plain “done looks like”, so neither side has to guess. Click any item for the detail.
1. Where it runs
Hosting under a company account. Not a personal one.
The company can log in without the builder, and billing goes to the company.
Separate environments. One to try changes in, one the business uses.
Nothing is tried on the live one.
A written note of what is where.
The hosting provider, the database, the domain, any third-party services, each with the account it lives under.
Done looks like: a one-page list of services and accounts, and a second person who has logged into each.
2. Who can get in
Access that survives departure.
Every account has at least two people with access, or is owned by a company identity that can be handed over.
Secrets outside the code.
Passwords, keys and tokens live in the hosting platform’s secret store or a password manager. Never in the source, never in a chat.
The rule about who sees what, written down.
Which users, screens and automations can reach which records. Enforced as close to the data as possible, so a new screen cannot forget it.
Done looks like: the builder can name where every secret lives, and can explain in one sentence where the “who can see what” rule is enforced.
3. What happens to the data
A backup that exists, and a restore that has been tried.
A backup nobody has restored from is a hope. Try one, on the non-live environment, and write down how long it took.
A data inventory.
Which customer, staff or financial data the app holds, and whether any of it goes to an AI model, and under what agreement.
Retention.
How long it is kept, and how it is deleted.
Done looks like: a dated note saying “restore tested on this date, took this long”, and a half-page inventory.
4. Tested by someone else
Not the builder.
A second person checks the app against what the business asked for, not what the builder thinks it does.
The cases that matter, written down.
The refund. The end of the month. The customer with two accounts. The empty list. The person who is not allowed to see the record. Each one tried, each result recorded.
A way to re-run them.
If the app changes, the same cases get tried again. Automated where the builder can manage it, a written script where they cannot.
Done looks like: a list of cases with a tick and a date beside each, and a second name on it.
5. Reviewed for security before it touches real data
The mistakes AI-built applications make are specific and repeatable. Before the app touches real data, check these, in this order:
- Can anything be reached without signing in?
- Given a signed-in user, can they reach a record that is not theirs by changing an id in the address?
- Does the app fetch anything from a web address a user can influence?
- What happens when a setting or secret is missing: does the app refuse, or carry on?
- Is anything secret shown to the browser or written to a log?
- Does any part of the app connect with a privileged account that bypasses the “who can see what” rule?
Then a scheduled pass afterwards.
A scan on every change, a regular check of the database’s own configuration, dependencies matched against known vulnerabilities, findings turned into fixes a person reviews. For anything handling money or personal data, independent human testing at least annually.
Done looks like: six written answers, a date for the next scan, and the name of the person who reviews findings.
6. Something watching it
Checks on the figures the business relies on.
Statements that must always be true, checked on real data: totals equal the sum of their parts, a status cannot be skipped, no record points at another customer’s data. When one fails, someone is told the same day. Log and continue; never block the user.
Errors tagged with the version.
Every error carries the version of the app that produced it, so “when did this start” is a minute’s work.
Someone who receives the alerts.
A named person, and a rule for what happens when they are away.
Done looks like: three to five written checks, running; a place errors go; a name.
7. It can be kept running without the builder
A handover document. Two pages, written now, not when the builder resigns.
What the app does, where everything is (section 1), how to make a change safely, how to run the tests (section 4), what the alerts mean (section 6).
A maintenance rhythm.
Dependencies updated on a schedule. The security pass running. Someone responsible for whether it is working, by name.
A rule for changes.
No change goes to the live environment without the tests being re-run and a second person knowing.
An instructions file for the codebase, not just the app.
Separate from the handover document: a short file, under two hundred lines, that states how this codebase is actually built. Conventions, where business rules live, what never goes in a commit. If an AI coding tool wrote any of this, that file is what makes the next session follow the same conventions instead of inventing new ones.
Done looks like: a second person has made a small change to the app using only the handover document.
8. The lesson gets kept
Every one of the above will teach the company something: a hosting quirk, a test that caught a real problem, a security finding. Write each down, once, somewhere every future project starts by reading. That is the difference between doing this homework once and doing it every time.
Done looks like: a shared place for notes, with the first three notes in it.
For the leader
You do not need to check the work. You need to ask for the eight “done looks like” items and see them.
- All eight shown: let the business rely on the app.
- Four shown: it is a prototype. Treat it as one until the rest is done.
The homework is a week or two of part-time effort for a capable builder, and it is the cheapest insurance the company will buy this year.
Changelog
- 2026-09-05: first version.
- 2026-09-05: section 7 adds the codebase instructions file, distinct from the handover document, for anything AI-built.
- 2026-09-08: checklist items collapsed to their one-liners, with the detail a click away; short version added.