I've been thinking about how hard it is to time that shift, especially in microfluidics and medical devices. (And really, this applies to any company or project, even in academia.)

In the beginning, when you are just getting started and are early stage, the pressure is all about getting it to work just once. Show a signal. Prove it's possible. Generate interest.

But that early success can be misleading. Making something work once is very different from making it work every time, across batches, operators, and environments.

At Chronus Health, we had to relearn this lesson more than once.

Some teams try to perfect their early prototypes when they should still be exploring.

Others stay in prototype mode too long, shipping parts that can't survive scale, regulation, or manufacturing variability.

The truth is: both modes are valid, just not at the same time.

Early Stage: Build It Fast

One of my earliest hard pivots happened in the very early days of Chronus Health, when it was just me, my cofounder, and three full-time engineers. We had just received our pre-seed round and were working out of an incubator with limited time, budget, and resources.

Initially, we tried building a microfluidic platform on silicon and even considered SOI (Silicon on Insulator) wafers. Coming from IBM, I was used to iteration at scale: fab runs, automated tools, batch workflows. But in a lean early-stage startup, that model collapsed. We had no fabrication facility, little funding, and the silicon process development alone would have taken more than three months, longer than our entire incubator residency.

So we made the call:

It wasn't polished. It wasn't meant to last. But it moved us forward. We could test faster, iterate more, and learn what mattered most.

Later Stage: Build It Right

But that speed doesn't scale. Eventually, we had to shift from exploration to execution.

In our case, in one assay, we particularly needed to count cells in a microfluidic channel with a precision of under 2% CV. That meant rethinking everything.

We had to:

At that stage, it wasn't about just getting a signal once; it was about getting reproducible data, every time, with CV <2%.

That level of repeatability required reworking almost every part of the system: cartridge tolerances, reader alignment, and fluidic stability. Even human interaction had to be simplified or eliminated.

What worked for learning no longer worked for launching.

Where Are You Now?

This is something I now ask every founder:

"Are you in a phase where the job is to discover or to deliver?"

Microfluidics is unforgiving. At small volumes, everything is amplified. For us, a sub-micron channel variation, a tiny air bubble, or a slight mismatch in surface energy could derail flow, alter reaction kinetics, or break the assay entirely. Small tolerances, invisible failure modes, and complex fluid physics leave little room for error.

Medical devices are expensive because safety, validation, and regulatory requirements add significant cost to every stage. You're not just engineering a product; you're engineering trust, reproducibility, and compliance. Clinical settings are even more demanding because they introduce real-world variability: operator differences, time constraints, and patient risk. You only get one shot to get it right. But you can't skip the early hacks, and you can't stay there forever.

What We Built at Chronus Health

Chronus Health was a diagnostics startup focused on building a point-of-care blood testing platform that combined microfluidics, biosensing, and real-time data analytics. Our mission was to deliver lab-quality results in minutes. I was the CTO and the person behind the technology, leading the engineering effort. We developed novel assay workflows, high-precision fluidic cartridges, and scalable data pipelines. Building at Chronus was not just about proving scientific feasibility; it was about making diagnostics fast, reliable, and clinic-ready.

About Me

I'm Ashish Jagtiani, a founder, engineer, and systems thinker. I've spent the last two decades building, from semiconductor R&D at IBM to launching Chronus Health, a medtech startup focused on point-of-care diagnostics. I was the CTO and co-founder of Chronus Health. I left the company in December. It was one of the hardest decisions I've made, because it wasn't just a company, it was something I helped build from scratch, something deeply personal. Walking away felt like stepping back from something I had raised for over twenty years (8 years building the company).

It was hard and deeply painful, not because of lost equity or missed future gains, but because of broken promises. This post comes from experience, not theory. Our company didn't make it. But that doesn't make the lessons any less valuable. If anything, it makes them sharper.

If I had to do it again, I'd be more deliberate about timing that transition, from fast to right, from discovery to delivery.

I'm sharing this in case it helps someone else navigate that same blurry middle. If you've been through it or are in it now, I'd love to hear what you've learned.

Today, I run Twenty Seven Labs, where I work with early-stage deeptech and diagnostics startups to bring hard technologies to life. I believe in simplifying the complex, building with intent, and designing for scale from day one. Let's connect. If you're a founder navigating that blurry middle between building fast and building right, I'd love to hear your story.