Why "Move Fast and Break Things" Should Be Illegal in Health Tech

I’m writing this from a hospital room.

My father has been here a little over three weeks. Heart failure, a rare pulmonary condition, and now kidney failure that led to needing dialysis.

At least half a dozen specialists are managing his care, and the coordination between them is its own full-time job. Dr. Dara and I have been here to help carry it.

Sitting in this room has sharpened a belief I already held.

“Move fast and break things” has no business anywhere near health.

It is the most quoted operating principle in technology, and in its original home it made sense. When the product is a social feed, the worst case is an ugly screen or a lost post.

You ship, something breaks, you fix it, nobody is harmed.

But the phrase travels. Founders carry it into categories where the same words mean something completely different. When the user is a living thing, “break things” stops being a bug report. It becomes a missed diagnosis.

A wrong number handed to a team deciding whether someone survives the week.

I would not want a half-finished product anywhere in the middle of my father’s care right now. Not because technology has no role, but because the wrong technology, shipped fast and validated never, is a hazard dressed up as a feature.

I spent a decade selling encryption and endpoint compliance to the Department of Defense, hospitals, banks, and federal agencies. Those buyers do not tolerate breakage.

In those rooms, “we’ll fix it in the next release” is not a roadmap, it is a liability. Break something, and you get fired or sued, not promoted.

That built a different reflex than the consumer-app playbook most health and pet tech founders bring with them. They learned to ship where failure was cosmetic. I learned to ship where failure ended contracts and careers.

Here is the part the hospital made concrete.

The answer is not “AI has no place.” The answer is knowing the difference between what is critical and what is not, and treating them differently.

Near critical care, the honest role for technology is narrow.

• Report the hard data.

• Surface trends in that data.

• Retrieve and translate it for someone who is not technical.

Maybe hand a clinician a clue that helps them jog a memory.

The guardrail is simple to say and hard to build:

It points to hard data, never to interpretation, and never to a hallucination. It can be done.

It is not easy, but it can be done. We have built it that way at PerkyPet.

And there are things technology will never do. Dara sitting at my father’s bedside has done more for him than any product ever could. No model replaces that.

So at PerkyPet we move slowly on the things that are critical and quickly on the things that are not. When one of our AI agents gets something wrong, it does not ship. It goes back to our veterinary and scientific advisory board, and we retune it together. That loop is running right now.

Thirty-five validated prognostic indicators came before a single line of marketing copy. The platform is built to support pet parents between vet visits, never to replace the veterinarian.

That discipline has a price, and I will name it.

We pushed our launch to Summer 2026. We deferred the revenue windfall a faster, looser approach might have captured. I do not regret a single one of those decisions, and sitting in this room has only hardened that.

I have taken business calls from this hospital room. The team keeps the product moving while I am here, and good monitoring tech is part of why I can be in two places at once. That is what technology is supposed to do. It serves the people using it without getting in the way of the moment that matters.

Move carefully and validate things. It will never fit on a T-shirt. But it is the only principle I am willing to build a health product on.

Over the past weeks, I’ve been sharing lessons from three decades of building technology companies.

Three weeks ago, we questioned a popular startup practice and discussed what meaningful customer collaboration actually looks like.

Two weeks ago, we took a closer look at market assumptions and why founders should be skeptical of numbers that look too good on a slide.

And last week, we unpacked why you need to hire rigorously, not sluggishly. Fire to protect your best people, not to punish your worst.

Next week, I’ll share another lesson from the realities of building technology businesses, products, and teams that last.

Subscribe to get the next post the moment it goes live.