# Every product is built twice - URL: https://onepointdelta.com/articles/every-product-is-built-twice - Category: Product development - Published: 2026-09-06 - Reading time: 4 min (781 words) - Source: OnePointDelta _Under every product people see is a system they don’t. The screens come second. The first build is the model of the business, and it decides everything else._ When a founder describes the product they want to build, they describe screens. The onboarding flow, the dashboard, the booking page, the thing the customer taps. That is natural; screens are what a product looks like. But screens are the second thing that gets built. The first is the system underneath: what the product knows, how that knowledge is structured, what happens when something changes, and who is allowed to do what. Get the first build right and the screens are almost easy; they are views onto a model that already makes sense. Get it wrong and every screen fights the model beneath it, features take three times as long as they should, and the product spends its life being patched. > The screens are the second build. The model underneath is the first, and it decides how hard everything else will be. ## What the first build is The first build is a set of decisions that have nothing to do with the interface. - **The entities.** What things exist in this product? A customer, a booking, a job, an invoice, a message. Which of these are the same thing seen from different sides, and which are genuinely distinct? - **The relationships.** A booking belongs to a customer. A job produces an invoice. A message belongs to a conversation, which belongs to a customer. The product is a map of these connections. - **The states.** A booking is requested, confirmed, completed or cancelled. Each state allows certain actions and forbids others. Most product bugs are a state the model never named. - **The transitions.** What moves a thing from one state to the next, and what else has to happen when it does? - **The rules.** Who can see what, who can change what, and what the product does on its own without being asked. None of this is visible to a customer. All of it determines what the product can do, how fast it can change, and whether it survives its second year. > A product is a model of a business with a screen on the front. Build the model first. ## Why the order matters Products built screen-first inherit the model implied by their first screens, which was never designed. The onboarding flow decided what a customer is. The dashboard decided what a job is. Six months later a feature needs those two to relate in a way nobody planned, and the team discovers that the product's idea of the business is a set of accidents. Products built model-first can change their screens freely, because the screens are the cheap part. A new interface for the same model is a matter of weeks. A new model under an existing interface is a rebuild. This is also why the first build is where a founder's understanding of the business is tested. Naming the entities and states forces the questions that a mock-up lets you skip: what is a customer before they have paid, what happens to a booking when the job is cancelled halfway through, who owns a conversation that spans two accounts. Answer those in the model and the product will handle them. Leave them to the screens and they become the bugs customers find. ## The sequence The brief for building a product is the same every time, and the interface arrives late in it. 1. **Concept.** What business is this product a model of? What does it have to know and do? 2. **Architecture.** The entities, relationships, states, transitions and rules, decided and written down before anything is drawn. 3. **Product.** The screens, designed as views onto that model, and the flows that move things through it. 4. **Engineering.** Building it, with the model as the fixed point and the interface as the flexible one. 5. **Deployment.** Putting it in front of real users, with the systems around it, payments, email, monitoring, in place. 6. **Iteration.** Changing the screens often, changing the model rarely and deliberately. Founders who want to skip to step three are not wrong to be impatient. The screens are where the excitement is. But the two steps before them are where the product's ceiling is set. ## What a good first build feels like It feels like the product understands the business. New requests turn out to be a screen away rather than a rebuild away. Edge cases have names. Data that came from one part of the product makes sense in another. The team can explain what the product knows in a few sentences, and those sentences stay true as the product grows. That is not luck. It is the result of building the invisible product first, as a system, and only then building the one people see.