3 years in, many digital health engineering teams spend more roadmap time on rebuilds than on new features. The cause is usually the same.
When a CTO calls us in year three, the situation usually looks the same. The product is growing, the team is stretched, and a closer look at the roadmap shows that a significant share of it is fixing infrastructure from the first build: auth that can’t support SSO, a database that blocks an upgrade, a FHIR adapter written in a sprint that now handles production traffic it was never meant for. The decisions that created this were made years earlier, under pressure to ship, without asking what the product would need once it grew.
Table of Contents
The codebase that can’t move forward
Take Kipinä. We were brought in to take over a mobile application and its backend from a previous team. The handover looked straightforward. What we found was a codebase where adding features broke existing ones, and the infrastructure choices that had made sense at launch had become blockers.
The previous team had delivered. Their architecture, though, couldn’t be extended without breaking what was already there. We rebuilt the backend, mobile application, AWS infrastructure, and video processing pipeline from scratch. The product works now, and the rebuild that got it there was avoidable.
The database decision that costs you in year three
When mySugr needed to migrate from Aurora MySQL to PostgreSQL, the original database choice wasn’t wrong. The problem was that nobody had asked, years earlier, what would happen when the infrastructure had to change. After integration with Roche and AWS releasing Aurora 3, the question became unavoidable.
The migration covered a live product with 1.8 million active users: schema redesign, reconciling MySQL’s lenient SQL standards with PostgreSQL’s stricter approach, DateTime precision mismatches, CDC synchronization across both databases simultaneously, and more than two months of QA verification before the production switch. The switchover itself took 2.5 weeks of real risk on a live medical application.
In regulated healthcare, a normal database migration is expensive, slow, and almost always the consequence of an early choice nobody revisited until it became urgent. The full case study shows how the team handled it, what it cost in time and risk is the more useful read.
From MVP to scalable platform: what breaks first
When 9am.health came to us, the goal was clear: build a virtual diabetes clinic with online prescriptions, at-home lab testing, medication delivery, and specialist consultations. The MVP had to work, and it also had to be the foundation for something much larger.
The gap between those two requirements is where the expensive architectural decisions get made. How prescriptions are authorized and tracked, how lab results flow between systems, how logistics integrates with clinical data, how audit trails are structured for regulatory purposes, these look like implementation details at MVP stage. Build them wrong and the rebuild happens while the product is live, with a team that’s also trying to ship new features.
Why MDR and HIPAA compliance can’t be retrofitted
In most software categories, getting the authentication layer wrong means an expensive refactor. In a regulated medical application, it means a compliance gap you can’t close without restructuring the systems around it.
Data residency requirements, access control models, and audit log formats need to be part of the initial schema design. MDR, HIPAA, and ISO 27001 don’t prescribe specific technologies, but get those structural decisions wrong early and compliance becomes very difficult to achieve after the fact.
We’ve seen products where audit logging was treated as a post-launch feature. Implementing it properly, with the data model, access controls, and retention policies certification required, took months. The team was doing that rebuild while maintaining the product and moving the roadmap. Features slipped by quarters.
The question to ask before you commit to any architecture
Before settling on a database choice, an integration pattern, or an access control model, ask what it looks like when the product has ten times the users, goes through an acquisition, or needs to pass a certification audit. Not every scenario will apply, but the ones that do will determine whether your engineering team spends year three building new features or rebuilding the foundation.
The products in our portfolio that have scaled cleanly are the ones where those questions were asked before the first sprint.
If you’re starting a healthtech product or hitting the first real scaling wall on an existing one, we’re happy to talk through what’s worth getting right before it becomes expensive to undo. Let’s talk.
