Q&A: “Build something healthcare can trust” A conversation on breaking into health tech

The UK health and social care sector is awash with digital health startups, each promising to fix an overstretched NHS through some combination of artificial intelligence, data analytics, and sleek user interfaces. But for every success story, there are dozens of products that never make it past the pilot phase technically sound, perhaps, but unable to navigate the complex realities of clinical adoption, procurement, and trust.

Maksim Mishin is trying to solve the problem that sits beneath most of those failures. Since July 2024, he has been building HOBA, a data engine that takes raw laboratory test results and turns them into structured, AI-ready medical data, with a particular focus on women’s health and digital health platforms.

With a background in data engineering and AI systems, Mishin brings a technical and deeply practical perspective to the challenges facing health tech founders. We sat down with him to explore the most pressing questions facing any entrepreneur looking to make a genuine impact in health and social care.

We are in an era of intense tech development affecting health and social care. How can a startup make their solution stand out rather than getting buried in the noise?

The first thing is to avoid selling “technology” as the product. Healthcare does not need more dashboards, more apps, or more AI claims. It needs solutions that remove real friction from clinical, operational, or patient workflows.

A startup stands out when it can clearly explain three things: what problem it solves, who has that problem today, and what measurable improvement it creates. In health and social care, credibility matters more than hype. If a solution can show better data quality, reduced manual work, improved access to information, or better patient stratification, it becomes much easier to take seriously.

The strongest startups are usually not the loudest ones. They are the ones doing the difficult infrastructure work underneath the visible product.



How can medtech startups secure funding to develop their solutions, especially in the UK?

Funding depends heavily on the stage of the company. At the earliest stage, founders usually need to show a clear problem, a credible team, and evidence that the market actually wants the solution. That evidence can be pilots, letters of intent, early customer conversations, clinical advisors, or a working prototype.

In the UK, medtech startups should understand the full landscape around grants, accelerators, innovation programmes, angel investors, and sector-specific venture funds. But funding is not just about having an interesting idea. Investors want to know whether the product can be adopted in a system like the NHS, whether procurement is realistic, whether regulation has been considered, and whether the business model works.

A strong technical product is not enough. The startup must also show that it understands the healthcare system it is trying to enter.

What are some of the biggest issues a startup may face breaking into health and social care?

The biggest issue is that healthcare adoption is slow for good reasons. You are dealing with patient safety, regulation, clinical trust, procurement, data protection, integration with existing systems, and overstretched teams.

Another major issue is data quality. Many startups build AI or analytics tools assuming that healthcare data is clean and ready to use. In reality, data can be fragmented, inconsistent, unstructured, stored in PDFs, spread across systems, or missing important clinical context. If the input data is weak, the output will be weak too.

This is especially important in areas such as lab diagnostics. A lab value is not just a number. It depends on units, reference ranges, sex, age, timing, clinical context, medications, hormonal state, inflammation, and many other factors. If this context is not structured properly, adding AI on top can create false confidence rather than better decisions.



In an already competitive field, how can you protect your innovative idea from being stolen or plagiarised?

Ideas are usually not the real defensibility. Execution is.

In medtech, the defensible part is often the combination of domain knowledge, validated workflows, data models, clinical logic, integrations, regulatory understanding, and customer relationships. A competitor can copy a pitch deck. It is much harder to copy years of accumulated understanding about how the data behaves, where the errors appear, how clinicians actually work, and what customers are willing to adopt.

Of course, startups should still use NDAs where appropriate, protect their code, document their IP, and consider patents or trademarks if relevant. But the best protection is building something deeply useful, technically hard to reproduce, and grounded in real-world healthcare complexity.

If your product performs well in R&D, how do you stop investors losing interest during the procurement and deployment stage?

You need to show investors that you understand the difference between product validation and market adoption.

A product can work well in R&D but still fail because deployment is too complex, training takes too long, procurement is unclear, or integration costs are too high. Investors lose interest when the company cannot explain how it moves from “the product works” to “the system buys it, uses it, and keeps paying for it.”

The best way to manage this is to build adoption milestones early pilot completed, integration tested, user training reduced to a simple workflow, procurement path identified, compliance requirements mapped, measurable outcomes recorded. Investors do not need everything to be perfect. But they need to see that the founder understands the operational reality, not just the technology.

The end goal for solution providers is full adoption. What does that process look like, and what are the biggest challenges?

Full adoption usually happens in stages. First, the organisation needs to recognise the problem. Then it needs to trust the solution. Then it needs to test it in a controlled environment. After that comes procurement, integration, training, governance, and finally wider rollout.

