What order should you build an app in?

Data model first, then authentication, then everything else. The database schema and the auth model are the two decisions that are expensive to reverse once real users exist, because both of them contaminate every table and every endpoint you add afterwards. Frontend feels like the natural starting point because it is the part you can see, but it is also the cheapest layer to change later. Build the things you cannot easily undo before the things you can.

Do I need all 13 layers before launching?

No, but two of them are non-negotiable: server-side authorization checks and data isolation between accounts. Ship without those and you do not have a small problem, you have a breach waiting for its first curious user. The other eleven layers can be staged — you can launch with basic logging and add proper error tracking in month two — as long as the staging is a decision you made rather than a gap you did not notice.

Is an app built with AI tools less production-ready?

Not inherently. AI coding tools build exactly what you describe, and they describe the visible half of an application extremely well. What they do not do is volunteer the parts nobody asked for — rate limits, row-level isolation, backup restores, structured logs. The gap is not quality, it is scope. If you never asked for a layer, it is not there, and the app will look finished right up until the moment it meets real traffic.

How do I know if I built it correctly?

That is the honest limit of any standard, including this one. You can follow all 13 layers carefully and still miss the thing you did not know to look for, because the failure modes are invisible from the inside. A standard you grade yourself against is a standard you pass. Independent verification is the only way to find the gap between what you believe you built and what actually deploys.

What does it cost to build to this standard?

Building to it yourself costs time rather than money — the layers are documented here specifically so a capable builder can follow them. If you would rather hand it off, a build scoping call establishes the shape and price against your actual requirements. If the app already exists and you want to know where it stands, the Launch-Ready Audit is a fixed $5,000 and returns a scored 13-layer report with prioritized fixes.

The Standard · Build Phase

Most AI-built apps break in the same 13 places. Build for them from day one.

The 13-layer standard for building an app that survives real users. AI coding tools closed the fun half of building software — the half you can see, demo, and feel proud of. The load-bearing half sits exactly where it always did, and it is not hiding anywhere clever. It hides in thirteen specific places, and this page names all of them.

Book a build scoping call

Section 01 · Why This Page Exists

The problem was never the code you can see

Something genuinely good happened in the last two years. A person with a clear idea and no engineering team can now describe an application and watch it appear. That is not a lesser way to build; it is the biggest expansion of who gets to build anything since the spreadsheet.

But describing an app produces the parts you thought to describe. Nobody sits down and says "and add rate limiting, and isolate tenant data at the database layer, and give me a tested restore path for the backups." Those parts were never invisible to engineers — they were just never the interesting part, so they lived in the tacit knowledge of people who had been burned before.

So the app looks finished. It demos beautifully. It works on your laptop, and it works for the first ten users, because ten users do not probe. It breaks the first time it meets people who did not build it, and it breaks in a specific and predictable set of places.

This page is the build-phase standard. Not a checklist of what to verify after the fact, but the thirteen layers to build into an application while it is still cheap to do so, and the one decision that actually defines each layer. If you want to know how the app you already have measures up, that is a different question and there is a separate audit for it.

Section 02 · The Standard

The 13 layers, in order

Each layer below gets three things: what it actually is, what happens when you skip it, and the single decision that defines it. The decisions matter more than the tutorials — you can look up how to configure anything, but choosing wrong at the start costs you a rebuild.

Frontend Foundations

What users touch. Skip it and you get an interface that works on your machine and falls apart on a three-year-old Android on a hotel connection. The defining decision: whether your content exists in the HTML or only after JavaScript runs — because that single choice determines who can read your app, including search engines and AI assistants.

APIs & Backend Logic

The rules of your business, expressed as code the client cannot edit. Skip it and your validation lives in the browser, where anyone can turn it off. The defining decision: what the server refuses to trust from the client — which should be everything, including the user's own claim about who they are.

Database & Storage

Where the truth lives. Skip it and you discover in month six that a core relationship was modelled wrong and every feature since has been built on the mistake. The defining decision: your schema, made before the first feature — because it is the single most expensive thing on this list to change once real data exists.

Auth & Permissions

Who someone is, and what they may do. Skip it and every endpoint is public to anyone who reads your network tab. The defining decision: whether authorization is checked on the server for every request, or merely reflected in what the interface chooses to display. Hiding a button is not a permission model.

Hosting & Deployment

How code gets from your machine to the world. Skip it and deployment is a ritual only you can perform, at a keyboard only you have. The defining decision: whether a deploy is reversible in one step — because the question is never whether you will ship something broken, only how fast you can take it back.

Cloud & Compute

