~12 min read · Every business app is really three apps stacked on top of each other. Most builders only build one of them well. Here's what to look for, why it matters, and how to ask for all three without sounding technical.
The first time someone described an app this way to me, I thought they were trying to sound impressive. Turns out they weren't. They were trying to explain a piece of the engineering that explains everything else.
Here is the idea, in one sentence: every business app is really three apps stacked together, and most of the time you can only see the top one.
The top one is the part you and your users interact with. Screens, buttons, animations, the things that move when you tap them. It's the part you point at when you tell people about your product. It's the part that gets feedback. It's the part that gets redesigned.
Underneath it sits the second app — the one that contains the rules of what your business actually does. Who is allowed to do what. What happens when an order is placed. When a refund is valid. What "active customer" means. When a notification fires.
Almost none of this is visible on a screen, but all of it determines what the screens are allowed to do.
Underneath that sits the third app — the system of record. The durable memory. What actually happened, who it happened to, when, and in what order. The part that has to be right even when the rest of the app changes.
You don't have to know any of this to use an app. But if you're buying one — paying someone to build it, or trying to figure out why the one you have keeps disappointing you — knowing about the three apps changes almost every conversation you have with developers. It changes what you ask for, it changes what you notice, it changes what you accept.
This article is about those three apps: what each one is, why they matter, what happens when one of them is missing, and how to ask for all three without sounding like you've memorized a textbook.
How Most People See an App
The way you see an app is the way an app is designed to be seen. Screens. A logo. A login page. A list of items. A button that says "Buy". A small animation when something works, a red border when something doesn't, etc.
This is not wrong — it's how the app presents itself, and it's how almost every user thinks about it. If asked to describe "the app", most people will describe what they see: the home screen, the cart, the checkout, the profile. These are the things that have names and the things that get changed when someone says "redesign the app".
When a buyer asks for a new feature, they almost always describe it the same way — in terms of screens.
Can we add a screen that shows past orders? Can the profile page have a way to update the address? I want a button on the main screen that takes me directly to support!
The trouble is that what makes a feature work isn't the screen...
The screen is what the user touches. What makes it work is everything underneath the screen — the rules that govern it, the data it depends on, the things that have to happen when the user taps the button.
This is the gap that the three-apps model closes.
The Way an Engineer Sees an App
If you sit a competent software engineer down and ask them to draw your app, they won't draw the home screen. They'll draw three boxes.
The top box is the interface. What the user sees and touches.
The middle box is the rules. The logic that decides what's allowed, what happens when, and in what order.
The bottom box is the data. The system of record. What actually exists. What survives a phone reboot, a server restart, or a year of growth.
These three boxes are not the same thing, and they don't have the same shape. They cost different amounts to build. They change at different speeds. They have different decay rates. They benefit from being separated, and they suffer when they're tangled.
The reason most apps disappoint over time is not that any one of the three boxes was built badly. It's that the boundaries between them were never drawn. The rules are sprinkled inside the screens. The data is whatever the screens happened to save. The system of record exists, but only as a side effect of what the interface did last week.
When the three boxes are separated, each can grow on its own schedule. The interface can be redesigned without changing the rules. The rules can be updated without breaking the interface. The data lives in its own structured place where it can be queried, migrated, and trusted.
When the three are mixed together — which is what happens in most hastily-built apps — you can't change one without disturbing the other two. This is what almost every "small change is harder than it should be" conversation is actually about.
App One: The Interface
The interface is what most people mean when they say "the app". It's the visible part, the part that the designer designs and what the user reviews on Twitter.
The interface app is the cheapest of the three to build, the fastest to change, and the one most people pay the most attention to. It is also the lowest-leverage in the long run, because everything about it can be redone in a redesign. A button that's in the wrong place this year can be in the right place next year. A screen that's confusing can be re-laid-out without touching anything underneath.
This is the part of your app where redesigns happen, where A/B tests happen, where you can experiment without long-term consequence. As long as the other two apps are sound, the interface can be reshaped almost endlessly.
Most builders are best at this app. It's where the visible payoff is. It's also what most AI-assisted builds produce well — screens are local problems that don't depend much on the rest of the app, which is exactly the kind of work that lends itself to fast generation.
The signal that the interface app is good: changes to it are cheap, fast, and don't break anything else.
The signal that something is wrong: every change to the interface seems to break something underneath it, or every "small visual tweak" turns out to require touching code that doesn't look related.
App Two: The Rules
The rules app is the one almost nobody talks about, and the one that determines what your app actually is.
What is a customer in your system? When does an order become a refund? Can a user place an order without a verified email? What happens when two people try to claim the last available slot at the same moment? What does "delivered" mean — when the courier says so, when the customer confirms, when seven days have passed without a complaint? Can a deactivated account still see its history? Should a paused subscription resume automatically, or wait for the user to confirm?
These questions are not about screens. None of them describe what's on the display. All of them describe rules — the parts of your business that have to be true regardless of which screen happens to be open.
In a well-built app, these rules live in one place. The rule that an order can only be refunded within thirty days exists once. The rule about what "delivered" means exists once. The rule about who can edit what exists once. Every screen that needs to know about these rules asks the same place. If the rule changes, it changes once.
In a poorly-built app, the rules are scattered. The thirty-day refund window is checked on the order screen. It's also checked, slightly differently, on the support screen. The admin panel doesn't check it at all. The email that's sent when a refund is requested has its own version of the rule, written into the email template.
Six months later, when someone says "let's change it to sixty days", the change has to happen in six places. Five of them get updated. The sixth doesn't, and now your app contradicts itself.
This is the app that suffers most when it's not deliberately built. It's also the app that's hardest to see, because it doesn't have a screen of its own. You can run an app for years without realizing the rules app is missing — and then one day you change a policy, and you discover that your "app" was actually four different apps with four different ideas about how your business works.
We've written a whole separate piece on what this looks like when it's done well — our introduction to domain-driven design for business owners is the long version. The short version is: an app that knows what it's modeling can change gracefully. An app that's just a stack of screens cannot.
App Three: The Data
The data app is the system of record. It's what survives.
If everything else got rebuilt tomorrow — every screen, every rule — the data would still be there. Your customers. Your orders. Your messages. Your transactions. The history of what happened. The thing that, if you lost, you couldn't get back.
This is the app that's hardest to change and most expensive to get wrong, which is why it's also the app whose design decisions echo the longest. The shape of your data — what tables exist, what fields they have, what relationships they have to each other — determines what your app can and can't do in the future.
Want to add a new kind of report? Easy or impossible, depending on how the data is shaped. Want to migrate to a new system? Painless or a year-long project, depending on how the data was structured originally.
The "data app" is also the one buyers know the least about. It doesn't have screens. It doesn't have animations. The developer doesn't show it to you in demos. But it's the most important of the three for the long-term value of your app, because everything else is derivative.
The interface can be redesigned. The rules can be rewritten. The data — if it was set up well — is forever.
We've written about this in our piece on what your app's backend actually is, which goes deeper into the question of what you actually own when you "own your backend". For the purpose of this article, the thing to know is: this third app is the foundation. The other two stand on top of it.
If it's wobbly, nothing above it can be stable.
Why Most Builds Only Get One
The economics of building an app push hard toward only building the first one well.
The interface is what the buyer sees in the demo. It's what they evaluate. It's what they show their investors or their board. If the interface looks good, the buyer is satisfied. If the rules are scattered across the codebase and the data structure is improvised, nobody notices — because nobody looks. There are no screens for the second and third apps. There is no demo of "well-organized rules".
This means a developer who's optimizing for the demo will put almost all their effort into the interface. They'll write the screens beautifully. They'll add the animations. They'll get the empty-state illustrations right. And in the time they have left, they'll improvise the rules and the data — putting just enough together to make the screens work.
The buyer accepts the result, because the result looks like what they asked for. The problems don't surface until later, when the missing rules app and the improvised data app start to make every change harder than it should be.
This is the structural reason that "the app worked great until we tried to add anything new" is such a common phrase. The app didn't work great. It worked great in the demo. The other two apps, which would have made it actually work great over time, were never built.
When you hear that phrase from another buyer — or notice yourself saying it — you can almost always trace it back to this. One of the three apps got built. The other two got skipped.
What It Looks Like When All Three Are Built
The honest summary: it looks like an app whose price tag was higher.
Building all three apps costs more than building one. There's no way around this. The rules app needs to be modeled — someone has to sit down and write out, in code or close to it, what the business actually does and how it works. The data app needs to be designed — someone has to think carefully about what gets stored, how it relates, how it'll be queried in two years.
None of this is fast.
But the buyer who pays for all three gets a different long-term shape. Changes are cheaper. Redesigns don't break the underlying logic. Adding a new feature is a feature-shaped amount of work, not a structural archaeology project. The developer who inherits the app — when the day comes — gets up to speed quickly, because the structure is legible.
The numbers vary, but in our experience, the difference is usually somewhere between 30% and 60% higher cost up front, for an app that's two to four times cheaper to maintain over its life. The math works out almost immediately for anything that's expected to grow, and very quickly even for apps that aren't.
We cover this from the engineering side in our piece on what clean architecture actually means for your business. The structural framing in that article — boundaries, layers, dependencies — is the same three-apps idea, told in slightly more technical language.
How to Ask for All Three Without Sounding Technical
You don't need to use the engineer's words. You need to ask three kinds of questions.
For the interface, the questions are usual: what will it look like, can we change it later, how easy is it to redesign without breaking everything.
For the rules, the questions go:
Where do the rules live?
If we change the refund policy, how many places does that change have to happen?
If a new team member needs to understand how our business works in code, where would they look?
Is there a single place where the rules of our business are written down?
For the data, the questions go:
What's stored, how is it structured, can we query it later in ways we haven't thought of yet?
What happens if we want to migrate, who owns it?
If I needed to take all of our data and move it somewhere else, what would that look like?
A good developer will appreciate these questions, because they signal that you're not just buying screens. A developer who's only built the first app will deflect them, or answer them vaguely, or change the subject back to the visible features.
The way someone responds to "where do the rules live?" tells you, very quickly, whether you're talking to someone who builds one app or three.
What Happens When You Only Got One
If you're reading this and realizing that what you have is mostly the interface — the screens are nice, but the rules and the data underneath are improvised — you're not alone, and you're not in trouble.
Most apps in the world are like this. The buyer paid for an app and got an interface with the other two improvised behind it. The reason this article exists is that the situation is much more common than the alternative.
What you can do depends on how far along your app is. If it's early, the right move is usually to build out the "missing apps" now — before more features get layered on top of the improvisation. If it's further along, the move is usually to extract the rules and the data gradually, one piece at a time, while the app keeps running.
This is the kind of intervention we describe in the piece on technical debt — usually smaller than a rewrite, often dramatic in its impact on the cost of future changes.
The point of this article isn't to make you feel like your app is broken. It most probably isn't. The point is to give you the mental model that almost every conversation about your app is about — even when nobody names it.
Three Apps, One Product
When you talk to people about your app, you'll keep talking about it as one thing. That's precisely fine. That's how products are described. The app is what your users use, what your investors fund, what your customers pay for.
But underneath, you now know there are three: the one they see, the one that governs what they're allowed to do and the one that remembers what happened.
When all three are built, the product feels solid. When only one is built, the product feels good in a demo and gets harder to use the more you push on it.
You don't need to be technical to ask which of the three you have. You just need to know the question exists.