When Building Becomes Free

Three places to put AI — and the one that gets missed

Every healthcare software company is racing to get AI into its product, and most have someone senior carrying that mandate, inundated with vendors and AI "solutions." Much of it is worth doing. But it's aimed at one of three places AI can actually go:

• AI you sell — features customers touch. This is where nearly all the attention and vendor noise lands.
• AI you use — the back-office tools that draft emails, job descriptions, and meeting notes. Useful, easy, beside the point.
• AI you build with — AI coding, reshaping how the company designs, builds, validates, and ships the software itself.

The first two are bolt-ons. The third is a different animal: it changes the cost of the one activity the whole business is organized around, and it comes before the feature race — rebuild how you build, and you can out-build competitors on nearly everything, those features included. It's also the hardest to act on — no vendor sells it, no playbook to buy — which is why even companies reaching for it get stuck. Closing that gap is what the rest of this paper is for.

The thesis in one paragraph

For thirty years the constraint on every healthcare software company was the same: engineering capacity was scarce and expensive. Everything else — the process, the org chart, the project managers, the bloated estimates, the ritual of prioritizing a wish list down to the two things you could afford — was machinery built to ration that one scarce resource. AI coding has removed the constraint. Producing working software is now fast, cheap, and effectively unlimited. But most companies haven't noticed in the way that matters. They've bolted a language model onto the old machine and asked it to write the same bloated specs faster. The companies that win the next decade will be the ones that stop optimizing the rationing apparatus and rebuild the company around the constraints that remain.

How we got here: three eras

The arc only makes sense if you see that each era was organized around whatever was scarce at the time. When the scarcity moved, the era ended.

Era 1 — The founder-visionary

The first generation of healthcare software companies was often founded by clinicians who taught themselves to code because the tools they needed didn't exist. They were their own first customer. That is the single most important fact about Era 1, and it explains both the magic and the eventual failure.

Because the founder was the customer, the loop between need, vision, and product was as tight as it could possibly be. There was no translation layer, no game of telephone, no requirements document — the person who felt the pain wrote the code that fixed it. When the founder's instinct happened to match what the market wanted, the result looked like genius. The product sold, the company grew, the founder moved into the CTO or chief-architect seat, and a sales and corporate organization assembled around them.

These founders were frequently difficult — dictatorial, certain, impatient with being told no. That, too, was a feature early on. Vision needs a spine. The problem wasn't a character flaw — it was a blind spot. Early product-market fit is easy to mistake for permanent insight. The founder concluded they had a Midas touch, when what they actually had was one good guess made when they were standing close to the customer. As the company grew, the founder drifted away from the bedside and toward the things founders drift toward: elegant architecture, a favorite language, the industry trend of the moment, the product they now found interesting. The instinct kept firing, but it was no longer aimed at a real customer. The Midas touch didn't fail because the founder got worse. It failed because the conditions that made it work — proximity to the customer — quietly disappeared. Eventually they shipped things people didn't want, and they were replaced.

Era 2 — The industrial process machine

What replaced the founder was, in many ways, a deliberate correction — and a sensible one. If the risk in Era 1 was a single unaccountable person guessing, the answer was to spread the decision out and put real structure around it. Product teams gathered requirements from across the customer base and the market and shaped them into considered specifications, which then moved through a disciplined pipeline of product management, design, project management, development, testing, QA, and documentation. Every one of those functions exists for a reason, and together they shipped serious, reliable software in an industry where reliability is not optional. For its moment, this was the right answer, and a great deal of good software was built this way by capable, committed people.

The difficulty is what the model gradually became. Estimates grew large — partly because the work is legitimately complex, and partly because, in a structure where caution is rewarded and no one holds a countervailing conviction about what ought to be quick, the safe estimate tends to win. Once everything is expensive, little can be attempted: you fund the top one or two items, often the regulatory must-dos, and a year later they reach a market that has already moved. Falling behind, the natural instinct is to add still more structure and oversight, because that is what the organization is good at — and development becomes a smaller part of an ever-larger machine. None of this requires anyone to be less talented or less committed; it is simply what happens when a system built to manage scarce engineering capacity keeps optimizing for that scarcity even as the scarcity begins to lift. Capable people end up with less room to actually build, and the creative spark that defined Era 1 gets quietly squeezed — not by anyone's intent, but by the sheer weight of process around it.

