This project started at my house's dining table. Over dinner with my parents, my father, a neurologist, explained that a clinic opening in about four months would need a new clinical management software. For reasons I won't get into here, they couldn't keep using the software they'd relied on until now. So we talked about building our own, combining his domain expertise with my technical knowledge.
I want to explain how this journey went, and especially why it has been so smooth and what I got right. For a long time I've written about the mistakes I've made; this is a story of success, and of the lessons I've finally put into practice. It feels good to sense that you've found a better way of doing things, even if I haven't mastered it yet. That just comes with time. I now know this is the right direction, and I want to share it.
This isn't a purely technical piece on how to build software. It's about a shift in mentality. To work this way, the whole team has to buy in, because the results are clearest in hindsight: when you look back and realize that the work you did up front made you faster every time, not slower. That's the entire point, and it's the motivation behind everything I do.
I'll keep this chronological, so let's start at the beginning.
Let's go straight to the first day of real work. For the first two days, I did something I'd never done at the start of a project: I didn't open Visual Studio, and I didn't write a single line of code. Instead, after my 9-to-5 and after my father finished his, I went to his clinic. There we were, at 7pm, in his office.
I asked him to treat me as a patient and walk through every feature he actually used with real patients. After distilling the features he leaned on most, I asked about the ones he didn't touch, and the surprising part is that he didn't even know about, or had never used, roughly 80% of them.
Then came one of those hard conversations. I told the team we wouldn't be replicating their current software, which is what they'd assumed. Instead, we'd start with a minimal version they could actually use. It is not easy to tell people you're cutting about 70% of the features they're used to. The only way to get away with it is to genuinely understand how they work and distill the essentials. This was not easy, but that's the point. It isn't supposed to be, and it's something no LLM can do for you.
This is where you can still make a real difference, not just as an engineer but as a product engineer. Stop thinking about how to build all those features; first figure out how not to build them at all.
In this phase we still don't touch any code, even though I was chewing my nails wanting to. If I already knew which features to build, why hadn't I started? Because I didn't understand the domain well enough to one-shot it. I wasn't confident, and that's not a bad thing. I just needed more information.
To gather the missing pieces, I started event modeling the defined MVP. For scheduling reasons I couldn't get everyone in the same room at once, so I did most of the work myself and saved the key questions for the people who could answer them. Many were simple checks: "Should role X also be able to do Y?" But some genuinely improved the workflow, like: "Do you need to make a patient's history editable before printing it or emailing it?"
The thing is, the small decisions aren't yours to make. They belong to your users. This turned out to be an exceptional experience: the team could see the various flows laid out, and they flagged important details we would otherwise have discovered only after shipping.
It is far, far cheaper to fix a mistake while modeling the system than after it's in code.
The usual objection shows up here: "This is over-engineering." Really? Spending two or three days understanding your own system counts as over-engineering? If you aren't comfortable delaying your time at the keyboard, you'll be guessing from the start, and we all know how that goes. I won't bother explaining, because it describes almost every software project.
Now it's time to get our hands dirty. With the system modeled as processes, the path forward was to implement it in vertical slices. I'll write a separate post on vertical slices, but in short: it's a way to structure code so that each business process is isolated and decoupled. This was a game changer. I could start implementing the slices I fully understood while still iterating with domain experts on the ones that needed more discussion.
For the implementation, I built two Claude skills. The first parsed the event model (JSON exported from Miro via the Event Modeling extension) into a YAML spec containing the command, event, and read model plus all the business rules, in one indexed file. One spec, one slice. The second skill scaffolded the vertical slice from each spec. That one was tricky, and I spent real time tuning it to behave the way I wanted.
Once it was set up, the speed was remarkable: every slice was completed in under five hours, frontend included. And let me stop here, because some of you are thinking he had a prototype. No. I had a production-ready system with security, observability, auditability, tracing, testing, documentation, everything I needed for the moment. This was going to be the final product, and I treated it as such. The hard work was already done; with the right tools and architecture, the implementation phase was almost trivial.
Nothing in software is ever perfect or finished. So I shipped the first version for them to use, swapping out their old software so they could start working in mine. I wanted it out as soon as possible because I knew I'd been aggressive about cutting features. Some might turn out to be necessary, but when in doubt, I wanted to feel the need before building for it.
They started using it, and of course we heard things like, "Oh, I thought this role could also do Y," or "We used to be able to do Y, how do we do it now?" This wasn't bad news; it was exactly what our approach predicted. The key is that we could discuss each missing piece against the event model we'd already built, and shape those features not just to replicate the old behavior but to improve it and fit their actual needs.
That loop never really ends. It's just how software projects work. Your job is to understand what to build and when. That's the hard part, and it's what an LLM can't replace.
One more thing caught my attention: the clinic had been running two systems at once. One was theirs; the other was a popular industry tool that lacked some features they wanted and was expensive, so they kept the two in sync by hand. When I noticed this, I checked whether the popular system had a REST API or some integration path. It did. So I proposed that our new, minimal software integrate with it and keep everything in sync automatically. They were thrilled.
It's another example of how a product mindset makes the difference; the code was never what made us valuable. I didn't write a single line of code for this project, and I never hit a Claude limit. And when I do need to go through the codebase, it's easy, because I understand the patterns behind every process and I was present for every decision that shaped each command, event, and read model.
This isn't the first product I've built, but it's the first where, looking back, I know I'm headed in the right direction. Now it's a matter of mastering these techniques, becoming a better product engineer, and building a hundred more things worth building. That's my roadmap.
