What to build first: the order the 13 layers actually go in

Almost everyone who sits down to build an app starts in the same place: the screen. It's the part you can see, the part you can show a friend, the part that makes the whole thing feel real. It's also, almost every time, the wrong place to start if you care about the right app development order instead of just the most satisfying one.

I get why the instinct is so strong. AI build tools make the interface come together fast — describe a dashboard, watch it render, iterate in minutes. That speed is genuinely useful. But speed on the visible layer creates a kind of gravity that pulls every decision after it into place around a UI that was never meant to be the foundation. By the time the schema gets attention, there are already three screens built assuming a shape the data doesn't actually have.

The 13-layer standard I use to scope and evaluate builds isn't a to-do list you work top to bottom. It's a map of where an app can break, and the order you tackle it in matters as much as whether you eventually cover all thirteen. Get the order wrong and you don't just waste time — you build real cost into decisions you'll have to unwind later, sometimes with production data already sitting inside them.

Start with what you can't undo, not with what you can see. Two layers are expensive to reverse once an app has real users: the database schema, and the authentication and permissions model. Everything else on top of those two inherits their shape. Change the interface and you've spent a weekend. Change the schema after six months of real customer data has accumulated on top of the wrong relationships, and you're migrating live records while trying not to lose anyone's information in the process. That is not a weekend. That is a project with its own risk register.

Auth is nearly as unforgiving, for a different reason. The permission model doesn't just live in one place — it gets referenced by every endpoint you write after it exists. Bolt on "oh, we also need organizations with multiple users" after fifty endpoints assumed one user per account, and you're not adding a feature, you're retrofitting an assumption that's been quietly baked into every query since day one.

So the practical order looks like this: model the data first, before a single screen exists. Decide who a "user" is and what they're allowed to touch second. Only then build outward toward the interface, the APIs connecting it to the data, and the operational layers around all of it — hosting, cost, CI/CD, monitoring, recovery. Those later layers are real and they matter, but they're also the layers you can stage. You can launch with basic logging and upgrade to real error tracking in month two. You cannot launch with the wrong data model and quietly upgrade it later without pain.

Here's the test I actually use when someone asks me to look at a build in progress and tell them if the sequence is sound: I ask what happens if a requirement I know is coming six months out shows up today. If the answer touches the schema or the permission model, that's a signal the foundation was undersized for what the product is actually going to become. If the answer only touches the interface or an operational layer, the order was probably right, because those are the cheap layers to revisit.

The layers that don't get built first aren't optional forever, though — they're staged, and staging only works if it's a decision you made on purpose. Rate limiting becomes urgent the first time a request pattern looks nothing like a person. Caching becomes urgent when a page is slow enough that a user notices before you do. Load balancing becomes urgent when one instance is genuinely saturated, which for most small builds is a lot later than the founder assumes. None of those are failures of the build order — they're failures of not writing down, at the time, which layers you deferred and why. Six months later, "we decided to defer rate limiting" and "nobody thought about rate limiting" produce the exact same code. Only one of them was a decision.

I'll add one caveat, because it matters: staging a layer is not the same thing as skipping the two layers that block launch outright. Server-side authorization and data isolation between accounts aren't things you get to sequence for later — they have to exist before real users touch the app, full stop, because the failure mode isn't slow, it's a breach. The full 13-layer standard walks through why those two sit outside the normal staging logic and what the other eleven look like when you do get to sequence them deliberately.

If you're mid-build right now and something about the order feels off — screens getting built faster than the data model underneath them can support, or auth decisions getting made endpoint by endpoint instead of once, up front — that's usually the earliest and cheapest moment to catch it. Catch the same misordering after launch, once real customer data exists inside the wrong shape, and the fix costs a migration instead of a conversation. The Launch-Ready Audit exists for the after case; a scoping conversation before you're deep into the build is the cheaper version of the same check.

See the full 13-layer build standard →

— Kyle Tysvaer, Founder, Insightful Eye Marketing