Era 3 — The AI inflection (where almost everyone is stuck)

We are now in the era of AI coding, and it has changed the fundamental equation — the production of software, the thing the entire Era 2 machine existed to ration, is no longer scarce. The honest state of the industry, though, is that most companies built like Era 2 have not reinvented themselves. They have absorbed the new tools into the old shape. They use a model to draft a specification, perhaps to generate some boilerplate, and then hand the result back into the same pipeline of PMs, estimates, hand-offs, and annual releases. They have made a slow machine slightly faster. They have not asked the question that actually matters: if the thing we organized the whole company to ration is now free, what is the company actually for?

The shift that changes everything

For decades, software ran on an iron triangle: fast, good, cheap — pick two. Sales lived their whole careers inside that constraint. Being told no, we can't, not this year was just part of the job.

AI coding breaks one leg of that triangle — and which leg matters, because the loose version ("AI makes everything free") is hype, and a veteran will rightly distrust it. What collapses is the cost and time of production — turning a well-formed intent into working code. That part really is now fast, cheap, and close to unlimited.

What does not collapse is everything around production:

• Judgment — knowing what is worth building, grounded in what the customer actually needs and what the sales team can actually sell.
• Verification — knowing whether the thing that was built is correct, safe, and clinically sound. In healthcare this is not polish. It is the difference between a feature and a patient-safety event.
• Coherence — keeping a thousand cheap, easy features from accreting into an incoherent, unmaintainable Frankenstein.
• Trust — the human relationship that actually closes a sale, which no model can do.
• Absorption — the customer's capacity to take a new release, validate it, and put it into clinical use, which in healthcare is severely limited.

The point is simple: the constraint didn't disappear, it moved. It moved off of production and onto judgment, verification, coherence, trust, and absorption. The Era 2 org was a well-built machine for managing the old constraint, which is exactly why it is now mostly overhead. The job in front of us is to build an organization shaped around the new constraints — the same way every prior era was shaped around the scarcity of its day.

"You can have all three now — speed, accuracy, and low cost" is true for production. The work is making sure the things you produce are the right things, that they're safe, and that customers can actually use them.

The right unit of the new organization is small. Call it a build cell: a tight group that brings every skill together and can take an idea to a shipped, validated product without handing it off to a separate development department. A healthy cell needs only a handful of people with strong judgment plus AI, supported by a few shared functions the whole company draws on. Five roles do the core work — and, as we'll see, the load does not split evenly among them. It concentrates at the two ends: on the people who decide what to build, and on the people who prove it's safe to ship. A set of preserved gates guards what cannot be allowed to fail, and a category of old roles has to learn to step back.

Role 1 — The Product Definer (vision, grounded)

This is the return of vision — but disciplined, where Era 1 was not, and it is the hardest creative work in the company. The Product Definer does the hard thinking: listening to customers, reading the market, and generating a high volume of product ideas, each captured as a thin skeleton — a short narrative, some screenshots or sketches, the context, the intent, the "why." The reflex to fight here is the Era 2 instinct toward the twenty-page specification. The skeleton is the deliverable; the detail is not. You let the AI propose and build the detail, because — and this is counterintuitive until you have watched it happen — the AI does the detail better than a human spec ever did. The vision stays anchored to two things at once: what the customer actually wants, and what the sales team can actually sell. That dual anchor is what keeps the role from drifting into the Era 1 failure of building whatever the visionary personally finds interesting. And while the role spikes hardest at the start — when years of pent-up, never-built demand come flooding in — it does not fade once that backlog clears. It settles into the steady, well-oiled engine of ideas that powers the company over the long run. This is the role that gets refined and better-oiled over time, never smaller.

