Why "move fast and break things" is a liability in regulated industries

How healthcare companies can ship a marketing site quickly without cutting compliance corners

This post is about healthcare marketing sites. Not patient portals, not clinical software, just the public website a health system, a biotech, or a digital health company puts in front of patients, providers, and partners. People assume that a marketing site is the low-stakes part of a healthcare company's web presence. It is not. It collects form submissions, it runs analytics, it has to be usable by people with disabilities, and every one of those things sits under a regulation. The pace that works for a consumer site breaks here, and I want to explain why in concrete terms.

There's a version of startup culture that treats speed as the only thing that matters. Move fast and break things. Ship it, learn from the wreckage, iterate. In a lot of contexts that works fine. Nav isn't mobile friendly? Push a fix, move on.

Healthcare is a different world. I've been building websites for healthcare clients for about ten years, and early on I made the mistake of thinking I could run the same playbook. Ship something, get feedback, tighten it up.

Except the feedback wasn't a user complaint. It was a compliance review that blew up a month of work because nobody had checked how patient data was moving between the site's contact form and the CRM behind it. The client didn't lose trust in the code. They were learning as much as I was. They lost trust in the process.

Why does breaking things cost more here?

Because the thing that breaks is usually a legal obligation, not a layout. When a healthcare company skips compliance review to hit a launch date, you don't just miss your launch window. You're looking at potential HIPAA violations, failed audits, and a site getting pulled.

Here is what that looks like on an ordinary marketing site.

Analytics. A consumer site drops Google Analytics, Meta Pixel, and a heat-mapping script on every page and thinks about it never again. On a healthcare site, a pixel on a page about a specific condition can transmit what amounts to health information to a third party. Several health systems have been sued over exactly this. So analytics has to be consent-gated: nothing loads until the visitor agrees, and the tag manager is configured so a marketer can't accidentally add a script that bypasses the gate. That is a design decision, and it has to be made before the first page is built, not patched in after legal notices the pixel.

Forms. "Request an appointment" or "Talk to a specialist" is a form, and a form in healthcare is a data flow. Where does the submission go? Who can read it? Is the email notification carrying a patient's name and reason for visit through a mail provider without a business associate agreement? Every form on the site has to pass legal review, and the review is faster when the form is built to a pattern legal has already approved rather than invented fresh for each page.

Accessibility. On most sites, accessibility is a nice-to-have the team gets to eventually. For healthcare organizations it is a regulatory requirement. Section 504 and the ADA apply, and the 2024 HHS rule sets WCAG 2.1 AA as the standard for covered entities. A carousel with no keyboard control or a PDF with no text layer is not a polish issue. It is a complaint waiting to be filed, and the people who can't use the page are often the people who most need to reach you.

I've watched teams stall for months because they shipped first and talked to legal after. The rework is always more expensive. It's not just rework either. Teams lose confidence and momentum. Fewer good risks get taken.

I keep waiting for the exception that proves me wrong on that, but it hasn't shown up yet. Speed and compliance aren't actually at odds. You just have to rethink what fast means.

How do you move quickly in regulated work?

Get compliance involved at scoping, as soon as you know which direction you're heading. Not after the build, not during QA. At scoping. Before anyone writes code, you need to know what data the site handles and what rules apply.

HIPAA, state privacy laws, the accessibility standard you're building to: what do I need to keep in mind here? It might feel like it slows you down, but it saves you from the three-week detour six months later when legal flags something you missed because you were too deep in the weeds.

Design for audit from the start. If your site touches anything that looks like health information, even a contact form, someone will eventually ask you to prove how it's stored, who accesses it, and how it moves. Think about that early and audits are just documentation. Think about it late and they're a fire drill.

Pick boring technology. Regulated industries are not where you debut an experimental form library you saw at a conference. Use proven patterns and stable frameworks. Use architecture that's been around for a while. It might not be as fun as testing a new framework, but that's not the point.

Plan around legal review. Most developers treat it like a wall they keep hitting. If you know legal needs two weeks to review a new form or a change to the consent banner, put it in the timeline. This is no different from a design review or stakeholder feedback.

What does nobody talk about?

Most agencies avoid healthcare. The process feels slow, the stakes feel high, and there's a lot of "not my problem" energy around compliance. That is exactly why the people who figure it out tend to stay busy. Healthcare clients don't need the flashy sites that win vanity awards.

Clients in regulated industries don't churn over price. They churn when their developer can't navigate the process. They churn when the team is slow to deliver, especially when something gets flagged as "needs to be fixed right now per legal." They churn when their solo developer disappears in the middle of the project.

If you can ship a healthcare site on a timeline that doesn't collapse every time legal gets involved, and you communicate proactively, you become very hard to replace.

"Move fast and break things" was always the mantra for companies that could afford the breaking. In healthcare you can't afford it. It's the difference between fines that put your company out of business and being able to provide your services to your patients. But deliberate isn't the same as slow.

Build compliance into the workflow instead of around it, treat it like a design constraint, and you end up shipping faster than the teams spending half their time cleaning up after themselves.