Model the hard case before anyone asks for it.

One of the owners we build for stopped us mid-build with a fair question. The scheduling data in their app looked flat on the screen, a simple list of items. But the business it modeled was not flat. Jobs contained phases, phases contained rooms, and the rooms rolled back up into the job total. They wanted to know, before we went any deeper, whether the version they would need a year out could hold that shape, or whether we were quietly building something they would have to tear down.

We opened the schema. It already did that.

That exchange is what "craft scales" actually means, once you take it out of the slogan. It is the difference between a data model that survives contact with the real business and one that looks fine in a demo and buckles the first time the requirements get honest.

The cheap way and the durable way

The cheap way to model a feature is to build exactly what today's screen needs. If the demo shows a flat list, you store a flat list. It ships a little faster, it looks identical, and for the first few weeks nobody can tell the difference. The durable way costs slightly more up front. You model the shape the product will actually need when it grows: the nested case, the multi-role case, the "what happens when there are a hundred of these instead of three" case.

Most of the time those two roads look the same from the outside. The screen is identical. The difference lives in how the data is stored, and it only surfaces later, when someone finally asks the product to do the thing it was always going to be asked to do.

You will never see this decision

This choice does not demo. There is no screenshot that makes "we modeled the nested case" look impressive next to "we added a dashboard." So it is exactly the kind of work that gets skipped when a shop is racing to look done. And skipping it stays invisible right up until the day it isn't. On that day it becomes a migration project with a change plan and a war room, on your budget, to repair something that could have been a design decision made once, early, for free.

The tell that a shop is thinking about your product and not just this week's demo is small. When you raise a "will this hold" question mid-build, do they say "we'll deal with that later," or do they open the thing and show you that it already holds? "Later" is the word that should worry you. Later usually means they built the flat version and are hoping you don't grow into the corner.

Which hard cases are worth modeling

We do not model every hypothetical. That is its own failure. Gold-plating an MVP with structure for features that may never exist is just bloat wearing an architect's hat, and it burns the same runway that overbuilding features does. So the judgment is in picking which future cases are real.

We look at the business, not the screen. If a trades business estimates by job, and a job is always made of phases and rooms, then the nesting is not hypothetical. It is the real shape of the work, and it will show up whether or not anyone planned for it. That case we model on day one. The speculative "what if they add a marketplace someday" gets written down and left out. The rule we use is simple: model the shape the business already has, even when today's screen hides it, and do not model the shape the business might someday invent.

What it actually buys you

The payoff does not show up on launch day. Both versions launch. The flat one and the nested one look identical to the first users. The payoff arrives the day the real requirement lands, when one product answers it with a settings change and the other answers it with a rebuild. That gap, the one nobody can see at kickoff, is most of what you are paying a senior team to prevent.

So when you are deciding who builds your MVP, ask a question you cannot fully judge the answer to, and then watch how they handle it. Ask what happens when a job has ten rooms instead of two, or when a user needs three roles instead of one. If the answer is a calm "open the schema, it already does that," you are working with people building the product you will have in a year. If the answer is "we can add that later," you are paying for the demo.