Role 2 — The Build Director (the conductor)

This is the truly new role, and probably the hardest to hire for, because it has almost no precedent. The Build Director is not a programmer. They are the person who guides, audits, nudges, questions, and pushes back on the AI as it works — turning a vision into a real, complete, shipped system. They keep opportunities from being missed and, just as importantly, keep work from being quietly deferred or faked.

The skills are specific and uncommon together:

• Deep domain and development literacy — enough to know when the AI is wrong, when it's cutting a corner, and when there's a better path it didn't take.
• Tenacity to completion — the single most important trait. AI coding makes the prototype deceptively easy, which means the new trap is getting 80% of the way there, being satisfied by a working demo, and wandering off to the next shiny thing. The Build Director's job is to grind out the last, unglamorous 20% — the edge cases, the error handling, the places where the pieces connect — all the way to shipped.
• Patience to actually read the AI's work — the willingness to read the long explanations the AI produces, rather than skim and trust.
• A bias for "is it done and right?" over "does the demo work?" — because the model is extremely good at convincing both itself and you that everything is complete.

Role 3 — The Clinical Validator (the adversary)

In healthcare this may be the highest-leverage role in the entire model, and it is almost certainly the busiest. It sits directly on the constraint that now governs everything downstream: verification, where the cost of being wrong is a harmed patient. AI is excellent at the quick once-over — and at persuading everyone the work is finished; hands-on, clinically-informed testing, by someone actively trying to break it, is what reveals the gaps, the oversights, the quietly deferred code, and — just as often — the chance to make the design meaningfully better.

The work here is less intellectual than the Definer's, but the volume is enormous, and that is exactly the point. A Build Director and the AI can rip out a complete feature in a single day; getting that feature to a clean, shippable state takes a human looping through it again and again — breaking it, watching it get fixed, and re-validating, often several full passes before it is truly clean. So far no AI does this the way a person does, which is what makes validation the practical bottleneck of the whole cell: the rest of the pipeline can outrun it. The traits that matter are real clinical experience, relentless curiosity, the instinct to break things by clicking every path, and — above all — the stamina to iterate fast and hold the thread across many loops without losing speed. Issues go back in short documents built around screenshots and very short narratives, because speed is the whole game; the Validator can drive fixes into the AI tool directly or route them to the Build Director. (More on the two-phase rhythm below.)

Role 4 — The Deployment & Adoption Engineer (shipped and in use)

This is the role the original framing underweighted, and it turns out to be decisive: when the only thing that ultimately matters is the customer using the product, getting it shipped and into real, daily clinical use is the finish line — not an afterthought. Free production is worthless if the result sits in a release queue. This person owns the unglamorous, decisive work of getting software out the door and into live use: packaging, versioning, release mechanics, and the whole path into production. And they own it against the brutal realities of healthcare delivery — on-premise environments the vendor doesn't control, validation protocols, change windows, training, and the customer's hard limit on how much change they can absorb. Their mandate is to make each release land cleanly and to keep pushing the cadence outward to whatever the customer can safely take. A feature that isn't deployed and in use didn't happen; this is the role that makes sure it happened.

Role 5 — Sales, as the growth engine

AI cannot do sales. The relationship, the trust, the reading of a room, the overcoming of an objection — it is a 100% human process, which makes the salesperson the engine of growth in this new company and arguably its most important role. What the customer wants now drives everything downstream, because production is no longer the thing standing in the way.

This is also the role that has to change the most, and it's covered in its own section below, because it inverts how the job has worked for a generation.

The preserved gates — what must not fall away

It is tempting, and partly correct, to say the old roles will all fall away. But in regulated, safety-critical healthcare there are hard exceptions, and a credible plan has to name them or it isn't credible. These functions don't disappear; they get re-tooled, made leaner, and ideally accelerated by AI too — but they remain real gates that work has to pass through:

