Healthcare Software Development Timelines: Why AI Specs Get Them Wrong

A new pattern has emerged in healthcare software development over the past two years. Founders arrive at their first vendor conversation with a polished requirements document written by ChatGPT or Claude, complete with feature lists, user stories, and a confident timeline of 90 days.

At Arkenea, where we have spent 15 years developing healthcare software exclusively, we now see these documents in a majority of early conversations, and the gap between what they promise and what the project actually requires has become one of the most expensive misunderstandings in the industry.

This article explains why that gap exists, what AI generated specs consistently leave out, and how to pressure test your own document before it costs you a failed engagement. The problem is not that founders use AI to draft requirements. The problem is treating the output as a plan rather than a starting point.

Why AI Generated Specs Are So Convincing

Large language models are trained to produce complete, confident, well organized text. Ask one to spec a telehealth platform or a specialty EHR and it will return a document with numbered modules, clean user stories, and an estimate that sounds precise. The formatting signals rigor, and the confidence signals feasibility.

But the model is pattern matching against tutorials, marketing pages, and toy project writeups, not against the delivery records of production healthcare systems. Public content about building software skews heavily toward demos and MVPs that were never audited, never integrated with a clearinghouse, and never survived a security review. The model reproduces the optimism of its sources.

There is a second, quieter issue. An AI spec is generated in minutes, so it never absorbs the friction that shapes a real scoping process: the stakeholder who reveals a workflow nobody documented, the payer rule that breaks a clean data model, the integration partner whose API documentation is three versions out of date. Those discoveries take weeks of structured questioning to surface, and they are precisely what determines the timeline.

The Demo and the Product Are Different Systems

Most AI generated timelines are roughly accurate for one thing: a demo. A single developer using AI coding tools genuinely can produce a working prototype of a patient portal or a scheduling app in 8 to 12 weeks. It will log users in, display data, and look credible on a screen share.

A production healthcare system is a different object entirely. It needs role based access control across user types, audit logging on every touch of patient data, encryption at rest and in transit, session management, breach response procedures, and infrastructure that holds up under a security assessment from a hospital IT department. None of that is visible in a demo, which is why AI specs price it at zero.

The security data here is not encouraging. Veracode tested code generated by more than 100 large language models across four major languages and found that AI generated code introduced security flaws in 45 percent of tests. In consumer software that is technical debt. In software handling protected health information, it is a reportable breach waiting for a discovery date.

What AI Specs Consistently Leave Out

Across the documents we review, the same categories of work are missing or dramatically underweighted. Each one is a multiple of the original estimate, not a line item.

• Integration engineering. Connecting to an EHR via SMART on FHIR, a clearinghouse for claims, an eligibility verification service, a remote monitoring device feed, or an ambient AI scribe each carries its own sandbox access process, certification requirements, and testing cycles. A spec that says “integrates with Epic” in four words is hiding months of work behind them.
• Compliance architecture. HIPAA obligations shape database design, hosting decisions, access models, and logging from the first line of code. Retrofitting them after the build is not a cleanup task, it is a partial rebuild.
• Data migration. If the product replaces an existing system, historical patient, billing, or clinical data has to move with validation and reconciliation. AI specs almost never mention migration at all.
• Edge cases in clinical and billing workflows. Payer rules, coordination of benefits, retroactive eligibility changes, and specialty specific documentation requirements generate a long tail of conditional logic. The happy path in the spec covers perhaps 60 percent of what users actually do.
• Testing and validation. Healthcare software requires testing depth that consumer apps do not: claim scenario testing, permission boundary testing, and user acceptance cycles with clinicians whose calendars do not bend to sprint schedules.

Then there is the single developer assumption. AI specs frequently imply, and founders frequently infer, that one full stack engineer can carry the project. Production healthcare builds require backend, frontend, QA, DevOps, and compliance review as distinct functions, even when some are part time roles.

The Math Behind 3 Months Becoming 18

The overrun pattern is well documented and predates AI entirely. McKinsey and the University of Oxford analyzed more than 5,400 IT projects and found that large IT projects run 45 percent over budget and 7 percent over time on average, while delivering 56 percent less value than predicted. The same research found that 17 percent of projects overrun so severely that they threaten the survival of the company behind them.

