I am building a patient registration and appointment scheduling app for a healthcare clinic based in Dallas. I am part of the team at Software Orca working through the discovery phase, and the technical requirements keep shifting in ways that make accurate cost estimation difficult.

The specific problem is around HIPAA compliance. Things like encrypted local storage, session management, audit trail logging, and role-based access control all add meaningful development time, but exactly how much depends on decisions we have not locked yet, like whether we go native or cross-platform, and how the backend authentication layer gets structured.

Dallas has a strong healthcare market with clinics and smaller provider networks actively going through digital transformation. Most of them come in with a budget figure that does not account for the compliance layer at all.

How do other developers handle this gap with clients? I have tried breaking estimates into phases and presenting ranges rather than fixed numbers, but clients almost always anchor to the lower figure and expect that to hold.

Do you treat compliance requirements as a separate line item, or fold them into each feature as an overhead buffer? And when scope shifts mid-discovery, how do you communicate that without the client feeling like the original quote was not honest?

Henry_code commented: When scope shifts, tying the estimate to explicit assumptions makes it easier exactly why the cost changed. +0

Recommended Answers

All 5 Replies

When it comes to handling healthcare data, particularly PHI (Patient Health Information) then data security and regulatory compliance become your baseline non-negotiable items. Everything else is up for discussion.

Do you think they'd ask their doctors to not bother washing their hands to save a bit of money on soap?

Most of them come in with a budget figure that does not account for the compliance layer at all.

There's your first problem.

Explain that without compliance, their business with either face a haemorrhaging of customers who no longer trust their business, and/or regulatory oversight shutting the business down.

Though while the orange golf-ball still has his fingers wrapped around the throat of the American people, that might take some time to kick in.

like whether we go native or cross-platform

What?

Back ends usually run on one singular system.

Oh wait, this is all about the shiny pixels in the hands of the users isn't it.

If you're in the US there's some orange golfball and brain worm problems along with just a few insurance companies in charge of this.

I see NO OPENING for a small under 1 BILLION DOLLAR COMPANY here. Unless your last name is one of those in the current administration.

I think I see a basic flaw here. HIPAA compliance is not entirely the job of the "architecture."

Yeah, I can see where you're coming from. The software itself may not be the biggest problem here.

For a smaller company, you can end up dealing with compliance, security, legal work, insurance, hosting, audits, and ongoing maintenance before the product is even properly off the ground. Those costs can add up pretty quickly.

That said, I don't think it necessarily means smaller companies have no opening. It probably makes more sense to stay focused on a specific healthcare problem instead of trying to compete with the big platforms on everything.

The tricky part is making sure the business can handle the ongoing compliance and operational costs, not just the initial development bill. That's probably something I'd want to understand before putting a serious number on the project.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.