From 6 Months to 2 Weeks: An AI-Native Build Inside a Hospital Software Platform

A brownfield healthcare product. Two prior vendors that couldn’t hold the relationship. And a first module that shipped fast enough to change how the client’s leadership team thought about what AI-native development actually means.

Two weeks ago, we started working with a healthcare product company building a hospital-facing platform with real clinical impact. This is not a greenfield story. Before us, more than one vendor had already churned off this account, not because the product was wrong, but because they couldn’t consistently show value or deliver against what they promised.

That’s the situation we walked into. A brownfield codebase, a client that had been burned before, and a product complex enough to include multiple hardware integrations alongside the core software. This is what happened in the first two weeks, and why it ended with the client’s CEO asking for a hug.

01 The Expectation We Set on Day One

Before writing a single line of code, we told the client something that, in healthcare software, tends to raise eyebrows: we would use AI, specifically Claude models, to generate roughly 70 to 80 percent of the codebase.

For a product this complex, with multiple hardware integrations and hard requirements around patient safety and compliance, that’s a bold claim to make to a client who has already watched vendors overpromise. It only works if the remaining 20 to 30 percent- the architecture, the decision workflows, the design discipline- is airtight.

That stack, running across a web front end, a desktop application for hospital floors, and cloud infrastructure, is exactly the kind of surface area where AI-generated code can quietly go wrong if there isn’t a process holding it together.

02 The Harness Behind the 70 to 80 Percent

The reason we were comfortable making that commitment, even during a ramp-up phase on a brand-new engagement, is that we weren’t improvising. We have an internal ADLC, an AI development lifecycle process and harness, that governs how our team uses AI models across planning, coding, and review. It’s the difference between repeatedly prompting an AI model and hoping, and running AI generation through a repeatable, structured process.

On top of that process sits experience that doesn’t come from a framework. Twenty thousand hours of hands-on coding experience is what let our lead engineer sit with the AI-generated output and immediately see where the decision workflows needed to be restructured around SOLID principles and established design patterns, rather than accepting the first version an AI model produced.

03 The First Module, Shipped in Two Weeks

Within two weeks of engagement kickoff, still technically in ramp-up, we delivered the first module. It didn’t ship as a prototype or a demo. It shipped as a build.

Alongside the code, we handed over documentation that went well beyond a typical handoff doc. We split it into nine sections, each one addressing a question a hospital software buyer actually asks, not just what a typical engineering team documents by habit.

Notice what’s on that list. Patient safety and security aren’t afterthoughts bolted onto an appendix. They’re named as non-negotiable design philosophy, right alongside architecture. That’s a deliberate choice, and it’s the kind of choice that AI can help you write up quickly, but can’t make for you.

04 The Meeting

We walked the client’s leadership through the module and the documentation. The reaction wasn’t the polite nodding you get when a client is satisfied. It was something closer to disbelief.

At the end of the meeting, the CEO stood up. Reaching for a handshake, he asked instead, “Raj, can I hug you?” It’s one of the best compliments we’ve received, precisely because it wasn’t polished corporate language. It was a genuine reaction to seeing months of expected work compressed into two weeks.

Before the meeting, the COO had pulled us aside and said what stood out to them most wasn’t speed. It was that our team thinks through software engineering best practices at their core, and builds systems rather than just features. The CTO, who had been closely guiding the technical direction, said he was thoroughly impressed by the team’s proactivity, communication, and responsiveness, and by how consistently we held ourselves to a high standard.

05 What This Story Actually Proves

It would be easy to read this as “AI made it fast.” That’s true, but incomplete, and it’s the part of the AI conversation that gets oversimplified the most.

AI didn’t replace the judgment that decided which design patterns to enforce, which decision workflows needed human review, or which sections of a compliance-heavy hospital platform could not be left to a first-pass AI output. What AI did was remove the mechanical drag of writing 70 to 80 percent of the code by hand, so that experienced engineers could spend nearly all of their time on the 20 to 30 percent that actually determines whether hospital software is safe, compliant, and maintainable five years from now.

That’s the real definition of AI-native development. Not less engineering. More engineering, applied to the parts that matter, because AI is carrying the weight that used to consume months of a senior engineer’s time.

Building complex, regulated software and wondering if AI-native development is real or just a pitch?

We'd rather show you a build than describe one. Talk to our team about your product.

Start the Conversation

06 Why This Wasn’t Vibe Coding

It’s worth naming the thing this story is not, because the two get confused constantly right now. Vibe coding, prompting an AI model in natural language and shipping whatever it hands back, is genuinely useful for prototypes, internal tools, and proving out an idea fast. It is not the same activity as the one that occurred in this engagement, and the difference isn’t philosophical. It’s structural.

Security researchers and engineering teams have spent the last year documenting the same pattern over and over: AI-generated code that ships without a governed review process tends to carry exploitable vulnerabilities, inconsistent patterns across a codebase, missing error handling, and no audit trail. That’s an acceptable trade-off for a weekend prototype. It is not acceptable for software that touches patient data, integrates with hospital hardware, and has to hold up under regulatory scrutiny five years from now.

The 70 to 80 percent figure we quoted this client is the part vibe coding and AI-native development have in common on the surface. Both let AI generate most of the code. Where they split is everything underneath that number: a harness that governs how AI is prompted and reviewed, decision workflows built around SOLID principles instead of whatever pattern the model defaulted to that day, a documentation trail that maps every design choice back to patient safety and compliance, and engineers with enough hands-on experience to catch the 20 to 30 percent an AI model will get wrong or leave dangerously ambiguous.

Vibe coding optimizes for how fast you can get to a working demo. AI-native development, done properly, optimizes for whether the system is still safe, auditable, and maintainable long after the demo is over. For a hospital platform, that second question is the only one that matters.

Frequently Asked Questions (FAQs)