What you rent, and what it costs. Skip it and the bill arrives with a number you cannot explain and cannot attribute. The defining decision: which resources scale with usage and which are fixed — this is an architecture choice long before it is a finance one, and it is set on day one whether you intend it or not.

CI/CD & Version Control

The path from change to production, and the history of every change. Skip it and there is no way back to the version that worked. The defining decision: what must pass before code can deploy — even one automated check turns "I hope this works" into a gate.

Security & Row-Level Isolation

The wall between one customer's data and another's. Skip it and a curious user changing a number in a URL sees somebody else's records. The defining decision: whether isolation is enforced by the database itself or by remembering to add a filter to every query — because the second approach fails the first time somebody forgets.

Rate Limiting

A ceiling on how fast anyone can hit you. Skip it and one script, or one bad loop in your own code, can exhaust the service for everyone. The defining decision: what a legitimate maximum looks like per user and per endpoint — set deliberately, not discovered during an incident.

Caching & CDN

Not recomputing what has not changed. Skip it and every visitor pays the full cost of every page, and so do you. The defining decision: what is allowed to be stale and for how long — a product judgement about freshness, not a technical setting.

Load Balancing & Scaling

Surviving more traffic than you planned for. Skip it and your best day becomes your outage. The defining decision: whether any single request can be handled by any instance — statelessness is what makes scaling a slider instead of a rewrite.

Error Tracking & Logs

Knowing something broke without a customer telling you. Skip it and your monitoring system is an email from an annoyed user. The defining decision: what gets recorded on every request so a failure can be reconstructed later — and, just as importantly, what must never be written to a log.

Availability & Recovery

Getting back after the worst day. Skip it and you have backups you have never restored, which is the same as having none. The defining decision: your acceptable data loss and downtime, stated in hours, before you need them — because that number determines the entire design and nobody chooses it calmly at 3am.

Section 03 · The Two Non-Negotiables

Eleven can wait. Two cannot.

Most of this standard can be staged. You can launch with basic logging and add proper error tracking in month two. You can run on one instance until one instance genuinely stops being enough. Staging a layer is a legitimate decision as long as it is a decision, rather than a gap nobody noticed.

Two layers are different, and they block launch on their own:

Layer 4 — server-side authorization. Every request that returns or changes data must confirm, on the server, that this specific user is allowed to do this specific thing. An interface that hides options from the wrong user is a courtesy, not a control.
Layer 8 — data isolation between accounts. One customer must never be able to reach another's records by changing an identifier. If that protection lives in application code rather than in the database, it holds only until one query forgets its filter.

These two are not on the list because they are the most technical. They are here because they are the two failures that cannot be walked back. Every other layer on this page fails in a way that costs you money, time, or reputation. These two fail in a way that costs your customers their data, and no apology recovers it.

Section 04 · Sequencing

Build the things you cannot undo first

The instinct is to start with the interface, because it is the part you can see and show people. It is also the cheapest layer on this list to change later — a redesign is a weekend, and it touches nothing underneath.

The schema is the opposite. Get the data model wrong and every feature built on top of it inherits the mistake, so the cost of fixing it grows with every week of use and every row of real customer data. Authentication is nearly as bad, because the permission model contaminates every endpoint added after it.

So the order is not the order of the list. Model the data first. Decide the auth model second. Then build outward toward the parts you can revise cheaply, and stage the operational layers deliberately as real usage tells you which ones you actually need next.

A practical way to stage the rest: let real usage pull each layer forward rather than guessing. Caching becomes urgent when a page gets slow enough that you notice, not before. Rate limiting becomes urgent the first time you see a request pattern that is obviously not a person. Load balancing becomes urgent when one instance is genuinely saturated, which for most applications is much later than the owner assumes. The trap is not launching without these — it is launching without knowing which ones you launched without.

Write that list down. The gap between "we deferred rate limiting deliberately" and "nobody thought about rate limiting" is invisible in the code and decisive in an incident, and the only artefact that distinguishes them is a note you wrote at the time.

Deep-dives on each layer group publish to Field Notes as the cluster fills out, starting with sequencing and the database decision.

Section 05 · What Next

Two honest options from here

Verify it

The Launch-Ready Audit

You can follow this standard. You cannot grade your own work — a standard you self-assess is a standard you pass. Thirteen layers, independently scored, with prioritized fixes. $5,000, and $2,000 of it credits toward the repair work if you want us to do it.

Hand it off

Book a build scoping call

Have us build it to this standard from the start, rather than fixing it against the standard afterwards. Scope and price are set against your actual requirements on the call — there is no package to buy off this page.

Publishing the standard we charge to verify is deliberate. A builder who reads all thirteen layers honestly is a builder who can tell whether they need us — and that is a better conversation than one that starts with a sales pitch.