The Bill After Launch: Budgeting for Patient-Facing Digital Services Beyond Year One

Launching a patient portal usually feels like crossing a finish line. Then comes the announcement, a jump in sign-ups, and a project team that moves on to the next priority. Twelve months later, the finance director opens a cloud invoice, a penetration test quote, and a request to rework the booking flow after an accessibility audit, and asks why a finished product is still costing money.

The short answer is that patient-facing software is never finished. Planning guides for healthcare web development typically put running costs at 15–25% of the original build every year, and that range holds on both sides of the Atlantic. What differs between the US and the UK is where the money goes. Organisations that budget for it from the start avoid an awkward conversation in year two. Those that don’t tend to cut the very things that keep patient data safe.

Why Year Two Catches Budgets Out

The people who build and run budgets rarely overlap. A build is approved as a project with a start and an end date. What follows lands on an operating budget that nobody sized. In healthcare, three things widen that gap further than in most sectors.

First, the software stays regulated for as long as it runs. Compliance isn’t a launch milestone; it’s a recurring cost with annual deadlines. Second, patient-facing services sit on top of systems that keep changing beneath them: electronic health records, identity services, payer and national APIs. Third, failure is unusually expensive. IBM’s Cost of a Data Breach Report 2026 put the average healthcare breach at $6.64 million, still the highest of any industry and well above the $4.99 million global average.

The 15–25% figure is more than vendor folklore. Even outside healthcare, a 2026 benchmark of 24 maintained software products by Wavect found median annual maintenance spend of 24% of build cost in year one, 21% in year two, and 26% in year three. The shape matters as much as the number. Year one is costly because defects surface under real use—year two dips. Year three climbs again as upgrades, integration changes, and compliance evidence pile up.

Where the Money Goes After Launch

Hosting, monitoring and on-call

Hosting is the line everyone expects, and it is rarely the biggest. The part that gets missed is monitoring: uptime and error tracking, failed-login alerts, stalled interface queues, and someone on call to act on them. A service that patients use at 8 am on a Monday needs an alert someone actually reads.

Both markets also narrow your infrastructure options. In the US, every cloud service that touches protected health information must be covered by a business associate agreement (BAA). In the UK, NHS buyers usually expect UK-region hosting, with backups and logs included. Neither constraint disappears after launch, so cheaper services cannot simply be swapped in later.

Security testing that recurs

Most organisations commission a penetration test before go-live. Far fewer budget for the second one. The current HIPAA Security Rule asks for periodic evaluation without naming a test or a frequency. HHS’s proposed update, published in January 2025, would require penetration testing at least every 12 months and vulnerability scans every six months. It is still not final, and the federal regulatory agenda now points to July 2027. Many US health systems already ask suppliers for an annual test, so the cost tends to arrive either way.

In the UK, NHS procurement routinely expects Cyber Essentials and penetration testing. Every test also produces findings, and fixing them takes development time that has to come from somewhere.

Compliance that renews every year

This line item most often goes missing. In the UK, any organisation with access to NHS patient data or systems completes the Data Security and Protection Toolkit (DSPT) every year, with submissions due by 30 June. The Digital Technology Assessment Criteria (DTAC) moved to a new form from 6 April 2026, and suppliers are expected to keep an up-to-date form and supporting evidence for each product version. A significant release can therefore mean fresh assurance work. Clinical safety under DCB0129 adds a hazard log that stays open for the life of the service and is maintained by a named Clinical Safety Officer.

In the US, the HIPAA risk analysis should be revisited whenever the system or its environment changes significantly. The BAA register has to keep pace with every new vendor, and many enterprise buyers ask for SOC 2 or HITRUST evidence that renews on its own cycle. None of this is engineering. All of it consumes engineers’ time when auditors ask how something works.

Integration drift

A patient portal is only as current as the systems it reads from. EHR vendors ship upgrades, wearable manufacturers change device APIs with little warning, and national programmes add new services.

In the US, impacted payers must have Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs in production from January 2027 under the CMS-0057-F rule, and provider-facing tools will need to keep pace with them. In England, NHS England’s July 2026 plans include AI triage in the NHS App and a Single Patient Record. Services connected to NHS login and national APIs will have to absorb both. Each change means regression testing, sometimes re-onboarding, and occasionally rebuilding a screen that worked perfectly well last year.

Accessibility and usability upkeep

Accessibility is not a one-off audit, because every new form or content update can break it. US providers that receive HHS funding now have until 11 May 2027 to meet WCAG 2.1 AA under Section 504 if they employ 15 or more people, and until 10 May 2028 if they are smaller. NHS bodies already work to WCAG 2.2 AA. Budget for an annual assistive-technology review and the fixes that come out of it, rather than treating the launch audit as the end of the matter.

Support and adoption

Patients forget passwords. Carers need proxy access set up, changed, and eventually removed. Front-desk staff field questions about results and messages. Someone has to unlock accounts, correct proxy links, and answer “where is my test result?” Without a proper admin console and a support budget, those requests flow to developers, which is the most expensive way to handle them.

What a Year-Two Budget Can Look Like

Take a mid-sized patient portal with booking, results, secure messaging, and proxy access over one EHR connection, built for around $250,000 in the US or £200,000 in the UK. At 20% a year, that is roughly $50,000 or £40,000 annually. The split below is an illustrative planning model, not a quote. The proportions shift with the number of integrations, user roles, and regulators involved.

​

Two things sit outside this table on purpose. Licence fees for video or messaging vendors belong in their own line. New features belong in a separate roadmap budget. Mixing features into maintenance lets a security patch compete with a stakeholder’s wish list, and the patch usually loses.

Five Ways to Avoid the Year-Two Surprise

1. Price the run alongside the build. Ask every supplier for a three-year total cost of ownership, not just a build quote. A team that cannot say what year two costs has probably never operated a healthcare service.
2. Ring-fence compliance. Give the DSPT, DTAC evidence, HIPAA risk analysis, and BAA register a named owner and a named budget line. Put the 30 June DSPT deadline and the annual penetration test in the same calendar as the finance cycle.
3. Separate maintenance from new features. Agree in writing what “keeping it running” covers: patches, defect fixes, integration updates and compliance evidence. Fund everything else through the roadmap.
4. Design for cheaper operations. An admin console for support staff, automated accessibility checks in the release pipeline, and infrastructure defined as code all cost a little more at build and save money every year after.
5. Read the regulatory calendar early. The HIPAA Security Rule update, the Section 504 dates, and the CMS payer API deadline are already public. Budget for them in the year they land, not the year after.

The Takeaway

A patient-facing digital service is a commitment, not a project. Setting aside 15–25% of the build cost every year can feel like a tax on something that already works. In practice, it keeps the service running, keeps auditors satisfied, and keeps patient data out of next year’s breach statistics. Organisations that plan for year two in the business case tend to have a much easier year five.