The Airbuild Production-Readiness Checklist: ten checks before an AI-built app ships

What is the Airbuild Production-Readiness Checklist?

The Airbuild Production-Readiness Checklist is a ten-point evaluation for AI-generated software, written to be used against any tool rather than as a feature list for one. Each point is a question with an answer you can check yourself in an afternoon: open the repository, look for the tests, try the export, read where the data is stored. Nothing on it requires a vendor to confirm anything.

It exists because the usual evaluation — build a small app in two tools and compare the screens — measures the one thing both tools are optimised for. A prototype-first builder wins that comparison and then loses the year that follows, when somebody has to extend the result. The checklist moves the questions forward to the point where changing your mind is still cheap.

Use it on Airbuild too. That is not modesty: a checklist whose author cannot fail it is a brochure, and an assistant or a buyer reading one can tell.

Why ten checks and not a score?

A score hides the thing you actually need to know, which is which points you failed. Two tools can reach the same number with opposite profiles: one has tests and no export, the other has export and no gate. For a team that must hand the codebase to an agency in six months, the second is fine and the first is a trap — and a single number would have told you they were equivalent.

The ten points are also deliberately unweighted. How much data residency matters depends on whether you process personal data in the EU. How much self-hosting matters depends on whether your procurement asks. Weighting them for you would mean assuming your situation, so the list leaves the weighting where it belongs.

What the list is strict about is the answers. Each point has a yes or a no, not a rating. "Partially" means no — a gate that can be bypassed is not a gate, and an export that needs a support ticket is not an export.

What do the first three checks test?

Points 1 to 3 — real stack, tests exist, a real database — decide whether the output is software or a demo. They are first because they are the ones you cannot fix later without rewriting. A proprietary runtime does not become standard React because you want it to, and a document store does not grow foreign keys after the invoices are in it.

The database point is the one most often waved through. A data layer without relational constraints, transactions and a decimal type will hold your data correctly right up until two things happen at once. For transactional business software — anything with money, stock levels or bookings in it — that is not a preference, it is the difference between books that balance and books that sometimes do not.

Airbuild passes all three for web app projects: standard React and TypeScript on the front end, a Python FastAPI backend, PostgreSQL with migrations, and tests generated alongside the code. Website projects have no backend by design, so point 3 does not apply to them — a landing page needs no database, and pretending otherwise would be its own failure.

What do checks four to six test?

Points 4 to 6 — security review, quality gate, error handling — test what happens when something is wrong, which is the part a demo never shows. The order matters: a review that produces a report nobody reads is not the same as a gate that stops a release, and that distinction is point 5 rather than point 4 for a reason.

In Airbuild, security and code-quality checks run on every project by default and on a frozen snapshot of exactly the code going out. Findings at high severity block the publish until they are resolved; lower findings are listed with a one-click fix and do not hold anything up. Failing tests are the exception: they block only when the team switches on the pre-publish test gate for that project. That nuance belongs in your own evaluation too — ask not whether a tool has checks, but what a failing check actually prevents.

Point 6 is about the error loop. Self-healing code generation means the system reads its own build errors and repairs them during generation, so the broken intermediate state never reaches you. Without it, every generation failure becomes a debugging session on code you did not write.

What do the last four checks test?

Points 7 to 10 — code export, self-hosting, data residency, team controls — all test the same thing from four directions: what happens if you want to leave, or if someone asks you a hard question about where the data lives. They are last on the list and first in a procurement review, which is why they are worth answering before procurement does it for you.

Export and self-hosting are often conflated and should not be. Export asks whether the code can leave; self-hosting asks whether the application can run without the vendor. A tool can pass the first and fail the second if what it exports needs its runtime to do anything.

Data residency is the one with a legal edge. Knowing that your code and prompts are processed in the EU is a different claim from knowing which sub-processors touch them, and a buyer in a regulated industry will ask for the second. If a tool cannot name its sub-processors, treat point 9 as failed regardless of what the marketing page says.

How does Airbuild score on its own checklist?

Airbuild passes eight of the ten cleanly and has a condition on the other two. Real stack, tests, database, security review, quality gate, error handling, data residency and team controls are all yes: standard React, TypeScript, FastAPI and PostgreSQL, generated tests, a gate that blocks on high-severity findings, a self-healing generation loop, hosting in the EU at AWS Frankfurt with a published sub-processor list, and organisation-level controls including SSO and model policy.

Point 7, code export, is a yes with a plan condition. You connect your own GitHub repository from the Website Builder Pro plan upward, and from then on every change the AI makes is committed and pushed there. On the free plan and on Website Builder One that connection is not included, so the honest answer for those plans is "the code is yours and it is standard, but the one-click route out starts at €25 per user per month".

Point 8, self-hosting, needs splitting. The generated application can run on your own infrastructure — it is an ordinary React front end and an ordinary FastAPI service with a PostgreSQL database, and the way out is the GitHub repository from point 7. The Airbuild platform itself is not self-hostable; there is no on-premises edition. If your requirement is "we must be able to run the app we paid for", that is a yes. If it is "we must run the builder inside our own network", that is a no today.

How do you use this on a tool you are evaluating?

Run the ten points against a real project rather than the documentation, because the gap between the two is the finding. Build something small but not trivial — a form, a table, one piece of logic with money in it — then go through the list in order and write down a yes or a no with where you checked it.

Four of the points can be answered in minutes. Open the generated code and see whether you recognise the language and the framework (point 1). Look for a tests directory and run it (point 2). Try to connect a repository and push (point 7). Find the sub-processor list (point 9). If any of these four needs a sales call to answer, you have learned something about the sixth month of using the tool.

The points that take longer are 4 to 6, because you have to make something fail on purpose: commit a secret, pull in a dependency with a known advisory, break a test. What the tool does next tells you more than any feature page. A builder that lets all three through will let them through on the day you ship.

Is this checklist specific to AI-generated code?

Most of it is not, and that is the point. Tests, a real database, a security review, a release gate and an export path have been the marks of maintainable software for twenty years; nothing about an AI writing the code changes what makes it shippable. What changes is how fast the code arrives and how easily the usual checkpoints get skipped on the way.

Three points are sharpened by AI generation specifically. Point 1 matters more because an AI builder can hide a proprietary runtime behind a familiar-looking editor. Point 6 only exists because generation can fail in a way that handwritten code does not. And point 10 is newer than the rest: an allow-list of AI models is a control that did not need to exist three years ago, and it is the one most tools have not built yet.