Key Takeaways:
- MVP scope determines long-term product stability and development speed
- AI accelerates development but never replaces regulatory discipline
- Requirements, traceability, and quality processes should start from day one
- Legacy code often limits better product decisions and innovation
- EHR integrations are workflow challenges, not just API integrations
- Underestimating regulatory complexity is a major founder mistake
In healthtech, what are the most common reasons Minimum Viable Product (MVP) development slows down after the first prototype?
Evghenii: Typically, this happens because the MVP was not scoped correctly during the prototyping stage. I’m not saying it was scoped wrongly, but it may have been under-scoped or mis-scoped.
As a result, once the MVP is released, the amount of change required is often far more fundamental than originally expected. The core assumptions or architecture may need to be revisited, which can significantly slow down further development.
We've seen cases where early MVPs focused on more on secondary features which were really nice, but once real clinical workflows were introduced, the data model had to be redesigned significantly. That’s why it’s important to scope the MVP in a way that preserves the fundamental elements of the software or platform and make sure it delivers the value. Ideally, those foundations should remain untouched as the product evolves.
The key is to align the MVP scope with the vision for the final product, ensuring that the functions implemented and tested within the MVP support the long-term direction of the platform.
Building on that idea of foundations and discipline in early development, how do you balance rapid AI-assisted development with regulatory and Verification and Validation (V&V) readiness in healthcare products?
Evghenii: I believe that AI-assisted development should not fundamentally change the way software development is carried out in healthcare. The fact that development is supported by AI should not be a reason to skip any phases or steps of the software development lifecycle, especially in a highly regulated environment such as healthcare, medtech, or healthtech.
In fact, we’ve seen that the teams that balance speed and compliance and understand what tasks can be delegated to a guard railed AI are more successful in terms Time to Market values. AI can accelerate many aspects of development, but the responsibility for ensuring quality, compliance, and regulatory readiness remains with the people overseeing the process.
Even in cases where development is heavily automated and multiple AI agents are working in parallel, it is important to ensure those agents are orchestrated in a way that fully reflects the intended software development lifecycle. The key is to make sure that all required process steps, including those related to verification, validation, and compliance, are consistently followed. Ultimately, we help team make sure AI can help accelerate development, but it operates within the same disciplined framework required for regulated healthcare products.
For early-stage healthtech startups, what should founders prepare before involving AI in software development workflows?
Evghenii: Requirements is the key. Teams that better define requirements, scope, and processes, get more stable and predictable development outcomes. This is also well aligned with the expectations set by regulatory frameworks that healthtech and medtech companies must follow.
Founders should not assume that AI will handle these aspects for them. AI is there to accelerate development, not to replace the discipline required to build regulated software.
In that sense, it is important to first establish a proper process and a quality management system around your software development lifecycle. Only after that should you decide where and how AI can be introduced to assist the work. Make sure you have enough resources and expertise to do so.
What are the biggest risks you see when startups inherit legacy codebases or unfinished Minimum Viable Products (MVPs)?
Evghenii: The biggest risk is that the startup becomes a hostage of the existing codebase.
Instead of focusing on what the product should actually do, its purpose, intended use, and who the users or patient population are, teams can end up concentrating too much on preserving what already exists. The thinking becomes: “We already have some legacy code, so let’s reuse it and avoid rewriting it.”
With AI-driven development, this mindset becomes even more important to challenge. While AI makes it faster to write or rewrite code, the real question is whether there are sufficient specifications and requirements to guide what should actually be built. In short, the risk is becoming trapped by legacy code rather than designing around the outcomes the software is meant to deliver. The focus should remain on the value the product brings to users, not on the codebase itself.
In some cases, especially in large enterprises, we also use “clean room development” approaches to address this challenge, where the goal is not to blindly reverse-engineer legacy systems, but to observe what the software actually does and rebuild it in a controlled way, often supported by modern tooling, including AI.
Following that thread of structure and control, how early should healthtech companies think about requirements traceability and regulatory documentation?
Evghenii: From day one. The longer you postpone thinking about regulatory requirements and requirements traceability, the more risk you introduce into the future development and compliance process. Not passing through regulations or significantly delaying it becomes a blocker for the product and drains the resources, shortening the runway.
That said, the approach also depends on the maturity of the idea. If you are still at the stage where you are unsure whether the concept will survive clinical validation or whether it will deliver meaningful value through a medical pathway, then the first priority is to validate that value.
However, if you are confident that the value exists and the challenge is primarily in building the software, then you should start thinking about quality control and regulatory alignment from the very beginning.
Successful founders don’t see quality only as a regulatory obligation. Regulations help ensure that the product is actually capable of delivering the value and outcomes the startup claims. So, the short answer is, again: from day one.
Zooming out from process and regulation, where do you see AI creating the biggest practical impact for healthtech companies today beyond just faster development?
Evghenii: In a broader sense, AI is impacting almost everything. First of all, it is transforming the software development process itself, which is what we are discussing here.
Then, as a second step, AI features can be embedded directly into the product itself, that is a separate and major topic that we at Virtual Nomad specialize in. Beyond that, AI can also be integrated into go-to-market strategies and operations. Practically every part of a healthtech startup lifecycle can be influenced by AI: technical development, legal, marketing, sales, and internal workflows.
The main question becomes whether a company has enough resources, expertise, and capacity to truly embrace this AI-driven approach across all these areas. If we look at it from a slightly different angle, one of the most immediate practical impacts is actually in expectations. AI has become something everyone talks about, and in many cases, hospitals and healthcare practitioners now expect AI to be present in some form even if the meaning of “AI” varies widely.
At the patient level as well, we see increasing trust in AI systems, sometimes in ways that are not always beneficial for patients themselves. So, beyond the technology itself, one of the biggest real-world impacts of AI today is the shift in expectations and perceptions across the entire healthcare ecosystem.
We see that the major success comes when the startups can keep up with their promises to the customers, and when the use of AI is made organically, and not just by adding “chats” in random places of the software.
Bringing the discussion closer to real-world deployment, what technical or compliance challenges usually surprise startups when integrating with EHR/EMR systems?
Evghenii: What often surprises startups is that health record management systems do not exist in a vacuum.
Even though there are a limited number of vendors and the systems may appear functionally similar on the surface, each deployment within a hospital or across a group of hospitals can be very different. This is largely due to differences in internal workflows, organizational constraints, and other operational factors that shape how the system is used.
As a result, it is not enough to assume that integration will work simply because an API exists. The reality is that the workflows inside each organization vary significantly, and integrations must be adapted to those specifics each time.
This creates a key decision for startups: whether to invest heavily in building highly flexible integration layers that can cover most possible scenarios, or to build more generic connectors and adapt them case by case during implementation.
There is no universal answer, as it depends on the nature of the software and how deeply it is embedded into patient workflows. However, the biggest surprise for most startups remains the same: every EHR implementation is different, even when it is the same platform.
What mistakes do you see founders repeatedly making in the first version of AI-enabled medical software?
Evghenii: It often starts with not fully knowing what the first product version should actually do.
In fairness to founders, I would not always call this a mistake - it is quite normal not to have a fully defined product at the beginning. The challenge comes when teams do not expect that their initial vision will evolve or pivot. It is rare for the first concept to remain unchanged throughout the lifecycle of a healthtech startup.
One common issue is not properly considering the relationship between the value the product is supposed to deliver and the complexity required to achieve it whether technical, regulatory, or operational. These dimensions are often underestimated.
Another frequent gap is underestimating timelines and effort, especially in regulated environments. New founders in healthtech may not anticipate the length of validation cycles, verification requirements, certification processes, or even the differences between regulatory jurisdictions. For example, assuming that launching in the UK and across EU markets follows the same path is a common misconception. Overall, it is this combination of factors: unclear product definition, underestimated complexity, and regulatory expectations that creates the most recurring challenges in early versions.
There are ways to mitigate this by refining the product vision early, clearly defining MVP scope, and testing workflows and value delivery as early as possible. At Virtual Nomad we have a service designed specifically for that – it helps define the scope and the vision of the product in days.
AI is now helping significantly in this area. It allows teams to iterate and test ideas much faster without sacrificing process quality. What used to be an expensive trial-and-error cycle is now considerably cheaper, even compared to just a few years ago. That is one of the most important practical benefits AI brings to early-stage product development in healthtech.
R2GConnect: Thank you very much for all the insights, Evghenii.
Building regulated HealthTech software or AI-enabled products?
Virtual Nomad supports founders and product teams in turning early-stage ideas, MVPs, and existing systems into scalable, V&V-ready HealthTech software, while keeping AI acceleration aligned with regulatory discipline, traceability, and real clinical workflows.
Explore two focused workshops designed to help teams reduce delivery risk and move faster without compromising compliance or product quality.