The biggest challenge is that healthcare organisations are not only buying software they are changing workflows. That means clinicians, managers, IT teams, data protection officers, finance teams, and sometimes regulators all need to be aligned.

Another challenge is that many products underestimate how messy the underlying data and workflows are. If a solution depends on perfect data, perfect user behaviour, or perfect system integration, it will struggle. Healthcare products need to be designed for real environments, not ideal ones.

How does UK regulation impact startups developing and deploying health innovations?

Regulation shapes both the product and the business model. A startup needs to understand whether its solution is a medical device, a clinical decision support tool, a data infrastructure product, an administrative tool, or something else. That classification changes the requirements entirely.

In the UK, startups may need to navigate MHRA requirements, UKCA marking, clinical safety standards, data protection, cybersecurity, NHS procurement standards, and information governance. This can slow things down, but it also creates a quality filter.

Founders should not treat regulation as something to “deal with later.” If the product touches clinical workflows or patient data, regulatory thinking should be part of the design from the very beginning.

The NHS recently announced a £300 million capital investment to digitally transform health services. What does that mean for medtech startups?

It is a positive signal, but startups should not read it as “the NHS will now buy every digital health product.” The £300 million investment is aimed at improving productivity, automating administrative tasks, enabling faster access to patient information, and supporting more coordinated care.

For medtech startups, the direction of travel is clear: the NHS needs tools that reduce workload, improve data access, and support more efficient care delivery. But the bar will still be high. Startups will need to demonstrate evidence, interoperability, security, and a realistic deployment model.

The opportunity is strongest for companies that solve infrastructure problems, not just surface-level user experience problems. If a startup can improve the quality, structure, or usability of healthcare data, it can become an enabler for many other digital tools.

We are seeing a wave of AI-branded innovations in health. How many of these bring real solutions rather than just riding a buzzword?

A lot of AI products in healthcare are still closer to marketing than real clinical transformation. That does not mean AI is not useful, it means the foundation is often missing.

AI can be powerful when applied to a well-defined problem with reliable data, clear constraints, and measurable outcomes. There are genuine examples in imaging support, clinical documentation, patient triage, administrative automation, trial matching, and decision support in narrow domains.

But using AI as a patch on top of invalid, incomplete, or poorly structured data is a bad idea. In lab diagnostics, for example, a model needs to know far more than the number it needs units, reference ranges, patient context, biomarker relationships, and whether the data has been normalised correctly. The real value of AI in healthcare will come from combining models with validated data infrastructure.

How long will it take for AI to be used meaningfully across the NHS to resolve its biggest challenges?

AI will not “resolve” the NHS’s biggest issues on its own. The NHS faces workforce pressure, waiting lists, funding constraints, infrastructure gaps, legacy systems, and operational complexity. AI can help, but it is not a replacement for system reform.

In practical terms, we will see AI adoption in specific workflows first: administration, scheduling, documentation, imaging support, patient communication, and data processing. Wider clinical adoption will take longer because it requires evidence, regulation, trust, safety, integration, and training.

The realistic path is not one big AI transformation. There are many smaller, validated use cases that gradually become part of normal healthcare operations.



Even if a startup does not use AI in its product, how can it use language models to grow without making new hires?

Language models can be very useful internally, even if the product itself is not AI-based. Startups can use them to speed up research, summarise documents, draft investor materials, prepare customer communications, analyse interview notes, structure product requirements, write support documentation, and produce first drafts of policies or training materials.

This does not replace expert work, it reduces the amount of repetitive work around expert work. For a small team, that matters enormously. A founder can use language models to move faster across sales, product, operations, and communication without hiring too early. But anything related to clinical claims, regulation, legal documents, or patient safety still needs proper human review.

Finally, what advice would you give to a startup itching to break into health and social care and provide genuinely beneficial solutions?

Start with a painful problem, not with a technology trend.

Spend time with the people who will actually use or buy the product. Understand their workflow, their constraints, their incentives, and the reasons existing solutions have failed. Healthcare is full of problems that look simple from the outside but are deeply complex once you see the system.

Also, be honest about the data. Many healthcare problems are not caused by a lack of AI they are caused by poor structure, missing context, fragmented systems, and unreliable information flow. If you solve that layer properly, you create real value before any advanced model is added.

My main advice is this: build something healthcare can trust. That means clear evidence, safe design, strong data handling, realistic deployment, and humility about what the product can and cannot do.

Leave a comment