Build something useful

No LLM was inferred in writing/editing this article.

For all of 2025, my Dad's dental practice was wrestling with the new vendor they'd switched to after retiring their legacy system. Data migration issues, flows not working for doctors, still using 3 systems for patient management, billing, treatment work. Dentists and specialists still signing treatment plans on prescription sheets like the 80s. So even though I'm not a software guy, I'd been helping out here and there trying to get the team to settle into the new system.

Fast forward to March 2026. I'm sitting with my dad, the practice manager, and the lead doctor on the second floor of the clinic. Construction is going on upstairs, the practice is doubling its footprint, the first expansion in 26 years. But the conversation downstairs is about how we're going to stop using MindHale (name changed). And that's where I floated the idea: I'd build it myself. Built for the clinic, from scratch.

It's never been easier to ditch your SaaS subscriptions. (Note: it's only worth it if you or your team aren't the ideal customer type for the product, or if you have too many different subscriptions and it's hard to keep them organized.)

Now I repeat, I'm no expert but this is around the time Claude Code got really good at coding, and I'd been building real products that real businesses were paying for. I also frankly wanted to get my hands dirty on a bigger project while I figured out where to move next (just moved to SF). The clinic was a chance to work on something larger, with real data and value I'd directly see.

How do you build software for a business with no order? Administration sets pricing. Treatments change weekly. Patients haggle with doctors over cost. The pen-and-paper binders and hand-written lab orders made one thing clear: before a single line of code, we needed systems. Every procedure had to have a fixed price. Negotiations needed bounds. Payouts had to be organized so multi-step, multi-consultant plans split correctly. That was the first time I saw what software actually does, it forces you to define the business before you can automate it. Putting things into process.

Understand how your business operates. Define a standard. Software is only as good as your translation of how the business works into rules.

Now from here, starting with the doctor's experience, then billing, then reporting, labs, bit by bit, module by module the system has grown to a stage where it's the only software the clinic needs. This was just the start. Good software comes from repeated cycles of guiding the product to a place that continues to serve the business. Daily syncs, feedback loops, trying two versions with the doctors. As I write this I still have a recurring meeting every 3 days despite the product being 'done', to keep improving it.

Find the daily friction point with the most leverage. Usually something done every day, or your core offering, and automate that first.

One observation: throughout the whole time, I wasn't thinking about how to make money from it. I was thinking about how to learn the most from it. I never saw this as the product but as the tool; eventually maybe an MCP server for it, models trained on the X-ray archive to draft treatment plans, and maybe one day the operating space for a future agent. I treated it as a canvas to learn, and it bore the most fruit for me.

By no means is this a get-finished-quick thing. Real software is hard, takes time to stabilize, needs to be iterated on, and requires frequent conversations with users.