Why MedTech startups need a scalable stack from day 1
In a regulated device business the architecture decisions are compliance decisions. What MDR, IEC 62304 and interoperability require before the first release.
Most startups can defer architecture decisions and refactor later. A medical device company cannot, and the reason is not technical.
In a regulated device business, the architecture is part of the submission. Changing it after clearance means re-documenting, re-verifying and sometimes re-submitting — so a decision that would be a two-week refactor elsewhere becomes a regulatory event here.
That asymmetry is why “we will fix it when we scale” does not transfer to this industry.
1. Scalability here means auditability, not just throughput
The usual scalability conversation is about load. In a device business the scaling that bites first is evidence.
Every release needs traceability from requirement to test to result. That is manageable by hand for the first submission and becomes the bottleneck by the third, when a small team is maintaining a matrix by hand alongside building the product.
What to put in place before it hurts:
- Requirements, risks and tests linked in a tool rather than a spreadsheet
- Traceability generated from the pipeline, not assembled before an audit
- Every build reproducible from a version-controlled source
Under IEC 62304 the software lifecycle documentation is a deliverable. Producing it as a by-product of delivery costs a fraction of producing it as a project.
2. MDR compliance is a design constraint, not a phase
The EU MDR — and IVDR for diagnostics — changed what software-containing devices have to demonstrate. Two consequences shape the stack directly.
Post-market surveillance needs data you have to collect. The regulation expects ongoing evidence of real-world performance. If the product cannot report usage and incidents in a structured way, that evidence is gathered manually, forever. Designing telemetry in from the start is cheap; retro-fitting it to a cleared device is not.
Changes have to be classified and justified. A change pipeline that cannot distinguish a documentation fix from a functional change makes every release a full regulatory exercise. Separating them in the architecture — and in the release process — is what keeps iteration possible after clearance.
For Swiss companies there is a further wrinkle worth planning for: the Swiss regulatory route and the EU route are related but not identical, and a product intended for both markets carries both sets of expectations.
3. The device is one part of a system
Increasingly the product is not a device but a device plus an app, a cloud backend, a clinician interface and an integration into hospital systems. That shifts the engineering problem from firmware to distributed systems, and it brings data protection with it.
Under revDSG/nDSG for Swiss data and GDPR for EU data, health data carries the strictest handling requirements there are. Two decisions belong in the architecture rather than in a policy document:
- Where data is processed, and who can reach it. These are separate questions, and the access half is what gets audited. A Swiss or EU region setting is not an answer to the second.
- How little personal data can the system hold and still work? Pseudonymisation and aggregation at the point of collection reduce obligation permanently. It is the cheapest compliance decision available and it has to be made early.
4. Interoperability is where clinical value actually appears
A device that produces data nobody can use in a clinical workflow produces reports, not outcomes. Interoperability is what turns one into the other, and it is standards work rather than integration work.
The relevant ones are HL7 and FHIR for clinical data exchange, and DICOM where imaging is involved. These carry over unchanged from any market — they are international standards, not regional requirements.
The practical advice: design your internal data model so it can express the standard, even if you do not expose the interface yet. Retro-fitting a standards-compliant model onto a proprietary one is one of the more painful migrations available, and it always arrives as a customer requirement with a deadline.
5. Cloud-native, with the residency question settled first
Cloud-native is the sensible default, with one ordering constraint specific to this sector: decide residency and access before choosing services, not after.
Health data under revDSG and GDPR constrains which managed services are usable. A managed backend that processes in a jurisdiction you cannot accept is not a configuration problem — it is an architectural one, and reversing it after the data model depends on it is a rebuild.
What tends to work for a Swiss MedTech startup:
- Health and personal data in a Swiss or EU region, with contractual limits on support access
- Non-production environments entirely separate, with synthetic or pseudonymised data — never a copy of production
- Logging and audit trails treated as regulated artefacts, retained deliberately rather than by default
- A documented exit path, because hospital and insurer customers ask for one
What to decide before the first release
Six decisions that are cheap now and expensive after clearance:
- Where health data is processed, and who can access it
- How much personal data the system genuinely needs
- Whether the data model can express HL7/FHIR
- How traceability is produced — generated or assembled
- How a documentation change is distinguished from a functional one
- What telemetry post-market surveillance will need
None of these requires a large team. All of them are harder to change later than any other decision on the roadmap.
Related reading
- Top five digital priorities for medical device companies
- Zeus Bioscience — MedTech/IVF, regulated context
- Software engineering
If you are making these decisions now, book a call. No obligation.