The Origin Story

Someone once gave me a T-shirt that said Mr. Lazy across the front. At the time, I was slightly offended. I wasn't one to lie in bed all day.

Now? I wear that label with pride.

Not because I lounge around while the world turns. But because I hate doing the same thing again and again. I like to automate. I like to simplify. I like to build systems so I don't have to brute-force my way through work.

Yes, that's me wearing that Mr. Lazy with pride.

Early Days: Manual by Necessity

In the early days of my microfluidics journey, especially in graduate school, everything was manual. I was working on building microfluidic devices focused on multiplexing microparticle detection. A lot of my work, whether it was building the devices, testing them, or analyzing the data, was brute force, tedious, and very manual in nature. One experiment at a time. Data analysis, then redesign, and repeat. I was scripting to analyze one dataset at a time, separately analyzing and drawing conclusions file by file, experiment by experiment. I was building microfluidic devices one at a time, iterating the design each time.

Not very efficient, but it got things done. At the time, the goal was simple: execute and publish. And I had all the time in the world to do just that. Whether it was pipetting assays manually, pushing samples through tiny channels, or wrangling messy datasets by hand, everything was done manually. Because it had to be. We were still proving things could work.

Early grad school days spent multiplexing a microfluidic channel and testing my theories. PSA: Testing like this is pure chaos and a guaranteed disaster, not just for your work but possibly for your mental and physical well-being. I learned from this to build better.

Learning to Spot Automation Opportunities

That mindset, doing everything by hand, wasn't sustainable. IBM became my training ground for understanding how to think about scale, how to design systems that work, and how to manufacture at scale and with precision. One example of the work was related to the characterization of nanowire FETs on semiconductor wafers, tens of dies, 100 or so devices per die. But it wasn't just about measurement scale; we were building devices, iterating through design and process parameters, and processing tens of wafers at a time. All of that had to flow through tools where the processes were automated and tightly controlled.

The volume and complexity made it impossible to brute-force manually. We had to automate. We had to systematize. Otherwise, we'd never make progress.

That was a turning point for me.

The IBM T.J. Watson Research Center in Yorktown Heights, NY, was where I was shaped, whether through hands-on training or the stories passed down, into someone who knows how to build, scale, and think differently.

Building Systems in Startup Chaos

Later, at Chronus Health, I saw this lesson come to life in a startup setting. In the early days, we were running our microfluidic assays manually, loading reagents, pushing samples, and analyzing data in spreadsheets. It worked. But it didn't scale.

As we moved closer to clinical use, we had to remove manual steps to reduce variability. We automated liquid handling. We built scripts to standardize data analysis. We developed tooling to reduce operator error. Every one of those changes came from asking a simple question:

Do we really need a human to do this again?

But here's what made the difference: our team at Chronus Health was willing to take the time to enable that automation. It meant pausing, rethinking workflows, investing in infrastructure, and sometimes slowing down in the short term to speed up in the long run. That commitment to redesigning the process rather than just pushing through it was essential.

One of our biggest internal wins was automating calibration routines that previously took hours of hands-on time per device. It didn't just save time; it reduced calibration errors and made the system more robust. We never would have reached sub-1% CV without those systems in place.

Case Study: Precision Through Fabrication

One area where our framework paid off was microfluidic chip fabrication. We asked: Is this step repeated frequently across workflows? Absolutely. Fabrication happened for 100s of devices. Most vendors we spoke to were comfortable with channel errors of ±10 microns. But that wasn't good enough for us. By developing custom process controls and simplifying key fabrication steps, we were able to consistently hit submicron resolution at a significantly lower cost. That level of precision became a major differentiator as we pushed toward clinical-grade performance.

Case Study: Assay Workflows

Another question we asked was:

Is this the place where things go wrong most often?

For us, it was the assays. Reducing error wasn't just about better chemistry; it was about better systems. We developed workflows to eliminate pipetting inconsistencies, automated mixing and reaction steps, and built analysis pipelines to process raw data reproducibly. Each time we automated a step, our signal stability and repeatability improved. Eventually, those changes became foundational to our assay performance.

The Strategic Framework: Automate to Liberate

Automation comes at a cost. You can't always build a fully automated solution from the start, and you shouldn't. The key is knowing where and when to automate. Early on, it's about being strategic. Automate the things that are repeatable and error-prone, not the things you're still figuring out.

In our case, we didn't try to automate everything overnight. We focused on the steps that were slowing us down, introducing the most variability, or draining time from the work that really mattered. Building smart, modular automation meant we could scale intentionally without locking ourselves into brittle systems too soon.

This experience fundamentally changed how I approached problem-solving. I began scanning for friction, bottlenecks, variability, and time sinks and asking: can this be turned into a system? Every repeatable action became an opportunity to free up focus, reduce complexity, and build consistency.

Over time, I developed a loose framework to evaluate automation opportunities:

These questions became my gut-check before building systems. They helped me avoid premature optimization and focus instead on high-friction, high-leverage wins.

It's not just about efficiency. It's about enabling scale, reducing cognitive overhead, and opening up space for better thinking.

The Creative Payoff of Laziness

Being "lazy" isn't about doing less. It's about doing smart, repeatable things that free you up to think, create, and scale.

When you're building a startup or a lab, it's tempting to just power through the manual work. In fact, doing it all yourself feels like a badge of honor at first. But eventually, the repetition wears you down. And worse, it becomes a liability to quality, speed, and sanity.

But if you find yourself doing the same thing more than a few times? That's a signal to pause and ask: Does this map to one of the three questions in my automation framework? Often, the most valuable automation isn't the most complex; it's the one that removes the highest-friction step, the one where mistakes pile up, or the one everyone avoids doing.

If you're in the trenches of deeptech or medtech or scaling something messy and manual, you might find this one useful. Or at least familiar.

So yes, call me Mr. Lazy.

Just don't be surprised when the system I built does the job while I'm off solving the next problem.

Because that's the real upside: freeing your mind to tackle the next creative challenge, think longer-term, and unlock innovation. When you're not bogged down in the same manual loops, you can step back, see the patterns, and build things that scale, not just function. You create space for invention.

So go ahead, build smart. Be a little lazy.

More soon.

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. 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 wrestling with where to automate or how to build like a "lazy" engineer.