Simplifying Foundations in Complex Domains
Lessons from healthcare and marketplaces on what actually unblocks shipping.
Healthcare and real estate have one thing in common: the domain complexity is real, and it will eat your codebase alive if you let it.
At Hazel Health, I worked on systems that handled behavioral health screenings for students across dozens of school districts. Each district had different rules, different consent flows, different reporting requirements. At Zumper, we had rental listings across every major market, each with its own quirks around pricing, availability, and landlord preferences.
In both cases, the temptation was the same: model every edge case upfront. Build the abstraction that handles everything. Create the universal config object. The result is always the same: a system so flexible that nobody can understand it, and so brittle that changing one district’s rules breaks three others.
What actually works is simpler. Start with the most common path. Build it solid. Make it boring. Then, when a new edge case shows up—and it will—you add a specific handler for that case. Not a generic one. A specific one, with a clear name, that future-you can find and understand.
The compound interest of simple foundations is enormous. A team that can onboard a new engineer in a week instead of a month. A codebase where the bug is always in the obvious place. A deploy pipeline where nobody holds their breath.
Complexity is the default. Simplicity is the achievement.