Owning the Harder Problems

Digvijay

Oct 27, 2026

Share

I’ve spent much of my career working on complex problems where getting the product right meant understanding the underlying system, not just building the interface.

At Plum, I worked on insurance operations, translating complex policy constructs and business workflows into a system that could support multiple organisations. That meant designing workflows and data models for fundamentally different journeys - from onboarding an organisation for the first time to managing renewals - while keeping the platform scalable enough for business and sales teams to grow without bespoke engineering work for every new customer. More on that here.

Before that, at Predible, I worked on deep-learning products that helped clinicians interpret medical scans more quickly and accurately. Read that story here.

These experiences were different but they reinforced something I keep coming back to: the interesting problems often lie beneath the surface, in the complexity of the systems themselves.

And with AI, writing code is getting cheaper by the day. Which makes me think it’s time to own the harder problems.

What once took a team and a quarter can now take one person and a few weekends. I know because I’ve been doing exactly that on this break - building and shipping my own side projects with AI as my co-builder.

That’s amazing for builders but it changes the game in a way one can’t ignore.

When everyone can build, building stops being the edge.

Almost every category/sub-category of software is getting crowded. If a product can be replicated in weeks, the advantage shifts to whoever already owns the customer, has the distribution, or can offer something others can’t.

Enterprise distribution matters more than ever. And for the first time in a while, incumbents seem to have the upper hand over startups. In previous eras, a small agile team with a better product could outrun a giant. I’m not sure that’s true anymore.

There’s another shift too. Reinforcement Learning (RL) is one of the most key engines driving AI’s progress today, and it thrives on one thing: rewards that can be evaluated quickly and deterministically. If a computer can run a test or simulation, verify the result and try again millions of times, you can brute-force a problem by throwing lots of compute at it. Code and math are the obvious examples - run the tests, check the results, verify answers and repeat.

Not every problem may fit this pattern, and RL isn’t the only technique at work. However, where progress can be validated cheaply and reliably, AI systems have a powerful advantage: they can iterate at a scale no human team could match.

Many such problems will get dramatically easier to solve. And the opportunities they create may be captured by whoever has the compute, the best models, or the resources to keep pushing the frontier. Probably not by me. And probably not through a product that’s defensible simply because I was the first to build it.

So I’ve started asking a different question: what kind of problems can’t be solved just by throwing compute at them?

The answer I keep coming back to: problems where the feedback loop runs through the physical world.

Think drug discovery, where a promising molecule still has to survive experiments and clinical trials. Or batteries, where understanding degradation means grappling with hundreds of charge cycle, i.e., years of real-world use. You can simulate, model and predict all you want but eventually your ideas have to survive contact with reality.

You run the experiment. You wait. You measure what happened. You try again.

More compute helps but it can’t simply make the physical run world faster. A growing number of companies are trying to close this gap via what’s often called “experiment-as-a-service”. The idea is to let a researcher - or an AI agent - request a physical experiment, have a laboratory or specialised facility run it and get structured results back. In effect, they’re trying to make experiments work more like computer programs.

But physical experiments are still expensive, slow and often need custom setups. You can’t simply throw arbitrary compute at them the way you can with code. That’s why AI can solve increasingly hard math problems but hasn’t solved cancer yet.

The bottleneck isn’t intelligence. It’s the infrastructure and feedback loops needed to test ideas against reality.

This is where I think it gets interesting.

If the physical world is difficult to access, measure and influence, then the ability to operate in it can become a barrier to entry. The infrastructure, integrations, relationships and on-ground expertise needed to make something work in the real world take time and money to build. A competitor can’t simply copy your code and replicate all of that overnight.

But there’s another advantage I find even more compelling: real-world feedback that compounds. Once you’ve laid the foundation and embedded yourself in a system, you start learning things an outsider can’t easily observe. You learn which predictions hold up, which interventions work and where your assumptions break. If you can turn those observations into better decisions, each deployment can make your product a little better.

Data isn’t automatically a moat, though. The advantage compounds only when what you learn improves the product in ways that matter to customers.

Operational friction may keep competitors out. Real-world feedback can help you pull ahead.

There’s a catch: all this costs money. The challenge as a founder is to turn that operational complexity into a durable advantage without letting it destroy your unit economics.

Can you standardise what initially requires bespoke work?

Can the product improve enough to deliver better outcomes without proportionally more people and resources?

The goal isn’t to preserve friction for its own sake. It’s to remove it for customers.

Predible taught me something about this. The hard part wasn’t just building a model that could interpret medical scans. It was earning clinical trust: running hospital pilots, validating performance, integrating into clinical workflows and convincing doctors that the product could work in their world. It was some of the most meaningful work I’ve done, and it shaped how I think about the gap between a technical capability and a product that actually changes something on the ground.

Since then, I’ve spent years building operational systems and workflow software, and I’ve enjoyed it. But I’m ready for a different kind of challenge.

I believe we’ve barely scratched the surface of what AI can do in the physical world. Over the next five to ten years, I want to build products that solve hard, real-world problems, going as deep into the underlying science as the problem demands.

Right now, my leading bet is energy systems, specifically in India.

Energy runs on physical hardware - panels, batteries, inverters, motors and grids - installed on-site and operating under real conditions: heat, dust, voltage fluctuations, and how people actually use power. Understanding how these systems perform over time could help us make better decisions about how they’re designed, financed, operated and maintained. Every deployment teaches you something that doesn’t show up in a simulation.

India’s demand for power is climbing, driven from several factors at once:

Aspirations - more homes running ACs, appliances and everything that comes with a rising standard of living.

EVs - two-wheelers, three-wheelers, buses and cars, all plugging into the grid.

Climate change - hotter summers and more extreme weather putting pressure on how we generate, distribute and use energy.

Data centres - the AI boom itself needs enormous amounts of power.

Meeting that demand isn’t just about building more generation capacity. It also raises harder questions about how we distribute and store energy, manage loads, improve efficiency and make energy systems work reliably on the ground.

The question that excites me most right now: how do we help families and factories make and own their own energy?

It’s a broad question and I don’t yet know which part of it is the right place to start. But it sits at the intersection of physics, hardware, software, policy and real people. It’s a space where better intelligence could have tangible impact. And it’s a problem that won’t be solved by writing better code alone.

I’m still early. I don’t have a product, a pitch, or a neat answer - just a direction and a lot of questions. I’m reading, talking to people and trying to understand where things actually break.

A Big Ass Fans industrial ceiling fan on a factory floor I visited.

I’m looking for problems that are painful enough to solve, grounded enough to start working on now and deep enough to keep learning from for years.

So if you operate, research, or build in energy - especially in India - I’d love to compare notes. Tell me what’s hard, what’s broken, or what I’m getting wrong. I’d much rather have my assumptions challenged now than later.

Thanks to Viswa, Sriram, Shreyas, Swapnil et al. - my IITM friends - whose WhatsApp group debates shaped parts of this, esp. the bit on experiment-as-a-service.