Model before code: why an hour with employees beats an hour with management

Most software projects fail for one reason: the system that gets built works perfectly but doesn't do the right thing.

Code is cheap compared to discovering, a month in, that you've been modelling the wrong process. And that's exactly why we start every serious engagement the same way — before we write a single line of code, we sit with the people who would use the system and watch what they actually do.

The org chart is a lie

Every company has an org chart. In it are roles, departments, hierarchy. If you read it as a software engineer, it's tempting to turn the chart into a system — salespeople see this, the supervisor approves that, bookkeeping does the next thing.

That almost never matches reality. The real process is denser, more complex, and full of exceptions the chart doesn't show. The salesperson doesn't always go straight to the supervisor — if the supervisor is out of the office, they go to a colleague; if the document is urgent, they go directly to bookkeeping. In bookkeeping not everything is the same — one person does invoicing, another VAT calculations, a third handles customer questions. The chart says nothing about that.

So the first phase of every project isn't writing code. It's a conversation.

Going down to the level of role and action

The discovery we do isn't a meeting with managers. It's time spent with the people doing specific jobs — how they fill out a form, how they forward, what happens when something is missing. We sit with salespeople in the field. We sit with bookkeeping while they work. We sit with warehouse staff while they issue goods.

The goal isn't to learn "how the system should look". The goal is to learn how the company actually functions — down to the lowest level of a single action. Who asks what, who sends what to whom, what happens when something doesn't fit.

The forms we see on the desk aren't the process itself. They're evidence of cracks in the process. Every form exists because at some point something was forgotten, lost, or mis-transferred, and the team invented a piece of paper to prevent it. There are usually more of those forms than the people themselves think. Only when you ask "and what do you do in case…" does a new form come out that everyone fills in but no one mentions at meetings.

State machines, not modules

When we come out of the discovery phase, what we bring back isn't a list of features. It's a model of entities and state machines.

The difference matters. A list of features is "a screen for entering customers, a screen for sales, a screen for collection". That's application design, not process design. A state machine is different: a document is born in the state created, moves to verified, can transition to invoiced or returned, from invoiced it can go to paid or reversed. From each state there are only certain transitions, and each transition has its rules.

Why does it matter? Because a company doesn't function through screens — it functions through flows. A document has no "screen"; it has a life cycle, and that cycle must be modelled explicitly so the system knows what it may and may not do with it.

When the state machine is clear, the screen is just a display of where that document currently is. A developer can write a screen in a day; an impossible transition in a process can cost a month.

Closing edge cases while they're cheap

The third thing we do before code: we take everything back to the client and ask "what did we miss?"

Discovery usually uncovers 80% of the process. The remaining 20% are edge cases — what if a customer returns half the goods? What if the same document is accidentally created twice? What if a salesperson in the field loses their phone with unsent documents? What if the exchange rate changes while an invoice is open?

The client usually knows all these things. They just haven't consciously connected them to the new system, because until now some person has handled them — Maria from bookkeeping who knows how to handle that problem. The system doesn't know. The system must be explicitly taught what to do.

When edge cases are addressed before code, they're closed in an hour or two of conversation. When they're discovered after delivery, the cost is a development cycle, retesting, redeployment, and — worst — a period where the production system works incorrectly.

An example from practice

The biggest project where we applied this approach is the operational system for Rudex. Before the first line of code, we spent weeks in meetings at their facilities. We sat with production, the warehouse, dispatch, bookkeeping — each role got a few hours of time.

Out of those hours came a model that described how the company actually functions, with all the edge cases we discovered together. The client validated the model before we started development. After that development went without major changes to the model, because the model was correct.

We did similar work for Sushi XO. Before we started the integration with their POS, we sat with the kitchen and the bar to understand exactly where the POS stops being useful and where the next problem begins. The POS works well within its domain — ordering, printing, payment. But it doesn't support a loyalty program, it doesn't handle SMS authentication, it doesn't understand that the same customer who ordered yesterday is on the site again today. The system we built didn't "replace" the POS; it filled a gap that was already there.

Five Rudex versions later, the same approach is the backbone of every next expansion. The system isn't changing because it was poorly built — it's changing because the company is growing and getting new flows. The old flows still work because they were modelled correctly at the start.

What this means for you

If you're thinking about a software project, the question to ask before you sign anything isn't "how much will it cost and when will it be done." The question is "how much time will we spend understanding our actual process before we start writing code?"

The answer "practically nothing, we already know what we need" is a red flag. It means discovery will be done during development — the most expensive possible place for it.

We make that work explicitly part of every project. Often it's the most valuable phase — not because it leads to code, but because the company gets to know its own process better. Often clients discover things they didn't know they did.

And when development starts, code is the simple part. The system knows where it's going because the model knows where it's going. That's the difference between software a company uses and software a company buys and forgets.