• Patient safety and clinical validation (Role 3 is the front line of this).
• Security and privacy — AI-generated code can carry subtle vulnerabilities; HIPAA and data protection are not optional.
• Regulatory and certification — ONC certification, information-blocking and interoperability rules, the relevant standards. These don't bend because your release cadence sped up.
• Architectural coherence — someone has to own the integrity of the system and the data model so that infinite cheap features don't rot into an unmaintainable mess. (See "Configure, don't customize," below.)

The discipline here is to keep these gates lean and embedded rather than rebuilding them into the heavyweight bureaucracy of Era 2. Strip the process. Keep the gates.

The roles that have to step back

Finally, and this is the hard part, the old roles have to get out of the way. The project manager who needs something to manage. The developer who needs to "check the code." The QA layer that has grown to serve the process more than the product. The instinct of every one of these roles is to insert itself into the work, and every insertion reintroduces a hand-off, a delay, and a point where the customer's signal degrades. After the build-and-harden cycle is complete, code needs to ship. The orientation is rapid deployment and short release cycles, not the ritual of imposing one more layer of oversight on work that no longer needs it.

How the work flows: the new process

The roles change because the process changes. Six principles define the new way of working.

1. Show, don't tell. This is the biggest single change to the front of the process, and it follows directly from the economics. When building a working thing is faster and cheaper than writing a document describing the thing, you stop writing requirements and start building prototypes to react to. Don't tell the customer what you'll build — show them a working version in days and let their reaction be the requirement. This kills the bloat at its root, because it was always a symptom of trying to get everything right on paper before paying the (formerly enormous) cost of building.

2. Collapse the chain. The Era 2 pipeline — customer to sales to PM to spec to dev to QA to ship — degraded the signal at every hop and took so long the market moved. The new model shortens the chain to something close to: customer need → a small cell that prototypes in days → customer reaction → ship. Fewer hops means less signal loss, which means faster and more accurate. Speed and fidelity stop being a trade-off.

3. Two phases, deliberately separated. There is real value in splitting the work into (a) getting from concept to a first working version — the Build Director and Definer building a working, coherent product — and then (b) polish and harden — the Clinical Validator driving the relentless cycle of breaking, fixing, and adding the small pieces that make it ready to ship. Blur the two and you either over-engineer the prototype or ship something brittle. Naming them as distinct phases, with distinct owners and a distinct bar for what "done" means, keeps both honest.

4. Configure, don't customize. This is the antidote to the most dangerous trap of a free-build world. When sales can get anything and building is cheap, the natural drift is toward a different custom build for every customer — and in EMR specifically, that road ends in an unmaintainable graveyard of one-off code, which is a big part of why so many legacy products stalled out. The discipline is to answer "every customer wants something different" with more powerful, configurable product built once for the market, driven by the sales bet on what is broadly sellable — not with per-customer customizations. Cheap production makes this discipline more important, not less, because the temptation to sprawl is now constant.

5. Design the cadence around customer absorption. You can now ship continuously. That does not mean you should ship continuously to every customer — because the constraint on the customer's side hasn't moved. Healthcare customers, especially on-premise (non-SaaS) ones, have been trained to fully re-validate the application on every release, so frequent releases create real pain and real resistance. The answer is not to slow down internally; it's to design the external cadence around what each customer can absorb:

• SaaS customers can take smaller, more frequent, well-tested releases — and you invest heavily in automated re-testing so the re-validation burden actually drops.
• On-premise customers get curated, well-documented, batched releases on a cadence they can absorb, with strong change-scoping ("only X changed"), backward compatibility, and — ideally — automated validation tools you provide so they don't have to re-test the entire application by hand.
• The competitive move is to turn fast iteration into an advantage without overwhelming the customer: make each release lower-risk and easier to absorb, not merely more frequent. The idea of an annual release makes no sense anymore; the idea of a daily release to a hospital data center makes no sense either. The right cadence is the one the customer can safely take, and your job is to keep pushing that frontier outward by lowering the cost of each release for them.

