Key Takeaways:
- DiGA success depends on planning for regulation, not just product building
- Architecture decisions early determine whether compliance is achievable later
- Choosing experienced regulatory/DiGA partners reduces risk and rework
- BSI requirements require interpretation and can easily lead to overengineering
- Clinical evidence may need to be rebuilt for the German standard of care
- Poor UX and unclear decision ownership directly slow down or derail execution
- Market access and reimbursement are country-specific and hard to scale across borders
What do most startups misunderstand about building a DiGA product in the early stages?
Benjamin: I think one of the biggest misconceptions is underestimating how long, costly, and complex the journey is from a clinical idea to actually having a DiGA listed in the directory. Most startups in this space come from a clinical background. They’re founded by physicians or healthcare experts who deeply understand a specific indication and genuinely want to improve outcomes for patients. That vision is usually very strong.
But turning that vision into a reimbursable DiGA involves much more than building a digital product. You have to deal with medical device regulation, CE certification, clinical studies, technical compliance requirements, and relationships with authorities. And even after all of that, you still need to solve the go-to-market challenge: reaching the right physicians and getting attention in a very crowded healthcare environment.
That becomes a huge undertaking, especially if the company is focused on only one indication. At that point, investors start asking important questions about scalability. Is a single-indication DiGA enough to build a scalable business? That’s something many startups face when speaking with seed or later-stage investors.
The obvious answer is internationalization, but that creates another layer of complexity. Digital health reimbursement is still highly national. Germany is really the only market with a proven multi-year DiGA track record. Other countries, like France or Switzerland, are developing similar models, but they are still evolving and shaping their regulatory frameworks. So, unlike a typical software business, DiGA products don’t scale easily across borders. Every country requires different regulations, local partnerships, reimbursement pathways, and go-to-market strategies.
I think that’s what many startups underestimate in the beginning: it’s not just about building a good clinical product. It’s about building a company that can navigate regulation, reimbursement, and commercialization at scale.
At what point do founders usually realize that compliance decisions directly impact product architecture and timelines?
Benjamin: In most cases, founders are already aware of the medical compliance side from the beginning. What they tend to underestimate is how deeply compliance affects the digital product architecture itself.
The real challenge is usually not understanding that compliance exists, but understanding the technical and IT security requirements early enough to make the right product and partner decisions.
If a startup works with a partner that already has DiGA experience and understands the regulatory and technical expectations, then building a compliant product becomes much more predictable. In that scenario, the main bottleneck is often the clinical evidence rather than the technology. But if founders choose a development partner mainly based on price, for example, a general app development company without DiGA experience, they often realize too late that compliance requirements need to be built into the architecture from day one. That’s when timelines and budgets can quickly double or triple because parts of the product have to be rebuilt.
This realization usually happens once startups see that compliance is not a final approval step, it directly shapes the technical foundation of the product from the start.
Is it generally easier to adapt an existing app for DiGA requirements, or to design for compliance from day one?
Benjamin: Technically, adapting an existing app can be feasible, especially if it was built with a flexible architecture that allows the product to evolve over time. But from a budget and timeline perspective, it is usually far more efficient to design for compliance from day one.
A good example is user authentication. Many standard applications use common email-and-password registration systems that may be secure from a general IT perspective, but still not compliant with BSI or DiGA requirements. If you understand those requirements early, you can build the correct solution from the start instead of rebuilding core functionality later.
That’s why early architectural decisions are so important. The same applies to partner selection. In general, it is always costly to switch development partners midway through a project, because a new team first has to understand and evaluate everything that was previously built before they can continue confidently. That challenge exists beyond DiGA projects, but compliance requirements make the impact even greater.
If founders know from the beginning that DiGA is their target market, choosing the right technical partner early and designing for compliance from the start is usually the most efficient path. That said, for companies that already have an internally managed software medical device with CE certification, adapting the product for DiGA can still be very realistic. In those cases, the company already controls the architecture and can evaluate what additional work is needed to meet DiGA-specific requirements and whether the investment into the German reimbursement market makes sense for them.
Adapting an existing product is possible, but building with compliance in mind from day one is generally less costly, less risky, and more predictable.
What are the most common gaps or risks you uncover during DiGA readiness reviews?
Benjamin: Usually, the basic medical device foundation is already in place. Most companies that plan to become a DiGA are already working toward software-as-a-medical-device compliance under MDR, so that part is generally well understood and supported by established certification processes.
The bigger challenges usually appear around the Germany-specific DiGA requirements. One major area is clinical evidence. Under the DiGA fast-track process, the evidence is expected to align with the German standard of care. So, depending on where a company conducted its previous studies, they may not be able to directly reuse existing clinical data for the German market and may need additional studies.
Then there are the technical and reimbursement-related requirements that many international companies are simply not prepared for initially. That includes reimbursement workflows, integration points related to the German healthcare infrastructure, and especially the BSI IT security requirements.
The BSI requirements are often one of the biggest challenges because they define the security goals that need to be achieved, but they do not prescribe exactly how to implement them. That leaves a lot of room for interpretation. Companies can easily overengineer solutions, spend unnecessary budget, or lose significant time trying to determine what is actually sufficient for compliance.
That’s where prior experience becomes extremely valuable. Teams that have already gone through the DiGA process and received external audit feedback can usually identify much faster whether an existing setup is likely to meet compliance expectations or where the real gaps are. I’d say the biggest risks are usually not the general MDR requirements, but the specific German regulatory, reimbursement, and security expectations around DiGA readiness.
Which technical or UX decisions tend to create the biggest problems later in the Fast Track process?
Benjamin: On the technical side, I would say the biggest issue is a software architecture that is not designed to evolve over time.
If teams move too quickly early on and build something without a solid architectural foundation, that can create major problems later both from an MDR perspective, where traceability becomes important, and from a compliance perspective when additional requirements need to be integrated. If the architecture becomes too fragmented or difficult to adapt, then at some point companies may realize they can no longer realistically build compliance on top of it. And that’s when they may need to start over, which becomes extremely costly.
On the UX side, patient experience is becoming increasingly important, especially with the introduction of new patient feedback and outcome measurement requirements within the DiGA framework.
If patients are dissatisfied with how the app works, if they don’t feel comfortable using it, or if the UX is not aligned with the actual target group, that can directly affect adoption and patient feedback scores. For example, if you design an app for a very tech-savvy audience but your actual users are elderly patients, that mismatch can create real problems in engagement and usability.
And because companies are required to collect and report patient feedback regularly, poor UX can eventually have financial consequences as well. I think the biggest long-term risks are building a system that is difficult to evolve technically and underestimating how important patient-centered UX has become within the DiGA process.
From your experience, what do the teams that execute best in digital health tend to do differently?
Benjamin: I can’t really generalize across the whole digital health space, because I don’t see all sides of it. But from my experience, what makes a real difference is having empowered decision-making.
You need at least one person, typically a dedicated product owner for the digital health project, who is empowered to actually take decisions. Otherwise, you end up with a lot of delays because too much time is spent on internal alignment and stakeholder management instead of building the product.
Alternatively, if multiple people need to be involved in decisions, then the key is to keep that group as small as possible and ensure they are directly involved in the decision-making process, so decisions can be made quickly, without long iteration cycles.
In the end, it’s about reducing unnecessary feedback loops and avoiding situations where no one can make a final call. Whenever we’ve worked in setups where decision ownership was unclear, the process becomes slow and painful for everyone involved, regardless of the industry.
How has AI changed the way startups and agencies like yours approach digital health product development?
Benjamin: At the moment, I would still describe it as quite exploratory. AI is mainly used to support research and early-stage work, things like helping with ideation, summarizing large amounts of information, or getting a better overview of complex topics. In the concept and product definition phase, it can be quite helpful, especially for structuring product visions and speeding up information processing.
However, I don’t yet see strong adoption in actual product development, mainly because digital health is a regulated environment.
The key challenge is how to reliably ensure high-quality output that still meets regulatory and compliance requirements when AI is embedded into the development process. A lot of teams are exploring this, but it is still an open question how to do it consistently and safely.
So for now, I would say AI is more of a tool for exploration and support rather than something that is deeply integrated into regulated product development workflows.
Do you think AI will eventually change how DiGA products are evaluated, reimbursed, or trusted within the healthcare system?
Benjamin: AI is a very interesting technology, but it is fundamentally non-deterministic, it produces probabilistic outputs rather than fixed ones. That means it can give different results depending on how you use it.
The key question is whether we can “tame” that behavior through guardrails so that it reliably produces high-quality output. If that is possible, it could significantly accelerate product development. However, when it comes to evaluation and reimbursement decisions, I don’t think AI will fully take over.
In the German healthcare system, these decisions are closely tied to responsibility and accountability. Institutions like BfArM carry that responsibility, and it is difficult to imagine that being delegated to an AI system.
At present, I don’t see a future where AI independently decides whether a DiGA is approved or reimbursed. What I do see is AI becoming increasingly useful in supporting and informing those decisions, helping to make evaluations more consistent, reducing variability between individual reviewers, and improving the quality of decision-making overall.
In that sense, AI is more likely to become an assistive layer that strengthens human judgment rather than replacing it.
Is there something outside DiGA that startups should know about NEXT Munich?
Benjamin: There are two areas I would highlight that go beyond DiGA but are still highly relevant for teams building complex digital products.
First, we have extensive experience in building large-scale, customer-facing digital products where user experience is a key driver of product success. This includes designing mobile journeys for very different user groups and ensuring high standards in UX, reliability, data privacy, and IT security. This type of work is relevant wherever the digital product is the main interface between a user and a service, and where adoption and engagement directly determine the success of the product.
Second, we have strong experience in IoT and hardware-connected applications, including systems that use Bluetooth Low Energy and NFC. This involves designing reliable communication between hardware and software and ensuring consistent performance across devices and operating systems. This becomes increasingly relevant in digital health, especially with wearables and connected medical devices, where the interaction between software and hardware is part of the user experience.
So, while DiGA is a key focus area for us, these two domains: high-quality UX for complex consumer applications and IoT system integration are areas where we can also support teams building regulated or technically demanding digital products.
R2GConnect: Thank you very much for your insights, Benjamin.
Building a DiGA or DTx solution?
Discover how NEXT Munich combines product engineering, regulatory, and UX expertise for HealthTech teams navigating compliance, system architecture, and reimbursement requirements in the German Fast-Track process.
Explore their set of exclusive deals and service packages designed to accelerate the journey from early concept to DiGA readiness.
- Free DiGA Architecture Session – avoid costly mistakes in your product setup (60 min) - learn more here
- Free DiGA Readiness Quick Check – identify your gaps before entering the Fast Track (60 min) - learn more here
- Service Package: DiGA Kick-Start Workshop for a planned App Project - learn more here
- Service Package: DiGA Kick-Start Workshop for an existing App - learn more here The deadline to some is June 30th, 2026.