Those figures describe projects that started with professionally prepared estimates. An AI generated spec starts several layers below that baseline, because it omits entire categories of work rather than merely underestimating them. When the omitted work surfaces mid project, it arrives as change orders, replanning cycles, and rework on architecture that was sized for the smaller scope.

The compounding is what turns 3 months into 18 rather than into 5. Missing compliance architecture forces schema and infrastructure changes, which invalidate completed work. Late discovered integrations impose external certification timelines that no amount of internal effort can compress. Each delay pushes the project deeper into the pattern McKinsey identified, where every additional year of project duration increases cost overrun by an average of 15 percent.

HIPAA Is an Architecture Decision, Not a Feature

This deserves its own section because it is the most expensive omission we see. AI specs typically handle compliance with a single bullet reading “HIPAA compliant” as though it were a library to install in the final sprint. The regulation does not work that way.

The HIPAA Security Rule requires a documented risk analysis as the foundational first step, and the safeguards that follow from it are structural: how data is segmented, who can access what under which conditions, how every access event is logged, and how the hosting environment is configured. These decisions belong at the start of the build because everything else is constructed on top of them.

A system built without that foundation and patched afterward carries the cost twice. First in the rework, and second in the ongoing fragility of controls that were bolted on rather than designed in. When a hospital procurement team or a payer security review examines the architecture, bolted on controls are exactly what they are trained to find.

The Fixed Price Trap That Follows an AI Spec

An AI generated spec creates a dangerous illusion of completeness, and that illusion invites fixed price quotes. A founder shops the document to five agencies, and some of them return a firm number against it within days. That number feels like certainty.

It is not. A fixed price is only as fixed as the scope beneath it, and a spec missing integration work, compliance architecture, and edge case logic does not define a scope. It defines a fraction of one. Any developer who commits to a fixed price against an unvalidated AI spec is guessing, and the commercial structure of a fixed bid means the gap gets resolved later through change orders, quality shortcuts, or an abandoned engagement.

The honest answer at that stage of a project is a range with stated assumptions, refined through a proper discovery process. Vendors who refuse to name a premature number are not being evasive. They are declining to bill you for a guess.

How to Pressure Test Your Spec Before You Shop It

Your AI generated document is still an asset. It captures your product intent faster than a blank page ever would. Before treating it as a plan, run it through the following questions.

1. Does it name every external system the product must talk to, and does each integration have its own timeline entry covering sandbox access, certification, and testing rather than a single line?
2. Does it describe compliance as architecture, including access control models, audit logging, encryption, and hosting decisions, or does it dispose of it in one bullet?
3. Does it account for data migration from any system being replaced, including validation and reconciliation of historical records?
4. Does it enumerate user roles and the permission boundaries between them, or does it describe one generic user?
5. Does it include failure paths: denied claims, expired eligibility, disconnected devices, partial data, and the other conditions that make up daily reality in healthcare operations?
6. Does the timeline include structured testing and user acceptance cycles with clinical staff, or does development end at “launch”?
7. Could you hand this document to two different engineering teams and expect them to build materially the same system? If not, it is not yet a specification.

If your document fails three or more of these, the 3 month estimate inside it is describing a prototype, not your product. That is worth knowing before you sign anything priced against it.

What a Realistic Path Looks Like

Complex healthcare builds benefit from a paid discovery phase before full scoping, for the same reason a hospital gets blueprints before construction. Discovery converts the AI draft into a functional specification: validated user journeys per role, an integration inventory with confirmed technical approaches, a compliance architecture, and a feature list that engineering can actually estimate against. It typically takes a few weeks and removes the largest sources of overrun before they are poured into the foundation.

From there, honest timelines vary with scope. A focused single specialty platform with limited integrations is a different undertaking from a multi role system connected to an EHR, a clearinghouse, and device feeds, and the difference is measured in quarters rather than weeks. What matters is that the number attached to your project comes from your validated scope, not from a statistical average of internet tutorials.

The founders who fare best in this market are not the ones who avoid AI drafting tools. They are the ones who use the draft as a conversation starter, subject it to real scrutiny, and choose partners willing to tell them the timeline they need to hear rather than the one the document promised. Eighteen months planned honestly costs far less than three months promised falsely.