6. A coherence gate. One named owner — often the Build Director, sometimes a dedicated architect — is accountable for the integrity of the whole — the data model, the architecture, the way it all fits together. Every new capability passes a simple test: does it fit the coherent whole, and is it built as configurable product rather than a one-off? This is the lean, embedded version of governance that replaces the heavyweight version, and it's what keeps principle #4 from being merely a slogan.

Sales as the engine

For a generation, sales lived downstream. They were told what development could do, they accepted it, and when it wasn't enough they could blame resources, the roadmap, the process — and they were usually right to. Their customers were told the same thing: here is the wish list, only the top one or two will get done, it will take a year, and by the time it arrives it will have been diluted and reshaped by the game of telephone until it no longer quite fits. That was the deal, and everyone learned to live inside it.

That deal is gone, and its disappearance hands sales something they have never had: ownership. Sales now owns the decision about what gets built, and is accountable for it. We only build a feature to make a sale — so if it gets built, sales has to make the sale. The slack is gone. You can no longer blame development for not delivering what the customer wants, because development is no longer the bottleneck; you can have, more or less, whatever you decide to ask for, quickly. The flip side is that the bet is now yours, and so is the outcome.

This requires new muscles that the role hasn't had to develop, precisely because the old constraint did the deciding for them:

• Choosing well. When you can have anything, what to ask for becomes the whole game. That is a judgment skill, and it has to be built.
• Owning the bet and the close. "We built it because you said it would win the deal" is now a sentence that has a follow-up: did it? Accountability moves to the person who placed the order.
• Protecting coherence. Sales has to want product, not a Frankenstein. The instinct to promise each prospect a bespoke thing has to be channeled — through the Product Definer and the configure-don't-customize discipline — into asks that strengthen a coherent product rather than fragment it.

This is the part of the message a sales-DNA leader will feel most viscerally, because it restores sales to the center of the company and simultaneously raises the standard for what sales has to do. It is empowerment and accountability arriving together, which is the only honest way they ever arrive.

What the organization actually looks like

Put the roles, the cell, and the process together and the shape of the company changes.

The basic building block is the build cell: a Product Definer feeding a high volume of ideas, one or two Build Directors conducting the AI build, a Deployment Engineer getting the result into real use — and, weighted more heavily than any of them, the Clinical Validators, because that is where the constraint now sits. This is the second time the bottleneck has moved. Era 2's constraint was building; AI removed it, and the constraint jumped downstream to validation — the human loop of polishing, breaking, fixing, and re-checking that the AI still cannot do the way a person can. A cell can rip out a complete feature in a day, but getting that feature clean enough to ship safely takes multiple validation passes, and that throughput — not building — is what now governs how fast the cell can actually deliver. So the cell is weighted toward validation; the Build Directors stay lean because the AI carries the build; and the Definer is one or a few people. But do not mistake "few" for "shrinking": once the backlog of pent-up demand is worked off, the Definer doesn't fade, it becomes the refined, well-oiled engine of ideas that drives the company quarter after quarter. A cell like that, drawing on shared lean functions for safety, security, and regulatory, can do what an Era 2 department of dozens used to do — and do it in a fraction of the time. The company becomes a small number of these cells, each owning a product area, each able to go from idea to shipped, in-use software on its own.

That implies a smaller, flatter, faster organization, and it implies a different scoreboard. The Era 2 metrics — velocity, story points, utilization — are now actively misleading, because they measure the throughput of a machine you are trying to dismantle. The new scoreboard measures the things that now actually constrain you:

• Idea-to-shipped time — how fast a need becomes validated software in a customer's hands.
• Time to first revenue from a feature — did the bet pay off, and how quickly.
• Feature win-rate — when we built something to win a deal, did it win the deal?
• Customer adoption of releases — are customers actually able to take and use what we ship (the absorption constraint, made visible).
• Safety / defect escape rate — what got past the Clinical Validator, weighted by clinical risk.
• Product coherence — a deliberate read on whether it's staying one product or fragmenting into a patchwork.

