Building a regulated health product in Austria means navigating ELGA, MDR, and EHDS before writing a single line of code. Here’s what separates the right partner from an expensive lesson.
A healthcare software development partner for an Austrian digital health startup should have production experience with ELGA integration, working knowledge of EU MDR software classification, and awareness of the EHDS 2029 deadline. Same-timezone availability (CET/CEST) and German-language capability in the development team are practical requirements. Poland-based nearshore teams typically cost 60–70% less than equivalent in-house hiring in Vienna, with no coordination overhead from timezone differences.
What follows is what we’ve learned through our healthcare startup software development practice from mySugr (Vienna, acquired by Roche), 9amHealth (Vienna, scaling across the US and Europe), Selfapy, and Mentalyc. All in regulated environments where a wrong release is a liability, not an inconvenience.
Table of Contents
What makes austria different from standard healthtech markets
Austria runs one of Europe’s most developed electronic health record systems. ELGA covers approximately 97% of the population and serves as the integration backbone for most clinical applications in the country. If your product touches patient data, a care pathway, or any clinical workflow, ELGA is the baseline, not an optional integration.
Three regulatory layers define what it costs to build for Austria. EHDS, the European Health Data Space, has a hard operational deadline of March 2029, meaning products built today need EHDS-compatible data architectures or they’ll require expensive rework before that date. If your software qualifies as a medical device, EU MDR applies, and MDR compliance cannot be added after the fact: risk management, QMS documentation, and clinical evidence requirements need to be built into development from the start. Austria’s data residency requirements are also stricter than the European average, which shapes cloud infrastructure decisions from day one.
mySugr, founded in Vienna in 2012 and acquired by Roche in 2017 in a deal valued at an estimated $75–100 million, served over 1 million active users across 52 countries at acquisition. That scale was built on architecture that treated Austrian and EU regulatory requirements as design constraints, not post-launch tasks.
What criteria matter when choosing a healthcare software development partner for Austria?
Most founder conversations about dev partners start in the wrong place: technology stacks, hourly rates, team size. Those matter, but they don’t predict whether a partnership works. The questions that actually separate good partners from expensive mistakes are harder to ask and easier to deflect.
| Criterion | What to look for | Red flag |
|---|---|---|
| ELGA / FHIR experience | Production integrations, not theoretical knowledge of the spec | „We can learn it” or „we’ve done HL7 before” (without FHIR specifics) |
| MDR fluency | Can they classify your software and discuss risk management? | Confusing MDR with GDPR, or „we handle compliance separately” |
| EHDS readiness | Awareness of the 2029 timeline and what it means for data architecture | Haven’t heard of it, or treat it as a future problem |
| Regulatory documentation | QMS processes, risk management artifacts, evidence of regulated project delivery | „We document as we go” |
| Nearshore practicalities | Same timezone (CET/CEST), DACH references, German proficiency in the team | Fully async only, no Central European clients in portfolio |
The compliance conversation filters fast. Teams without regulated healthcare experience treat compliance as a documentation task, something done alongside development, or after. It shapes architecture from week one. When 9amHealth came to us in 2021 with no product yet built, the decisions made in the first two weeks – how data was structured, how user identity was handled, how services were separated, were all determined by the regulatory environment the product would eventually operate in.
Questions to ask a development partner before signing
A good partner answers these without hesitation. Vague answers tell you as much as specific ones.
„Can you walk me through how you’d classify our software under the EU MDR?” The answer should reference specific MDR annexes, MDCG guidance documents, and the criteria that determine Rule 11 applicability for software. Teams that have done it know the specifics. Teams that haven’t describe the framework in general terms.
„Have you built ELGA integrations in production? What was the hardest part?” The ELGA spec and the reality of production integration are two different things. Anyone who’s built it has a specific answer: eCard infrastructure behaviour, CDA document handling, or the FHIR migration currently underway in Austria’s health infrastructure.
„How do you maintain regulatory documentation in an agile process?” Agile development and MDR-compliant documentation are compatible, but they require explicit process design. You want to hear how risk management artifacts are maintained across sprints – not „we’re flexible.”
„What happens when the product direction changes mid-build?” We built with 9amHealth for three years through a full B2C-to-B2B pivot. The architecture adapted, and so did the working relationship. When co-founder and CTO Bernhard Schandl later started a new company, his first call was to us — not because of elegant code, but because we understood his product and kept moving when the roadmap changed.
„Returning to work with fireup.pro was the natural next step when I started my new startup.” Bernhard Schandl, Co-Founder & CTO, 9amHealth
„Who on your team speaks German, and how does that shape daily collaboration?” For DACH-market products, German proficiency in the development team is a practical asset. Regulatory documents, user research, and stakeholder conversations happen in German. A team that participates directly reduces friction at every stage.
Nearshore from Poland: What it actually means for an austrian startup
Poland is the largest nearshore software development market serving Central Europe. For Austrian healthtech startups, the geography works: the timezone is CET in winter, CEST in summer, identical to Vienna, so there are no scheduling problems for standups, design reviews, or incident calls.
The cost difference compared to building an in-house team in Vienna is typically 60–70%, depending on seniority and specialization. For a seed or Series A startup, that difference has a direct effect on how many months of runway convert to working product.
The more important question is whether a specific Polish team has done this specific type of work. Our team is 50 senior developers with an average of 10 years of professional experience and five years of tenure at the company. That stability matters in healthcare: the developers who understand your domain, your architecture, and your compliance requirements are still there 18 months in.
Our healthcare clients – mySugr, 9amHealth, Selfapy, Mentalyc – are on Clutch with verified reviews. We have a 5.0 rating and 100% client retention. Every digital health client we’ve started working with has continued the collaboration.
The compliance trap that costs Austrian startups 6 to 12 months
A founder gets early product-market fit signals, raises pre-seed or seed, and hires a team focused on shipping fast. Compliance gets scoped as a separate workstream, something to address before the Series A, or the first clinical pilot. Twelve to eighteen months in, a regulatory consultant does a first assessment and finds that half the architectural decisions made in the first three months would need to be undone to meet MDR requirements.
What MVP development for a healthcare startup actually requires is different from a standard MVP build, and most general-purpose teams don’t know that until it’s too late. The cost of reversing early decisions – in time and delayed market entry – almost always exceeds what it would have cost to build correctly from the start.
When we worked with Selfapy, we inherited a codebase weeks before a critical BSI certification deadline. The previous mobile developer had left. We had one month to understand an unfamiliar React Native codebase, run penetration testing, internationalize the app across three languages, and deliver three versions on schedule. 120+ BSI requirements met, zero days of delay. That project would have been routine if the security architecture had been considered during the original build.
The same applies to ELGA. Teams that design data models without accounting for CDA document structure, or build identity flows without considering eCard, end up in costly rework cycles. We’ve written in detail about how ELGA integration actually works in production – the CDA-to-FHIR migration path, eCard identity handling, and what the EHDS 2029 deadline means for architectures being built today.
For Mentalyc, a HIPAA-compliant AI platform for therapy note automation, we built a complete QA framework from scratch: Playwright, Cucumber BDD, Docker, and GitHub Actions. Test cycle time dropped from several hours to 24 minutes.
„We did it while the car was still on the racetrack – in motion!”
– Karl Spies, Backend Developer, mySugr
That framework didn’t exist because Mentalyc had a compliance problem. It existed because in a regulated environment, „works on my machine” is not a release criterion.
What the first conversation should look like
A development partner worth working with spends the first conversation asking questions, not presenting a proposal. They want to understand your stack, your regulatory classification, your data model, and where your team is losing time. A vendor who opens with a capability deck is telling you something.
We’ve built for mySugr and 9amHealth – both Vienna-based startups that went from early product to significant scale in the DACH market. If you’re evaluating development partners and want to know whether our experience maps to your situation, that’s what the first conversation is for.
