How I work
Domain Driven Vibe Building
The client can't write a spec. They can tell me about their work. So before I build a screen with AI, I build a shared language with them.
After eleven days and two prototypes for a small training studio, the screens looked great. Under them sat eighteen tables. Then I said:
All that we've done by now is front-end driven development. I'm not sure about the model behind the scenes.
Every table existed to make some screen work. None had been checked against the business itself. So I asked the AI to ignore the code, read only the studio owner's spreadsheets, video and voice notes, and build a model from scratch.
His spreadsheet already held much of the model, including versions of a training plan, which I had reached the long way, through the screens. About a third of our model was guesses. And in the middle sat a bug no screen showed: the only way to give a trainee a plan quietly reset their charts and the comparison with their last workout.
The client talks, the AI builds screens
My typical client runs a small business. They don't write specs. They send a voice note, a photo of a spreadsheet they've kept for years, and a story about a normal day at work. Somewhere in the middle they drop a line like “I always copy this into the other sheet by hand.” That's a requirement. They just don't know they said it.
Vibe coding tools turn that into a screen in minutes, and I'm all for it. But every screen needs data, and the AI makes it up as it goes. A table here, a field there. Each decision makes sense on its own, and none of them came from the business. What no screen needs, nobody builds.
So I flipped the order.
Three in the conversation, one language
A shared language means the developers and the people who know the business use the same words, in conversation and in code. In vibe building there's a third party in the conversation, the AI. When there's no shared language, it invents one.
The therapist at a clinic says “session”. I write appointment in the prompt. The screen shows “meeting”. The code gets booking. Four words for one thing, and the AI doesn't know they're the same.
And the word carries rules. A patient comes for a series of treatments. The receptionist sees when they come, not what the therapist wrote. A session cancelled an hour before might need a charge. When the AI builds a customer with a list of appointments, none of that has a place.
| Business | The client's word | What it carries | What the AI builds without a model |
|---|---|---|---|
| Clinic | Patient | A series of treatments, notes only the therapist sees, a late cancellation that may be charged. | customer with appointments |
| Fitness studio | Trainee | A plan that changes over time, and history that must not be lost. | user with meetings |
| Property | Tenant | A lease with a start and an end, monthly rent, a deposit. | user with payments |
| Kids class | Parent and child | Who pays and who comes. One parent can have several children. | one user who pays and attends |
If the client never said a word, it needs a good reason to get into the model.
The model works for all three of us. The client reads it and corrects it, because it's in their words. I argue with it. And the AI gets it with every prompt, so the names stay the same from the table to the screen.
Four layers, bottom up
I move to the next layer only when the one below is finished enough to argue with.
The big difference is that the interface comes last. Once the model and the storage are settled, the vibe comes back at full speed, and the AI no longer has to guess what to store or what to call it.
And two rules. First: every item in the model says where it came from. the client's if the client said or showed it, ours if it's a guess, mine or the AI's. That way a guess never quietly turns into a requirement. Second: a screen can't add things to the model. If something is missing, I add it on purpose, with the reason next to it.
When to skip it
It has a cost. At first there's nothing to show on screen, and that makes the client nervous, and me too. If a week goes by with nothing to show, that's the signal to stop and show something, even if it's unfinished.
For a demo, a landing page or a one-screen tool, plain vibe building is the right call. My rule: if the system will hold a client's real data over time, the model comes first.
The client can't write a spec, and they don't need to. My job is to write down their words and turn them into a model, before the AI invents other words.