A sales-led organization needs accountability mechanisms, and this is them: a clean scoreboard that makes the new bets, and the new ownership of them, visible.

Honest risks of the new model

A veteran will trust this more, not less, if it's honest about where it can go wrong. The new model is not a free lunch; it just moves the risks around.

• The model is confidently wrong. AI ships code that looks right and isn't. In a clinical context that is dangerous. Mitigation: the Clinical Validator and the preserved safety gate are non-negotiable, not optional polish.
• Security holes in generated code. Subtle vulnerabilities are easy to introduce and easy to miss. Mitigation: security stays a real, embedded gate.
• Frankenstein by a thousand cheap features. The cheaper building gets, the stronger the pull toward sprawl. Mitigation: configure-don't-customize, plus a single accountable coherence owner.
• Nobody understands the system. If no human ever wrote it, deep system knowledge can evaporate. Mitigation: the Build Director owns architectural understanding as a deliverable, not just working output.
• Sales over-promising. "We can build anything" quickly turns into "we promised everything." Mitigation: the bet runs through the Product Definer and the coherence gate; sales owns the outcome, which disciplines the ask.
• Hidden shortcuts piling up. Moving fast can bury the small compromises that slow you down later. Mitigation: the product-coherence metric exists precisely to surface them.
• The prototype-and-wander trap. The easy 80% is the fun part; the last 20% is what ships the product. Mitigation: this is the literal job description of the Build Director.

Naming these is not hedging. It is the difference between a strategy and a sales pitch.

Getting there from here: the part that actually kills transformations

The target state is the easy part. The hard part is that the company you are trying to change is the Era 2 machine, staffed by people whose identity, status, and sense of competence are bound up in the old way of working. The single greatest threat to this transformation is not technical. It is the organization's instinct to protect itself — the PMs who need to manage, the developers who need to check the code, the QA group protecting its role — recognizing the new model as a threat and pushing back.

A realistic transition respects that:

• Run it in a protected cell first. Don't try to convert the whole organization by memo. Stand up one real build cell, shielded from the existing process and the people who will resist it, and let it ship something real, fast. Proof beats persuasion.
• Re-skill the people who can make the jump. The talent is real and a great deal of it transfers cleanly — this is not a story about clearing the building. A strong developer with product sense can become a Build Director. A clinically experienced QA person can become a Clinical Validator. And the most valuable seat of all, the Product Definer — the persistent engine of ideas — is often best filled by your existing product and PM people, the ones with the listening, market-reading, and customer instincts already built, provided they have the drive and can let go of the twenty-page-spec habit. An infrastructure or release-minded engineer can step into the Deployment role. The point is that experience plus drive, not job title, predicts who thrives. Offer the path explicitly and generously.
• Be honest that the org gets smaller. It will. Pretending otherwise destroys the trust the transition needs. Honesty about the destination is what lets good people choose it.
• Protect the new model from the old one's metrics and rituals. Until the cell has proven itself, keep it out of the velocity reviews, the estimate ceremonies, and the release-train calendar. Those are the machine defending itself.
• Scale from proof, not from theory. Once one cell has shipped and sold, the argument is no longer abstract, and the second and third cells get much easier.

The closing frame

The temptation is to read all this as the pendulum swinging back to Era 1 — a new bright dawn where the visionary is restored to the throne. It isn't that, and the difference matters. In Era 1, only the doctor who could also code could improve things, and even then only while they stayed close to the customer. This is a different dawn. The production of software is now fast, cheap, and effectively limitless — for everyone, not just the founder-coder. The scarce thing is no longer the building. The scarce things are knowing what to build, proving it's safe, keeping it coherent, earning the trust to sell it, and helping the customer actually take it.

So we don't swing back to the founder. We build new roles and new processes around the new scarcities, and we let the old roles and the old paradigm fall away. Software production has become free, fast, and limitless. The whole job now is to organize the company around everything that hasn't.

I've lived the small version of this over the last nine months: I stopped coding and went back to creating software. The argument of this paper is simply that the company has to make the same move.