Each minute of our life is a lesson but most of us fail to read it. I thought I would just add my daily lessons and the lessons that I learned by seeing the people around here. So it may be useful for you and as memories for me.

Why the Most Successful MedTech Startups Build Trust Before They Build Features

Software has transformed healthcare.

Today, a single application can help clinicians detect diseases earlier, monitor patients remotely, support treatment decisions, and even leverage Artificial Intelligence to improve outcomes.

Artificial Intelligence, cloud computing, remote patient monitoring, and digital therapeutics are transforming healthcare faster than ever before. Every day, startups launch innovative solutions designed to improve clinical workflows, reduce costs, and deliver better patient outcomes.

Yet many of these companies face an unexpected challenge when preparing for regulatory approval.

The obstacle isn’t the technology.

It’s the evidence behind the technology.

Having worked with leading Electronic Health Record (EHR) platforms including EMIS, TPP SystmOne, and Epic, and more recently leading an ISO 13485 implementation for a Software as a Medical Device (SaMD) organization, I’ve learned that regulators don’t simply evaluate software—they evaluate the process used to build it.

That’s a mindset every healthcare startup needs to embrace.

Innovation Gets Attention. Evidence Earns Approval.

Many startups believe success is measured by:

• Faster releases
• Better user experience
• AI-powered capabilities
• Modern cloud architecture
• Rapid customer growth

These are all important.

But healthcare is different.

Whether you’re preparing for FDA, MHRA, ISO 13485, or IEC 62304 compliance, regulators are asking a different question:

“Can you objectively demonstrate that your software is safe, effective, and consistently performs as intended?”

That’s a much higher standard than simply delivering working software.

Healthcare Software Is More Than Code

One of the biggest lessons I’ve learned throughout my career is this:

Medical software is not just an application.

It is a collection of evidence.

Every requirement.

Every design decision.

Every risk assessment.

Every verification activity.

Every release.

Together they create a complete story demonstrating that your product deserves to be trusted.

The software may save lives.

But the evidence proves why it should.

The Five Questions Every Regulator Wants Answered

Regardless of which regulatory framework you’re following, most reviews ultimately focus on five fundamental questions.

1. Is the Intended Use Clearly Defined?

Everything begins here.

If your intended use is vague, your regulatory pathway becomes equally unclear.

A strong intended use explains:

• Who the users are
• What clinical problem the software addresses
• What decisions it supports
• What it explicitly does not do

Clear intended use drives better design, testing, and risk management.

2. Have You Identified and Controlled Risks?

No medical device is risk-free.

The expectation isn’t zero risk.

The expectation is that risks have been systematically identified, evaluated, mitigated, and monitored throughout the product lifecycle.

Risk management isn’t just another document.

It’s a design activity.

3. Can Every Requirement Be Traced?

One feature.

One requirement.

One verification.

One result.

That traceability should exist throughout the entire development lifecycle.

Without traceability, demonstrating compliance becomes significantly harder.

4. Have You Proven the Software Works?

Testing is far more than checking whether the application runs.

Verification demonstrates that requirements have been implemented correctly.

Validation demonstrates that the software actually meets user needs within its intended clinical environment.

Both are equally important.

5. Can You Explain Every Change?

Healthcare software continuously evolves.

New features.

Security updates.

Bug fixes.

AI improvements.

Every significant change should be assessed for potential impact on patient safety before release.

Good change control protects both patients and your organization.

What Working Across Different Healthcare Platforms Has Taught Me

Over the years I’ve had opportunities to work with healthcare platforms supporting different healthcare systems and clinical workflows.

Whether it’s EMIS, TPP SystmOne, Epic, or other regulated healthcare environments, one thing consistently stands out.

The organizations that succeed don’t view compliance as the responsibility of the Quality team alone.

Quality becomes part of engineering.

Developers understand risk.

Architects understand traceability.

Product owners understand intended use.

Leadership understands governance.

When everyone shares responsibility, audits become confirmation—not crisis management.

Practical Advice for Healthcare Startups

If you’re building your first regulated healthcare product, don’t wait until six weeks before an audit to think about compliance.

Instead, build it naturally into your development process.

Here are six practices that consistently make a difference.

✅ Define Your Intended Use Before Writing Code

A well-written intended use statement becomes the foundation for every regulatory activity that follows.

✅ Integrate Risk Management into Product Design

Risk management shouldn’t begin after development.

It should influence architecture, workflows, and technical decisions from day one.

✅ Build Traceability Early

Don’t leave traceability until release.

Connecting requirements, risks, development, verification, and validation throughout the project saves enormous effort later.

✅ Keep Documentation Alive

Documentation should evolve alongside the software—not become a last-minute exercise before certification.

Current documentation reflects current quality.

✅ Review Designs Frequently

Short, structured design reviews help identify issues long before they become audit findings or production defects.

✅ Make Compliance Part of Engineering Culture

The best quality systems aren’t maintained by Quality Managers.

They’re supported by the entire organization.

Compliance Doesn’t Slow Innovation

This is one of the biggest misconceptions in healthcare technology.

In my experience, organizations with disciplined development processes often move faster over the long term.

Why?

Because they spend less time fixing avoidable problems.

They build:

• Better architecture
• More reliable software
• Stronger cybersecurity
• Higher-quality testing
• Cleaner documentation
• More predictable releases

Quality isn’t bureaucracy.

Quality is engineering done well.

Final Thoughts

As AI becomes more deeply integrated into healthcare, regulatory expectations will continue to evolve.

But one principle will remain unchanged.

Trust must be earned.

Not through marketing.

Not through impressive demonstrations.

Not through ambitious roadmaps.

Through disciplined engineering.

Through effective quality management.

Through objective evidence.

The healthcare startups that thrive over the next decade won’t simply be those building the smartest software.

They’ll be the ones capable of proving—every step of the way—that their software is safe, effective, and built under control.

And in healthcare, that’s what ultimately matters.

“In Healthcare IT, innovation may open the door—but evidence is what gets you through it.”

If you wanna share your experiences, you can find me online in all your favorite places  LinkedIn and Facebook. Shoot me a DM, a tweet, a comment, or whatever works best for you. I’ll be the one trying to figure out how to read books and get better at playing ping pong at the same time.