Most teams schedule approval as the last block on the plan. It isn't a block on the plan. It's a set of constraints on the data model, and it decides things you thought were yours to decide.
A telehealth platform is a deceptively normal-looking product. Users book appointments. A clinician turns up, physically or on video. Something gets prescribed. Someone pays. Viewed as software, it's a booking app with a video call bolted on, and a competent team will estimate it that way.
Then the health authority asks its first question, and the estimate stops meaning anything.
This is a write-up of a platform built from zero across Dubai, Abu Dhabi and Al Ain — roughly eighteen months to launch, taken through the full health-authority approval process, then handed to the client's own team to operate. It is still on both stores and still rated five stars regionally, years after we left.
The interesting part isn't the feature list. It's which decisions turned out not to be ours.
The surface area, so the rest of this is concrete:
iOS and Android, both built for real use rather than as a wrapper around a web view.
The instinct on a build like this is to treat approval as a gate at the end: construct the product, then compile a submission describing it. That sequencing feels efficient and it is the single most expensive mistake available.
The reason is that approval questions are rarely about features. They are about properties of the system — and properties are decided by architecture, early, quietly, usually by someone who didn't realise they were deciding anything.
Consider what a regulator is actually protecting against. Not a bad UI. They are protecting against a prescription issued by someone unqualified, a consultation that cannot later be shown to have happened, a patient who never meaningfully consented, a record that was silently edited, a sample that cannot be tied to the person it came from.
Each of those maps to a structural property, and each one is hostile to the way most application code is written by default.
Take the mildest of those: auditability. A team that didn't plan for it stores current state and updates in place, because that's what every framework tutorial demonstrates. When approval asks for a reconstructable history, the events needed to build one were never written down. They weren't lost — they never existed.
You cannot patch that. There is no migration that recovers information the system declined to record. You change the data layer, and everything above the data layer moves with it.
Retrofitting compliance isn't adding a feature. It's discovering that the foundation was poured for a different building.
There is a constraint on this kind of build that is not written in any regulation, and it is the one that decides whether the project was actually a success: the client has to be able to run it without you.
This gets treated as a documentation task at the end. It isn't. A system that only its author can operate has failed in a way that shows up eighteen months after launch, when a regulation shifts or an OS release breaks something and the only person who understands the approval-sensitive parts is no longer available at any price.
Handover-readiness, like auditability, is a property rather than a phase. It means the approval-relevant logic is legible and located where someone would look for it, rather than distributed through clever code that made sense at the time. It means the reasoning is written down — not just what the system does, but which decisions were made to satisfy the authority, so the next engineer doesn't casually optimise one away.
That last point is the one I'd underline. In a regulated system, a fair number of design decisions look like inefficiencies to anyone who wasn't in the room. An undocumented compliance decision has a short life expectancy: the next competent engineer will see redundant work and remove it.
The rating matters less than the durability. Plenty of software launches well. Far less of it is still doing its job years after the team that built it walked away — and in regulated healthcare, still doing its job includes still satisfying the body that approved it.
The generalised version, in the order I'd work through it:
You can submit afterwards. You will usually rebuild parts of it. The properties approval cares about — attribution, immutability, reconstructable consent — are structural, and code written without them didn't record the information you'd need to demonstrate them. That's a data-layer rewrite, not a patch.
The specific questions and the body asking them change by market and by year — that part genuinely needs local, current advice, and anyone who tells you otherwise from a blog post is guessing. The structural properties do not change. Every regime I've worked under wants to know who did what, under what authority, with what consent, and whether the record can be trusted.
For the feature list alone, it would be. The duration came from sequencing build against approval, where each answer can send you back into the architecture. Compressing that is possible, but you compress it by getting the questions earlier — not by writing code faster.
Push harder, earlier, for the authority's actual questions rather than working from the published framework. Most of the expensive reopenings in a build like this come from a reasonable reading of a document that turned out not to be how the requirement is applied in practice.
If you're mid-build and approval questions are starting to land, send them over with a sketch of your data model. I'll tell you in a paragraph which ones are architecture problems and which are paperwork — the distinction is worth knowing before you start rewriting.
Start there →