How I kept HIPAA from swallowing a healthcare founder's first version

Last fall I built an EMS platform for a founder in healthcare. Patient data meant HIPAA, and HIPAA is a word that can swallow a project.

I come from enterprise software, and one of the big products I'd worked on before was a HIPAA platform. So I know what full, enterprise-grade compliance looks like: database-level access control, every organization's data walled off, roles for who can see and approve what, audits, policies, a trail for everything. I also know how long that takes. It's months of work, and a lot of it is policies and paperwork.

My client didn't need all of that on day one. He needed something that worked, and worked well, that he could demo and get his first customers onto in about 30 days. Those are two very different builds. Most of my job on that project was keeping us pointed at the second one without skipping the parts of the first one that couldn't wait.

I said what the first version was for

Early on, I made the intended outcome explicit and set expectations around it. I told him we shouldn't go too deep technically. AI coding tools make builds a lot faster than they used to be, but the thorough version of anything still takes real time, and time was the thing he had least of.

We also had a written scope, and that document did a lot of work.

I held the line on scope

On a long working call that October, a new feature came up: pulling incoming documents into a patient timeline. It was a good idea. It also wasn't in what we'd agreed to build first.

So I asked, "Looking at our document that we agreed on, is the timeline part of that?" Then I said what I thought: "I think these are distractions."

He thought about it and agreed. "It is less important, you're right... No, I don't need the timeline."

That exchange took about thirty seconds, and it only worked because the document existed. Without it, we'd have been arguing about opinions. With it, we were checking a list.

Later on the same call, when the conversation drifted toward everything the platform might eventually do, I brought it back with a plain question: "What can we sell this week?"

I named the tradeoff and let him choose

In that same stretch of the call I raised the thing I cared about most: "I'm most concerned about getting with your security team and making sure we can get the infrastructure to where we can even store our data compliantly."

He heard it, and he made a call. His hosting setup already had the HIPAA protections he needed for now, a full infrastructure move would take a couple of weeks, and in his words, "We don't have two weeks." He needed it to work first.

That was his decision to make, and he made it knowing the tradeoff. That's what I want from a client. I want the person paying for the build to see the cost of each path before picking one, and then I build the path they pick.

He made the same kind of call on compliance tooling a couple of days later. A service that automates HIPAA paperwork would have cost $10,000 a year, and he decided to hold off until there were a handful of provider offices on the platform. Same idea: get the working version out, then grow the compliance work with the business.

I built the part that couldn't wait

Some of it couldn't wait, though. A healthcare app with more than one organization on it has to keep their data apart from the very first record.

So that's where I put the early work. "My main focus has been getting security down so that Organization one doesn't see Organization two's data," I told the team at one standup. The next day I was still working through row-level security at the database level and role-based access in the app. When I walked everyone through it, I put it this way: "the way that we're filtering is by role, but when we're fetching into the database, it's at an organizational level, which allows us to be multi-tenant."

None of that shows up in a demo. It's still what lets you put a second customer on the platform without rebuilding anything.

I didn't make him wait on me

The other piece was keeping him moving. Automatic document scanning was on my list, and he was eager to start tuning the outputs the platform would produce. I told him he didn't need to wait: "You can actually get started right now. You don't have to wait on me to get the OCR working." He could enter the data by hand in the app and refine the output while I finished the automation.

That's the version-one mindset in practice. The manual path is fine if it lets the client start learning sooner.

How I scope builds now

This is the process I bring to every build, including the service businesses I work with now.

First, I get the outcome in one sentence, in the client's words. "A working version I can demo and put my first customers on within 30 days" leads to a very different build than "something that holds up in an audit."

Second, I name the tradeoff out loud. If there's a big requirement like HIPAA, I explain what the full version costs in time and what the lighter version leaves for later.

Third, I recommend the lighter path when it fits, and I'm clear about which parts can't be lighter. Separating customers' data isn't optional. A compliance platform subscription might be.

Fourth, I write down what version one leaves out. When a new idea shows up mid-build, and it always does, we check it against the list instead of debating it.

Whether it's a healthcare platform, a recruiting firm's CRM or a coach's client portal, the question is the same: what do you need to be true in 30 days, and what can wait until you have more customers? Then I build to that answer.