Everyone claims it. Founders cite it in pitch decks. Investors use it in feedback. Advisors recommend it. It has become one of those terms that signals a certain kind of intellectual seriousness without requiring any demonstration of the thing itself.

I want to talk about what it actually looks like in practice. Not as a philosophy but as a daily discipline that costs something, gets pushback, and occasionally makes you deeply unpopular with the people around you.

Because that is what it is. And if it is not costing you anything, you are probably not doing it.

A Conversation With My Daughter

A few days ago, my twelve-year-old came home and told me education is pointless.

She is in grade six. Her argument was clear and specific: she learns five times more at home, through her own reading and exploration and the things she chooses to pursue, than she does in a structured school environment. School, in her view, is a system optimised for compliance rather than learning.

Most parents would have dismissed this. Gently, maybe. With a reassuring explanation of why school matters, why credentials matter, why she should trust the process.

I did not dismiss her. Because her reasoning was sound.

We sat and discussed it properly. I did not tell her she was wrong. I did not tell her to stop questioning it. I pushed back on some of the specifics and agreed with others. We talked about what education is actually for, which is a more interesting question than whether the current system delivers it.

That conversation was first principles in the most personal context I have. The culturally correct response would have been to reassure her that school is important and that she should trust the system. The first principles response was to actually engage with what she said, evaluate it on its merits, and follow the reasoning wherever it went.

She is twelve. She is already thinking this way. That matters more to me than whether she arrives at the conclusion her school would prefer.

The Home Decision

I owned a home. I sold it. I have not bought again in India since.

This has generated more unsolicited advice than almost any other decision in my personal life. “Settle down.” “At your age.” “It’s time.” “What about security?” “What about the kids?”

The pressure to own a home in India is enormous and mostly unexamined. It is one of those decisions that gets made because it is what people do at a certain stage of life, not because anyone has actually thought through whether it is the right decision for their specific situation.

I thought through it.

My conclusion was different from the conventional one. The question I asked was not “should I own a home?” but “what do I actually want the next ten years of our family’s life to look like?”

The answer was: I want to be close to where my kids’ interests and education take them. Not anchored to a city or a location because that is where the property is. Not constrained in our choices because of a mortgage on a specific location. The freedom to move, to follow what matters, to not have a piece of real estate determine where we live.

That is a first principles answer. It is not the standard answer. It generated genuine worry from people who love me and wanted something different for us.

I was comfortable with that because the reasoning was sound. Not because I had found a framework that told me this was the right call, but because I had thought it through from the actual question rather than from the assumed answer.

The Enterprise to SMB Pivot

On the business side, the most consequential first principles decision I made was pivoting Hyperleap from enterprise to SMB.

This was not obvious. Enterprise is where the big contracts are. Enterprise is what most B2B SaaS companies chase. Enterprise is what the playbook says to go after if you are building software for businesses.

I went the other way. Not because someone else had validated the SMB path. Because I sat with a set of honest questions and followed where they led.

The questions were personal and uncomfortable. Can I hire a proper enterprise sales team? No. Can I operate comfortably in twelve-month sales cycles with multiple stakeholders and procurement processes? No. These are not failures. They are honest assessments of where my strengths are and where they are not.

But the deeper question was about the market itself. I kept asking: if enterprises can build AI capabilities themselves, and the largest companies in the world are all investing in that capability, why would they buy from a small startup with limited resources and no brand? The answer, honestly, was that the stronger ones would not. The enterprises most likely to buy from a company like Hyperleap were the ones who could not build themselves, which was a specific and shrinking segment as AI tooling improved.

SMBs were a different picture. They could not build. They needed solutions they could deploy without large technical teams. The sales cycles were shorter, the relationships more direct, the feedback loop faster. And there were far more of them.

That pivot came from primary research, customer conversations, and thinking carefully about where the market was actually going. Not from copying what another company had done. Not from a framework about market segmentation. From asking the actual questions and following the actual answers.

People around me had concerns. The comparison to companies that had succeeded in enterprise came up often. “Company X did it this way.” “The successful B2B players all went enterprise first.” I understood the parallels. I also understood that the parallel was not my situation, and that following someone else’s path in a different market at a different moment was not first principles. It was just imitation with extra steps.

Why This Is Genuinely Hard

First principles thinking sounds like freedom. In practice it is mostly friction.

Every time you reach a conclusion that diverges from the conventional one, you have to defend it. Not once but repeatedly, to different people, in different conversations, over months or years. The people pushing back are often smart and well-intentioned. They are drawing on real experience. Their parallels are not irrelevant.

But parallels are not analysis. “This is how it’s usually done” is not a reason. “Company X did it this way” is not an argument. These are starting points for thinking, not substitutes for it.

The discipline is to take the parallel seriously enough to understand it, then ask whether it actually applies to your situation. Sometimes it does. Often it does not. The situations that look similar on the surface are frequently different in the ways that matter most.

Over time, I have found that this gets less exhausting and more automatic. Not because the pushback stops, but because the reasoning becomes more confident. When you have followed first principles to good outcomes enough times, the process of trusting your own reasoning becomes easier. The external pressure does not disappear but it has less purchase.

The hard calls we make at Hyperleap now come from a combination of primary research, direct customer conversations, and something harder to name: judgment accumulated over eight years of watching what the market actually does versus what people predict it will do. Not from copying anyone. Not from pattern-matching to someone else’s success story. From thinking.

That is first principles at the operational level. It is not dramatic. It does not look like a eureka moment. It looks like doing the work of thinking clearly about the actual situation in front of you, every time, even when the easier path would be to just follow what someone else already figured out.

What It Requires

Intellectual honesty. You cannot do first principles thinking if you are not willing to follow the reasoning to uncomfortable places. The home decision was uncomfortable. The SMB pivot was uncomfortable. The conversation with my daughter about whether school is actually working is uncomfortable. Comfortable first principles is not first principles. It is just rationalising what you already wanted to do.

Tolerance for being misunderstood. The conventional path exists because it usually works for most people. When you diverge from it, the people around you will often interpret that as naivety, stubbornness, or risk. Some of that concern is genuine and worth listening to. But if you cannot tolerate being thought wrong by people you respect, you will drift back toward the conventional answer every time.

Patience with the process. First principles thinking is slow relative to just copying what works. You have to actually think, which takes time. The shortcut of following someone else’s playbook is faster in the short run. The cost shows up later, when the playbook does not fit and you have to start thinking from scratch anyway.

And perhaps most importantly: the willingness to be wrong and update. First principles does not mean certainty. It means honest reasoning. Sometimes the reasoning leads somewhere that turns out to be incorrect. The right response is to update, not to double down because you went through the effort of thinking it through.

The Throughline

The decisions I am most confident in, looking back, are the ones where I started from the actual question rather than the assumed answer.

Where do my kids need us to be? Not: where should we own property?

What kind of business can I actually build, given who I am? Not: what kind of business do successful B2B companies build?

What is my daughter actually saying, and is she right? Not: what should a twelve-year-old believe about school?

These are different questions. They lead to different answers. And the answers, even when they are unpopular, sit well because they came from honest reasoning rather than borrowed convention.

That is what first principles actually is. Not a framework. Not a badge. The discipline of asking the real question and following the real answer, even when it leads somewhere uncomfortable.

The bottom line: First principles thinking is not a philosophy. It is a daily practice that costs something. It means starting from honest questions rather than assumed answers, following reasoning even when it diverges from convention, and tolerating the discomfort of being misunderstood while you wait for the reasoning to prove itself. It gets easier over time. It never gets frictionless.

Where have you found it hardest to think from first principles rather than just following the conventional path? I’d genuinely like to hear.

I’m Gopi Krishna, founder of Hyperleap AI, where we build enterprise-grade conversational AI for small and medium sized businesses across the world. Subscribe to Second Order AI on Substack to follow along.

Every founder memoir. Every startup framework. Every post-mortem from a company that failed and every growth story from one that succeeded. I was looking for the formula. The sequence of steps that, if followed correctly, would produce a company.

I tried applying what I found. When I read about a founder who succeeded by going all-in on product-market fit, I ignored everything else and focused on PMF. When I read about one who grew through aggressive content marketing, I pivoted to content. When lean startup methodology was the answer, I applied every part of it exactly as prescribed.

Nothing worked the way it was supposed to.

Not because the advice was wrong. Because it was written for someone else, in a different market, with a different product, at a different moment. I was trying to wear someone else’s map in territory they had never visited.

The breakthrough came quietly. I stopped asking “what did they do?” and started asking “why did they make that decision?”

That is a small shift that changes everything.

What the Playbook Actually Is

Every piece of founder advice you have ever read was written after the fact.

The founder survived, looked back, and found the pattern in what they had done. The pattern is real. But it was discovered in retrospect, not designed in advance. And the conditions that made that pattern work, the market timing, the team composition, the competitive landscape, the capital environment, are almost certainly different from your conditions today.

This is not a criticism of founder content. The stories are valuable. The principles inside them are transferable. But the specific tactics, the exact sequence, the “here is what you should do next,” those are maps drawn from someone else’s territory.

Your territory is different. It has always been different.

What I eventually understood is that there is no playbook. There is only judgment. The ability to take in information, understand context, reason from first principles, and make a call that fits your specific situation right now.

That is not something you can read your way into. It is something you develop by making decisions, watching what happens, and updating your thinking accordingly.

What I Did Instead

Once I stopped looking for instructions, I started looking for principles.

Not “here is what to do” but “here is how to think about this category of problem.” Not specific tactics but the underlying logic that made those tactics work in that context.

From Marc Andreessen, I took the idea that market timing matters more than almost anything else. Not as a rule but as a lens. When I am evaluating a decision, I ask: what does the market want right now, and are we early, on time, or late?

From watching companies that stayed lean and companies that scaled too fast, I formed my own view on hiring. Not from a framework but from direct observation of what happened when founders hired ahead of need versus behind it.

From my own experience, I learned that the advice that feels most universally true is usually the most dangerous. Because it is the advice everyone follows, which means it has the least differentiation, and differentiation is what actually builds companies.

None of this came from a book. It came from thinking hard about what I was seeing and forming my own view.

The Specific Moment It Changed

There was a period, maybe eighteen months into Hyperleap, where I was in three separate conversations with three advisors in the same week.

The first told me I needed to hire aggressively to capture the market. The second told me I needed to stay lean until I had more product-market fit signal. The third told me the market timing was wrong and I should wait before scaling anything.

All three were smart people with real experience. All three were contradicting each other completely.

That week I realised I was the only person in the room who knew my specific situation. Not better than them in general. Just better informed about this particular company, this particular market, this particular moment.

The playbook could not resolve that contradiction. I had to.

I chose to stay lean and wait for clearer signal. Not because a framework said so. Because when I thought hard about the specific conditions I was operating in, that was the call that made sense.

It turned out to be the right call. But I did not know that then. I just made the best judgment I could with what I had.

Why This Is Actually a Good Thing

Founders who are looking for a playbook are, in a subtle way, looking for permission. Permission to make the next move. Permission to know they are doing the right thing.

The playbook provides that permission. It says: someone else did this and it worked, therefore you should do it too.

But that permission is false. Because the playbook was written for someone else.

The founder who accepts that there is no playbook is also accepting that they have to trust their own judgment. That is uncomfortable. It is also the only honest position.

Your company is not like any other company. Your market is not like any other market. Your team, your timing, your constraints, your strengths, these are specific to you in ways that no framework can account for.

You have to think. There is no substitute for thinking.

The good news is that thinking gets better with practice. The judgment you develop over eight years of making decisions and watching what happens is genuinely valuable. Not because you have read more, but because you have thought more, in conditions that were real rather than hypothetical.

That is the playbook I have been building. It lives in my head, not in any book. And it is the most useful thing I have from eight years of doing this.

What I’d Tell a Founder Now

Read widely. Take the principles. Leave the tactics behind.

When you read a founder story, ask: what were the specific conditions that made this work? Would those conditions apply to me? If not, what is the principle underneath that might still be transferable?

Find advisors who help you think rather than advisors who tell you what to do. The best advice I have received has always been in the form of a question, not an instruction.

And accept early that the answer to “what should I do?” is almost always: it depends. Not as a cop-out but as an honest description of reality. The conditions matter. Your specific context matters. The playbook does not have that information. Only you do.

Trust that. Build that judgment deliberately. It is the most durable competitive advantage you can have.

The bottom line: There is no playbook. There are principles and there is judgment. The founders who succeed are not the ones who found the right formula. They are the ones who learned to think clearly about their specific situation and made the best call they could with imperfect information. That is a skill. It is learnable. But it cannot be outsourced to a framework.

What is the piece of startup advice you received that turned out to be completely wrong for your situation? I would genuinely like to hear.

I’m Gopi Krishna, founder of Hyperleap AI, where we build enterprise-grade conversational AI but for small and medium sized businesses across the globe. Subscribe to Second Order AI on Substack to follow along.

Not dramatically. Gradually. The hobbies went first. Then the friendships got harder to maintain. Then the family became another thing to manage. Then one day the company hits a wall and they had nothing else. No other identity. No other source of who they were. The company’s bad year became their bad year in a way that was genuinely hard to watch.

I thought about that a lot during the hard stretches of my own journey. I came close enough to that edge, especially in the year I wrote about in Mistake #9, to understand how it happens. I never wanted to be one of them. The reason was simple. At Microsoft, I was a full person - I wrote, I spent time with family, I vacationed, I had my me time, I did many things. I wanted to stay the same.

I wanted to stay a full person.

Writing

I cannot not write. This has been true since before Hyperleap, before the MBA, before I left Microsoft.

The 10x Software Engineer came out of COVID. The world stopped and I finally had the uninterrupted space to write something I had been carrying for years, everything I had observed about what separates good engineers from great ones across more than a decade at Microsoft. Nobody asked for the book. I just wrote it.

The Second Order AI Substack is the same instinct in a different season of life. This series you are reading is not a content strategy. It is how I make sense of what I have been through. Writing every week, finding the honest version of each story, not reaching for the comfortable framing, has given me more clarity about this journey than almost anything else has.

When things were hard, writing was not an escape. It was a way of staying tethered to how I actually thought, separate from how the company needed me to think. That separation mattered more than I realised at the time.

Reading

Broadly. Not just AI papers and startup content.

I am not going to pretend I have a perfect reading habit or a system. Some weeks I read a lot. Some weeks I barely read at all. But the commitment to reading things that have nothing to do with the company has stayed.

The unexpected connection, the insight from a domain that looks nothing like mine, the book that reframes a problem I have been stuck on for a month, these things have happened enough times that I stopped treating reading as a luxury and started treating it as work.

Speaking and Teaching

I speak at events. Salesforce Design Days, HubSpot startup events, T-Hub sessions, large business gatherings, among several others. Not as many as some people in this space, but enough that it is a regular part of my life.

I kept being asked why I do this, given everything else on the plate. The honest answer is that I get more out of it than I give. Teaching or even talking about something forces you to know what you actually believe. The questions that come from the room, expose assumptions I had not examined. Some of those questions have directly changed how I think about Hyperleap.

Giving back is part of it. Staying sharp is a bigger part.

Side Projects

I build things I have no business building given how much is already on my plate.

Waitroom, the agent coordination layer I have been building. Various tools and experiments that have taught me things even when they went nowhere. Supporting Asvini as she built Beyond Time. There’s a temple website I took up and worked on for an hour here and there. Finished in no time.

Some founders treat side projects as a problem to manage, a distraction from the main thing. I have never been able to see it that way. The compulsive building is not something I do despite the startup. It is who I am independent of it. Keeping it alive through the hardest years kept me connected to why I started in the first place.

Family

Asvini runs her own product - a tiny mobile app. We are both founders. We understand each other’s world in a way that I am genuinely grateful for.

Two kids. The realisation I wrote about in Mistake #9 was partly a health moment and partly a family one. I looked at who I was becoming and thought about what my kids would grow up knowing about their father. That thought changed something permanently and it has not changed back.

The Thailand trip in January was decided months before we went. Not spontaneous, not convenient, not something that happened because there was finally a gap in the calendar. It was in the plan and nothing moved it. The world continued while we were gone. I removed the SIM card while I travelled. Nothing burned down. What I came back with was worth more than four days of pushing through.

I did not always protect family time this well. But I learned, and the learning stuck.

Friends

HPS, class of 2000. College. Microsoft. ISB. Four sets of friendships that predate everything I have built professionally.

These people knew me before the startup. They have no investment in the startup version of me. When I spend time with them, nobody asks about metrics or funding or product roadmap. Some of them invested in the startup, and even they don’t ask. They ask how I am, and they mean it.

I have not been perfect about maintaining these friendships. The distance, the busyness, the years, all of it takes a toll. But I have shown up enough that the relationships are still real. That is one of the things I am most glad I did not let slide completely.

What I Actually Believe About This

This is not a work-life balance that I am trying to achieve. I genuinely do not know what that phrase means for someone building a company. The separation it implies does not match the reality I live in.

What I believe is simpler. Founders who collapse everything into the company become fragile. Not because they worked too hard but because they stopped being a full person. When the company has a bad day, and it will, there is nothing else. The self and the startup have merged completely. A hit to one is a hit to the other.

I have had bad stretches at Hyperleap. Things that did not work, bets that did not pay off, years that were harder than they had any right to be. What got me through was not resilience in any abstract sense. It was the writing and the reading and the side projects and the family and the friends and the speaking and the practice I found through Inner Engineering.

All of it outside the startup. All of it holding me while the startup did what startups do.

The company is still here. So am I. I do not think those two things are unrelated.

The bottom line: Keeping an identity outside the startup is not a luxury or a work-life balance achievement. It is structural support for the long haul. The things you hold onto outside the company are what hold you when the company gets hard. Do not let them go.

What do you hold onto outside the work? I’d genuinely like to hear.

I’m Gopi Krishna, founder of Hyperleap AI, where we build enterprise-grade conversational AI for small and medium sized businesses across the globe. Subscribe to Second Order AI on Substack to follow along.

This is not a pivot to positivity. It is a pivot to completeness. A founder who only talks about what went wrong is telling half a story. The things that worked are at least as instructive as the things that didn’t. Here is the first one.

For the last nine days I wrote about mistakes. Real ones. Things I would go back and do differently if I could.

But the company is still here. Eight years in, with real customers, a product that genuinely works, and a team that believes in what we are building. That did not happen only because I survived the mistakes. Some things I got right from the beginning and never let go of. This is the first one.

The Only Advice That Actually Generalizes

Every founder gets told different things. Raise early. Don’t raise. Hire fast. Hire slow. Focus on product. Focus on distribution. Move fast. Be deliberate.

Most of this advice is contextual. What worked for one founder in one market at one moment may have nothing to do with your situation.

But there is one thing I have watched hold across almost every founder I respect, regardless of what they built or where they built it.

They were dangerously good at one thing. And genuinely competent at everything else.

Not famous for one thing. Not credentialed in one thing. Dangerously good. The kind of deep where you see problems others miss, where your judgment in that domain is hard to argue with, where the best people in that field would respect what you know.

And alongside that depth, a deliberate breadth. Not expertise everywhere. Enough to understand every function, have the right conversations, make informed decisions, know when someone is pulling wool over your eyes.

That combination is what I now think of as the actual job of a founder.

What That Looked Like for Me

My one thing was tech and product. I never really separated them.

To me, a great product is just great engineering with a user in front of it. The technical decisions and the product decisions were always the same decisions, made at the same time, by the same person. That person was me.

That depth gave me something I could not have hired. I could see what was possible before the team could articulate it. I could tell when an engineering approach was going to create a product problem three months later. I could sit with a customer, hear what they were struggling with, and know immediately whether we could solve it and roughly how.

Eight years later, the feedback I am most proud of is still about the product. Customers notice when something has been built with genuine care and genuine understanding. That is not a marketing outcome. It is a product outcome. And the product was shaped, every day, by staying close to what was being built.

I am in the code every single day. In the last three months, I made 2,000 contributions on GitHub. Not as a statement. Just as how I work. The code is where my thinking happens. Staying out of it would be like driving with one hand tied behind my back.

The Breadth Side

The depth alone would have kept me in a corner.

I pushed myself, sometimes uncomfortably, into every other function. Sales. Marketing. Finance. Hiring. Legal. Customer success. I was not trying to be an expert in all of them. I was trying to understand them well enough to make good decisions and recognise good people.

The ISB MBA accelerated this significantly. It gave me frameworks for markets and strategy and organisations that I did not have as a pure engineer. It gave me a language for the business layer.

But here is what I noticed: the breadth became useful because of the depth, not instead of it. The strategy frameworks made more sense because I already understood leverage from engineering. The go-to-market thinking made more sense because I already thought in systems.

Without the foundation in one thing, breadth is just awareness. You know a lot of things at a surface level. You can have conversations. But when you hit a genuinely hard problem, awareness is not enough.

What the Depth Eventually Built

The way an engineer thinks is not just useful for engineering. It is useful for everything.

When I looked at sales and marketing, I did not see a people problem. I saw a systems problem. Something to be instrumented, automated, improved through iteration. That shift in thinking changed how we built our go-to-market from the ground up.

Today, almost everything on the distribution side is automated. Inbound, outbound, content. Built as systems that compound without proportional headcount. That did not come from a marketing hire or a GTM consultant. It came from an engineer who never stopped thinking like one.

That is what the depth buys you. Not just the ability to build the product. The ability to see every problem as a product.

The Lesson, Stated Simply

Your one thing does not have to be tech. It could be sales. It could be design. It could be a specific domain, healthcare or finance or logistics, where you have genuine depth that others do not.

But you need one thing. Something you know all the way down. Something that shapes how you think even when you are nowhere near it.

And alongside it, you need to build the breadth deliberately. Not to become a generalist. To become a founder, which is its own specific thing: someone who can operate across everything while being irreplaceable in something.

That combination, for me, is what made Hyperleap possible. Not the MBA alone. Not the engineering alone. The two together, with the engineering as the foundation everything else was built on.

Go deep first. Then go wide. In that order.

The bottom line: Every founder needs a domain where they are genuinely, uncomplicatedly excellent, and the range to operate across everything else. The depth shapes how you think. The breadth gives you somewhere to apply it. For me it was tech and product. For you it might be something completely different. But it needs to be something.

What is your one thing? And how far down does it actually go?

Young enough to feel invincible. Old enough to know better. I chose the first one.

The startup consumed everything. Long hours, bad food, too much caffeine, no physical activity, and the particular kind of mental load that comes from carrying a company in your head at all times. I told myself this was what building looked like. That this was the price. That I would course-correct once things stabilized.

Things do not stabilize. You just get used to running on empty.

What a Year of This Looked Like

Within twelve months of starting, both my physical and mental health had quietly deteriorated.

I say quietly because it did not happen dramatically. There was no single moment of collapse. It was more like a slow dimming. Energy levels that used to recover overnight stopped recovering. Thoughts that used to feel clear started feeling heavy. The work that used to feel exciting started feeling like something I was pushing through rather than something I was drawn toward.

I was still showing up. Still building. Still doing all the things a founder is supposed to do.

But I was not really there.

The caffeine kept the machine running. The output kept coming. From the outside, nothing looked broken. From the inside, I was running a company on fumes and telling myself it was fuel.

The Morning It Became Clear

It was not a crisis that changed things. No health scare, no intervention, no external event that forced a reckoning.

One morning I just woke up and had a thought so simple it should not have taken a year to arrive: this is not me.

Not the startup. Not the work. Me. The person doing this. The person my kids would grow up knowing. The person my family needed to be present, not just physically in the room but actually there.

I thought about my two kids. About what it would mean to build something and not be there for them in any meaningful sense. About what kind of example I was setting, not intentionally but just by how I was living. About the version of myself I had been before the startup consumed everything and whether that person was still accessible.

Nothing we build matters if our mind is not in our control. That was the realization. Not that the startup was wrong, or that the work was wrong. That I had put the startup first in a way that had quietly cost me the thing that made everything else possible.

Four Days Without a Phone

I had come across Sadhguru and the Inner Engineering program. I decided to go for the retreat.

Four days. No phone. No calls. No updates from the team. No checking in on anything. Completely switched off from the startup and everything around it.

This was harder than it sounds. A founder who has built their identity around being available, around being the person who keeps things moving, around the idea that the company needs them at all times, does not easily let go of that.

What Inner Engineering gave me was not a philosophy or a set of rules. It was a direct experience of what it feels like when your mind is actually under your control. When the noise quiets. When the compulsive loop of thoughts about the business, the team, the metrics, the problems, loses its grip.

I came back after four days a different person. Not because the startup had changed. Not because any of the problems had been solved. Because I had changed. My relationship to the work had changed. My relationship to my own mind had changed.

What Changed After

The shift happened in a sequence I did not expect.

First, mental. The clarity that came from those four days did not fade when I returned. I had tools now. A practice. A different relationship with my own thoughts. The noise was still there, the startup is always generating noise, but I was no longer inside it. I could observe it rather than just react to it.

Then, physical. Once the mental load lifted enough to be managed rather than just endured, I had energy for the body. Movement came back. Food choices improved. Sleep improved. The caffeine that had been propping everything up became unnecessary, or at least optional rather than essential.

And then, gradually, the work itself improved. Not because I was working more hours. Because I was more present in the hours I was working. The decisions were cleaner. The conversations were better. The things that used to spiral into anxiety had somewhere to land before they became reactions.

Priorities became obvious in a way they had not been before. Not as a framework or a set of rules but as something felt. Family first. Health as the foundation that makes everything else possible. The startup as important, deeply important, but not as the thing that everything else is sacrificed for.

What I Got Wrong About Startup Culture

There is a version of founder culture that treats self-neglect as a badge. The hours, the grind, the sacrifice, the sleep deprivation worn almost proudly as evidence of commitment.

I absorbed some of that. Not from any one source, just from the general atmosphere of what it looks like to build something. The images, the stories, the posts from founders who seemed to live entirely for the company.

What that culture does not show is the cost. Not the cost to the company, although there is one. The cost to the person. The slow erosion of the things that make you a full human being rather than just a productivity machine with a company registered to their name.

A founder who is not well cannot make good decisions. Cannot be fully present for the team. Cannot think clearly about the things that matter. Cannot be there for the people who need them outside the company.

You are not a resource to be optimized. You are a person. The company depends on that person being okay.

What I’d Tell Myself Now

Your health is not a cost of building. It is a condition for it. Not a nice-to-have. Not something to return to once things settle. The foundation that everything else sits on. Without it, the building is on sand.

The startup will always feel urgent. Your body and mind will give you quiet signals before they give you loud ones. Pay attention to the quiet ones. By the time the loud ones arrive, a lot of ground has been lost.

Switching off is not weakness. It is maintenance. The four days I spent at the retreat felt like a luxury I could not afford. They were the most leveraged four days I spent in that entire year. Coming back reset was worth more than four days of grinding through the fog.

Find a practice that gives you access to your own mind. Not a productivity system. Not a time management framework. Something that addresses the actual source of the noise. For me it was Inner Engineering. For others it is something else. The specific practice matters less than having one.

Your kids will not remember your company’s growth metrics. They will remember whether you were present. Whether you were well. Whether the person who came home was actually home. That is the work that does not go in any investor update, and it is the work that matters most.

Eight Years Later

Health is non-negotiable now. Not something I manage around the startup but something I protect before everything else.

The practice Sadhguru’s Inner Engineering gave me has stayed. The relationship with my own mind is different. The priorities are clear in a way they were not at 32, not because I am smarter now, but because I have lived the cost of getting them wrong.

The startup is still here. So am I. And being here, actually here, for the company and for the people I love, turned out to require the same thing.

Taking care of the founder.

The bottom line: Health is the first thing founders deprioritize and the most expensive thing to lose. Physical and mental neglect do not announce themselves dramatically. They compound quietly until the person running the company is no longer really running it. Whatever the practice is, find it early. The four days I spent completely switched off changed more than the months of grinding that preceded them.

Have you had a moment where you realized something had to change? I’d genuinely like to hear.

I’m Gopi Krishna, founder of Hyperleap AI, where we build enterprise-grade conversational AI for small and medium sized businesses across the world. This is part of an ongoing series on the mistakes I made in my first years as a founder, written for anyone thinking about starting something of their own. Subscribe to Second Order AI on Substack to follow along.

Knowing it and actually accounting for it are different things.

I knew it. I still built plans that assumed the work would take the time the work takes, and nothing else. And every time, the something else was what undid the timeline.

What the Plan Always Assumed

When you sit down to plan a quarter, or a sprint, or a product launch, the plan is a model of the work. Feature A takes three weeks. Fundraising closes in six. Hiring the engineer takes a month. Customer onboarding is two weeks per account.

The model is internally consistent. The numbers are not invented. They reflect real estimates from people who know the work.

What the model does not contain is any of the following:

The co-founder conversation that needs to happen and keeps getting scheduled and moved. The investor who seemed close and then went quiet for three weeks and needed four more touchpoints before saying no. The key engineer who got sick during the most critical sprint of the quarter. The customer who was ready to sign and then their internal champion changed roles. The compliance filing you forgot was annual. The integration that broke in production the week of the launch. The advisor whose input you needed who was traveling for two weeks.

None of these are unusual. None of them are bad luck in any meaningful sense. They are the normal texture of running a company. They happen every quarter, to every team, in some combination.

And yet the plan never made room for them.

Why We Do This

Part of it is optimism, which is not entirely a flaw. You need some conviction that the thing will happen in order to commit to it. A plan built on genuine pessimism is not a plan, it is a hedge.

But part of it is something more specific. When you plan, you are thinking about the work. The work is concrete. You can estimate it, break it into parts, assign it, track it. The reality around the work is diffuse and unpredictable. You cannot put it in a spreadsheet. And so it does not go in the spreadsheet.

There is also a version of this that is particular to founders who came from large companies, which I did. At Microsoft, there were systems for almost everything. Legal had a process. Finance had a process. HR had a process. When you needed something from another team, there was a way to request it. Things moved slowly sometimes, but the machinery existed and you could rely on it.

In a startup, you are the machinery. And the machinery breaks in ways that the machinery at a large company does not. Your engineer is also your IT support. Your co-founder is also your lawyer for the day when you cannot afford the real one. You are the HR department, the finance team, and the product manager all in the same week.

Every hour you spend on those things is an hour that was in nobody’s plan.

The Specific Ways Timelines Break

After eight years of this, I have noticed that timelines do not break randomly. They break in predictable categories.

People dependencies. Almost everything in a startup depends on another human making a decision or taking an action. Investors, customers, hires, partners, regulators. You can control your own pace. You cannot control theirs. Every external dependency is a potential delay that your plan did not price in.

Context switching. A founder’s day is not a series of focused blocks. It is a series of interruptions that occasionally has a focused block inside it. The sprint that was supposed to take two weeks gets stretched because you spent four days that week on a fundraising conversation, a team issue, and a customer escalation that all needed you specifically.

The decision that was not ready to be made. Some things cannot move forward until a decision is made, and sometimes the decision is not ready. Not because of laziness or poor planning, but because the information needed to make it well has not arrived yet. Waiting for that information is invisible on the plan but very visible in the timeline.

Recovery time. When something goes wrong, and something always goes wrong, the recovery takes time that was not planned. The launch that broke needs a fix. The hire that did not work out needs to be undone and restarted. The pivot requires the team to context-switch from what they were building. Recovery is a real cost that almost no plan includes.

The emotional overhead of uncertainty. This one is hardest to name but very real. Running a startup involves a level of sustained uncertainty that takes energy to manage. There are weeks where the weight of not knowing whether it will work is genuinely heavy. That weight slows things down in ways that do not show up on any project management tool, but are completely real.

The Rule I Eventually Developed

At some point I stopped trying to plan accurately and started planning honestly.

The difference: accurate planning tries to estimate each task correctly. Honest planning accepts that the estimate will be wrong and builds the buffer in from the start.

The rule I use now is simple. Take the timeline that feels right after careful estimation. Double it. That is the number I communicate externally. Internally, the team still works toward the original timeline, because having a real target matters. But the number I commit to with investors, customers, or partners is the doubled one.

This is not sandbagging. It is not being conservative for the sake of looking good when you deliver early. It is accepting that the gap between planned time and actual time is not exceptional. It is structural. And once you accept that it is structural, the right response is to build it into the plan rather than be surprised by it every single time.

The corollary: when someone on the team gives you a timeline, add fifty percent before you write it down. Not because they are wrong. Because they are doing what you did for years, estimating the work and forgetting the reality around it.

What Honest Planning Actually Changes

When you stop underestimating, a few things shift.

You stop having to explain why things are late. Not because you are hiding anything, but because the timeline you committed to was realistic and you hit it. This sounds small. It is not. Repeated lateness, even with good reasons, erodes trust with customers, investors, and your own team. Realistic timelines, consistently met, do the opposite.

You stop making decisions under artificial urgency. When the plan is too tight, everything feels like a fire. You start cutting corners, skipping steps, making calls you would not make if you had more time. Honest planning gives you the time to make better decisions.

You also stop blaming the team for things that were never possible in the first place. A plan that assumes nothing will go wrong will always generate underperformance. A plan that assumes some things will go wrong, and accounts for it, gives your team a real chance to succeed against it.

The Deeper Issue

Underneath the timeline problem is a belief that is worth examining.

Most founders who underestimate timelines are operating from a mental model where the company is behind. There is a gap between where the company is and where it needs to be. And every day that passes without closing that gap feels like failure.

That feeling is what drives the aggressive timeline. If we just execute well for the next quarter, we can close the gap.

The gap does not close that way. Because the aggressive timeline generates the same miss it always generates, and the gap feels as large at the end as it did at the start.

The mental model that actually works is not “we are behind and need to catch up.” It is “this takes as long as it takes, and our job is to keep moving consistently.” That is not resignation. It is accuracy. And accuracy, it turns out, is what compound progress is built on.

Not speed that pretends the reality around the work does not exist.

The bottom line: Founders consistently underestimate timelines not because they are bad at estimating work, but because they plan for the work and ignore everything around it. The fix is not better estimation. It is honest planning that treats delays, dependencies, and disruptions as structural rather than exceptional. Double your timelines. Stop being surprised by the predictable.

What has consistently taken longer than you expected? I’d genuinely like to hear.

I’m Gopi Krishna, founder of Hyperleap AI, where we build enterprise-grade conversational AI but for small and medium-sized businesses across the world. This is part of an ongoing series on the mistakes I made in my first years as a founder, written for anyone thinking about starting something of their own. Subscribe to Second Order AI on Substack to follow along.

Not just professionally. Personally.

They saw what you saw. They were willing to bet on something that had no track record, no brand name behind it, no safety net. They chose you and your idea over more stable options. That means something.

The mistake I made was letting that feeling do the work of a hiring decision.

What Hiring for Gratitude Looks Like

It does not look like desperation. That is the thing. It looks like momentum.

Someone in your network expresses interest. They are smart, you like them, the conversation goes well. They are not the most experienced person you could find for the role, but they are enthusiastic. They believe in what you are building. They say things in the interview that make you feel understood.

You make the offer.

The job description was one thing. What you actually hired was someone who validated your vision at a moment when validation felt scarce.

That is not a hire. That is a coping mechanism with a salary attached.

In the early days of Hyperleap, I made this mistake more than once. People joined because they trusted me, because they liked the idea, because the energy in the room was good. And I said yes to them because their enthusiasm felt like a signal about the company, when really it was just a signal about them being enthusiastic.

The role still needed to be done. The skill gap still existed. The enthusiasm did not fill it.

Why Early Founders Do This

There are a few things happening at once.

The first is psychological. When you are building something from nothing, with limited proof and a lot of uncertainty, every person who says yes feels like confirmation. You are not just filling a role. You are building a case that the thing you are doing is worth doing. New hires become evidence.

The second is practical. Early hiring is genuinely hard. You cannot compete on salary with established companies. You cannot offer the stability a large employer offers. The people with the most experience and the most options have the most reasons to go somewhere safer. So, when someone good enough, someone who seems capable and committed, says yes, the temptation is to close quickly before they change their mind.

The third is relational. Many early hires in Indian startups come through personal networks. A friend. A former colleague. Someone who knows someone. These relationships carry social weight. Saying no to someone you know, someone who is genuinely excited and wants to be part of what you are building, feels like rejection. It feels ungrateful. And we are, as we discussed in Mistake #5, not wired for that kind of confrontation.

So, the hire happens. And the mismatch becomes visible six months later, when the role has grown and the person has not grown with it, or when the skill the role actually needed was never really there.

The Hidden Cost

The easy version of this mistake is financial. You pay someone for work that is not getting done well, you eventually have to let them go, and you start over. That is expensive and slow.

The harder version is what it does to the team.

When someone is in a role, they are not right for, and everyone around them can see it, it creates a particular kind of organisational drag. The people who are doing their jobs well start to wonder why standards are uneven. The person in the wrong role often knows, at some level, that they are not quite right for it. That knowledge creates its own anxiety, its own defensiveness.

And the founder who made the hire out of gratitude is now managing a situation that is harder to resolve because it is also personal. You hired them because they believed in you. Letting them go now feels like a betrayal of that belief. So you wait. You try to make it work. You create a role around their strengths rather than filling the role the company actually needs.

Months pass. The problem compounds.

I have been on both sides of this. I have made the hire and felt the guilt of eventually having to undo it. I have also watched founders I know hold on to people far longer than they should have because the relationship made clarity hard.

Gratitude Has a Place. It Is Not in the Hiring Decision.

Let me be precise about this.

I am not saying you should not hire people who believe in what you are building. Conviction matters enormously in an early hire. Someone who is genuinely excited about the mission, who understands what you are trying to do, who would rather be here than somewhere more comfortable, is a real asset.

What I am saying is that conviction is not a substitute for capability. It is a multiplier on capability. If the capability is not there, the conviction just means they work harder at the wrong things.

The question to ask in every early hire is not “do they believe in this?” It is “can they do this job at the level this company needs, right now, and in six months when the job has evolved?” Those are different questions. The first one is easy to answer in an enthusiastic interview. The second one requires more rigour than most early founders apply.

What the Right Hire Feels Like

This is harder to describe than the wrong hire, but it is worth trying.

The right hire makes you slightly uncomfortable in the interview. Not because they are a bad fit, but because they push back. They ask questions you do not have clean answers to. They have opinions about how things should be done that are not identical to yours. They are evaluating you as much as you are evaluating them.

The wrong hire, the gratitude hire, tends to agree a lot. They are excited. They want the job. The conversation is warm and easy.

Warm and easy is a good sign in a customer conversation. In a hiring conversation, it is worth examining.

The person who challenges you in the interview is not being difficult. They are showing you that they have standards of their own. That they are not just looking for a place to land. That they will hold themselves and you to something.

That is who you want in the company when things get hard.

What I’d Tell Myself Now

Write the job description before you start talking to people. Not a list of requirements copied from another job posting. A real description of what this person will do in the first ninety days, what success looks like at six months, and what the hardest parts of the role are. Then use that as the filter, not the energy in the room.

Separate the relationship from the hire. If someone you like and respect applies for a role, run the same process you would run for anyone else. If they are the right person, the process will confirm it. If they are not, better to know before you make the offer than after.

Gratitude does not belong in the hiring room. Being moved that someone believes in you is fine. It is human. But the moment you find yourself leaning toward a hire because you feel grateful for their enthusiasm, that is the moment to pause and ask harder questions.

Hire for the role the company needs, not the role you can sell to the candidate. Early founders sometimes unconsciously reshape the role to match the candidate rather than the other way around. You end up describing a version of the job that sounds exciting and achievable for this particular person, rather than the version of the job that actually needs doing.

Move faster on mismatches than feels comfortable. When you realise you have made a gratitude hire and the mismatch is real, the kindest thing you can do for everyone is address it early. The longer you wait, the more expensive it becomes for the company, and the more painful it becomes for the person.

The Underlying Lesson

Early hiring is one of the highest-leverage decisions a founder makes. The first ten or fifteen people shape the culture, the standards, and the velocity of everything that follows.

When you fill those seats with people who are right for the role, you build something that compounds. When you fill them with people you hired because they believed in you, you build something that needs constant maintenance.

Belief in the founder is a starting point. It is not a qualification.

The company you are building needs people who can do the work. Your job as the founder is to find them, even when finding them is harder and slower and less immediately gratifying than hiring the person in front of you who really, really wants to be there.

The bus needs the right people on it.

Not just the willing ones.

The bottom line: Early founders often hire people who are excited about the founder and the vision rather than demonstrably right for the role. Enthusiasm feels like a signal. It is not a substitute for capability. The gratitude hires costs more than the gap hire, because it comes with a relationship that makes the inevitable correction harder and slower.

Have you made a gratitude hire? How did you handle it when you realised the fit was off? I’d like to hear.

I’m Gopi Krishna, founder of Hyperleap AI, where we build enterprise-grade conversational AI but for small and medium sized businesses across the world. This is part of an ongoing series on the mistakes I made in my first years as a founder, written for anyone thinking about starting something of their own. Subscribe to Second Order AI on Substack to follow along.

Imagine you are driving a bus.

Not a comfortable, air-conditioned coach with assigned seating and a clear itinerary. A startup bus. The destination is real but the route is uncertain. The schedule keeps changing. Most people you know think the trip is a bad idea. Some of them say so. Most of them just don’t show up.

Some people climb on early. They believe before there is proof. They are willing to be uncomfortable. They help figure out the route as you go.

Some people join later, once there is traction, once the destination feels more real. That is fine. Late passengers are still passengers.

And then there are the people at the bus stop who watch you pull up, consider it, and do not get on. They have their reasons. Maybe the destination does not excite them. Maybe the timing is wrong. Maybe they believe in you but not in this particular trip.

The mistake is not that they did not get on.

The mistake is leaving the engine running for them.

What “Not Burning Bridges” Actually Costs

We are taught, almost universally, that not burning bridges is wisdom. Keep relationships warm. You never know who you will need later. Be the bigger person. Leave doors open.

This is reasonable advice for most of life. For a founder in the early stages of building something, it can quietly become a trap.

Because not burning bridges with people who are not on your bus means you are maintaining relationships that are not moving you forward. You are spending emotional energy on people who have made their choice. You are keeping yourself available to people who are not keeping themselves available to you.

And startup energy is finite. More finite than most founders want to admit.

Every hour spent maintaining a warm relationship with someone who quietly checked out is an hour not spent on the people who are actually here. Every mental cycle spent wondering if an ex co-founder might come back, or if that early advisor might re-engage, or if that first hire who left might return, is a mental cycle not spent on the people sitting on the bus waiting to move.

The bus is already carrying weight. Do not drag it with the weight of people who got off.

The People Who Get Off the Bus

They are not all the same. It helps to understand who they are.

The early believer who lost faith. They were with you at the start. Genuinely. But somewhere along the way, the conviction faded. Maybe the product was harder than expected. Maybe life changed their priorities. Maybe they just realized this was not their destination. They drifted out, often without a clear conversation. You kept the door open. They never came back through it.

The co-founder who was never fully in. We covered this in Mistake #4. But it applies here too. When the co-founder dynamic breaks down and someone leaves or steps back, the temptation is to preserve the friendship at the cost of clarity. You stay in touch. You keep it warm. You avoid the harder conversation about what they still hold and what they still owe. Not burning that bridge ends up costing you both time and equity.

The advisor who took the title but not the role. They were excited when you asked. They said yes. They showed up for the first two calls and then got busy. You kept sending updates. You kept scheduling check-ins they would reschedule or miss. You told yourself they would re-engage when the time was right. They were never going to re-engage. They had already moved on, they just had not said so.

The investor who passed but kept the conversation going. They liked the space. They liked you. They just did not write the check. But they kept the door open with language that felt encouraging. You kept sending updates, kept nurturing, kept hoping this time the conversation would close. Some of these relationships do eventually convert. Most do not. And you will not know the difference until you are honest enough to force the clarity.

The potential hire who stayed on the fence. They were interested. They had two more conversations. They asked for more time. You waited. And then waited more. You did not want to pressure them and lose the relationship. They joined someone else six months later.

Why We Don’t Burn the Bridge

The reasons feel legitimate in the moment.

You genuinely like these people. That is real. The relationships were real. It feels harsh to write them off because circumstances changed.

You are also, if you are honest, hedging. Part of you believes that keeping the door open means they might come back. That the ex co-founder might return when the company is further along. That the advisor might re-engage when the product is more developed. That the investor might reconsider when the metrics improve.

Sometimes this happens. The error is treating it as a strategy rather than an occasional coincidence.

And in India especially, there is the cultural layer again. We do not end things cleanly. We let them fade. We stay in ambiguous holding patterns rather than have the conversation that would give everyone clarity. Not burning bridges, in the Indian professional context, often means not having direct conversations about the state of a relationship.

That ambiguity has a cost. And it is usually paid by the founder, not by the person who got off the bus.

What Burning the Bridge Actually Means

Let me be clear about what I am not saying.

I am not saying be cruel. I am not saying cut people off dramatically. I am not saying hold grudges or make departures painful.

Burning the bridge, in this context, means accepting with clarity that someone has made a choice and releasing the relationship from active maintenance.

It means stopping the update emails to the advisor who stopped responding.

It means having the direct conversation with the co-founder who left about what the equity situation actually is, rather than leaving it unresolved in the name of keeping things friendly.

It means telling the investor who has been stringing you along that you are closing the round and you need a decision.

It means accepting that the person who watched the bus pull away made a decision, and your job is not to convince them they made the wrong one.

None of this is burning a bridge in the dramatic sense. It is just accepting reality and redirecting your energy accordingly.

The People on the Bus

Here is the flip side of this mistake, and it is the more important part.

While you are maintaining relationships with people who are not on the bus, you are underinvesting in the people who are.

The early employee who took a bet on you and is grinding through the hard part. The co-founder who is still here. The customer who gave you a chance before you had proof. The investor who wrote the first check. The advisor who actually shows up.

These people deserve more of you than they are getting when you are distributing your energy across people who have already checked out.

Not burning bridges with the wrong people is, in effect, a slow way of burning bridges with the right ones.

What I’d Tell Myself Now

Clarity is a kindness, not a cruelty. When someone has stopped showing up, having a direct conversation about it is kinder than maintaining the ambiguity. It lets both people move forward. It respects the other person enough to tell them the truth.

Audit your relationship maintenance. Look at who you are keeping warm. Ask honestly whether those relationships are active or residual. If someone has not added value in six months and you are still investing time in the relationship, ask why.

Convert ambiguous relationships to clear ones. The advisor who has gone quiet needs a direct conversation, not another update. The investor in a holding pattern needs a deadline, not more nurturing. Force the clarity. Whatever the answer is, it is better than the limbo.

Protect the energy of the people on the bus. Your team, your active partners, your paying customers. They are here. They chose this. They deserve your full attention, not the remainder after you have spent energy on people who chose something else.

Not every departure needs a door left open. Some people leave and should leave cleanly. A co-founder who took equity and contributed little. A hire who undermined the culture on the way out. An advisor who misrepresented what they could offer. These bridges do not need to be maintained. Letting them go is not bitterness. It is resource management.

Eight Years In

I wasted real energy on this. Not dramatically. Gradually.

Check-ins with people who had moved on. Updates to advisors who were no longer engaged. Warmth extended to relationships that had already ended, just without the formal acknowledgment.

Meanwhile the people on the bus kept driving. And the destination kept getting closer, not because of the people I was trying to keep, but because of the ones who stayed.

The bus does not wait. It should not wait. And you cannot drive it well while you are looking in the rearview mirror at people who got off at an earlier stop.

Know who is on the bus. Focus there. Move. And keep moving!

The bottom line: Not burning bridges sounds like wisdom. For founders, it often becomes a way of avoiding clarity about relationships that have already ended. Every unit of energy spent maintaining connections with people who have left is energy not spent on the people who stayed. Audit the relationships you are maintaining. Force the clarity. Drive the bus.

Who have you been waiting for that you should have let go? I’d genuinely like to hear.

I’m Gopi Krishna, founder of Hyperleap AI, where we build enterprise-grade conversational AI but for small and medium size businesses around the world. This is part of an ongoing series on the mistakes I made in my first years as a founder, written for anyone thinking about starting something of their own. Subscribe to Second Order AI on Substack to follow along.

There is an image most of us grew up with. Three monkeys, seated side by side. One covers its mouth. One covers its eyes. One covers its ears.

Speak no evil. See no evil. Hear no evil.

It is a deeply embedded cultural value in India, and in many parts of Asia. The idea that a good person does not amplify negativity. Does not call out what is wrong. Does not dwell on the bad. Stays positive. Stays constructive. Does not rock the boat.

It is also, as a startup operating philosophy, a near-perfect recipe for failure.

What It Looks Like in Practice

The three monkeys do not announce themselves. They show up quietly, dressed as virtue.

Speak no evil looks like not calling out the flaw in your own approach during a planning meeting. You have a nagging sense that the go-to-market is not right, or that the pricing is off, or that a core assumption has not been tested. But someone worked hard on it. It would feel like stepping on toes. You tell yourself someone else has thought this through. It will work itself out.

And there is a version of this that goes even deeper than avoidance. In some cultures, including ours, there is a genuine belief that naming a bad outcome invites it. If someone predicts a product will fail and it does, the prediction itself gets blamed. That is not accountability. That is superstition. And it is a remarkably effective way of ensuring that no one ever tells you the truth about your own company.

It does not work itself out.

See no evil looks like watching a competitor do something that is working and deciding it does not count. They are gaming the algorithm. They are buying reviews. They are growing through tactics that feel beneath you. And so you look away and return to your own path, telling yourself that only the truly good product wins in the long run.

Sometimes that is true. More often, you just gave a competitor a head start while you were busy feeling superior about your methods.

Hear no evil looks like getting a bad review from a customer and finding a reason not to listen to it. They are the wrong customer. They did not use the product correctly. They have an unusual use case. One data point is not a trend.

It also shows up inside the founding team. Sometimes a co-founder hears the same bad feedback and privately agrees with it. But rather than say so and create friction, they stay quiet. The problem gets two votes of silence instead of one. And so it compounds.

Except when it is. And you won’t know the difference if you keep explaining away every data point that does not fit the story you want to be true.

Why This Happens

This is not about intelligence. Most founders who fall into this pattern are smart people who are working hard and genuinely want their company to succeed.

It is about how we are wired, culturally and psychologically.

In India especially, confrontation is not a neutral act. It carries social weight. Calling out a problem in a shared plan means someone owns that problem, someone might lose face, someone’s effort gets questioned. In a culture that values harmony and indirect communication, the path of least resistance is almost always to not say the thing.

And then there is the psychological layer that has nothing to do with culture. Founders are, by definition, people who have bet on an idea. The whole enterprise requires a certain suspension of doubt. The cognitive bias toward confirming what you already believe is strong in everyone. In founders it is often stronger because the alternative, admitting the idea might be wrong, is not just intellectually uncomfortable. It threatens the entire reason you are doing this.

So the three monkeys become a coping mechanism. A way of maintaining conviction in the face of contradictory evidence.

The problem is that conviction built on ignored evidence is not conviction. It is denial with a better PR strategy.

The Cost of Each Monkey

Speaking no evil means problems compound. A go-to-market flaw that could have been caught and corrected in month two becomes a structural issue by month eight. A co-founder dynamic that felt awkward to raise becomes an existential conflict. A pricing model that was never really stress-tested becomes the reason the unit economics never work.

Small things that were never said become big things that cannot be fixed.

Seeing no evil means you cede learning. Your competitors, ethical or otherwise, are running experiments in the market every day. When something works for them, that is a signal about the market. Not necessarily a signal to copy, but a signal to understand. Looking away from what works because you don’t like how it was done leaves you operating on a smaller set of information than the market actually contains.

You do not have to admire what your competitors do. But you do have to watch it.

Hearing no evil means customers stop telling you things. Not because they have nothing to say, but because their feedback does not visibly land. The founder who consistently explains away negative feedback trains their team, their advisors, and eventually their customers to stop offering it. You end up in a room where everyone agrees with you, which feels like validation and is actually the most dangerous place a founder can be.

The Version That Nearly Got Me

I did all three. Not all at once, not dramatically, just enough, just often enough, to miss the signal exactly when I needed it most.

For me, the sharpest version of this was hearing no evil.

Early on, I had customers give feedback that pointed clearly toward a problem with how we had positioned the product. Not a product problem. A framing problem. The right people were not immediately understanding what we did and why it mattered for them.

But the feedback came from customers I had mentally categorized as not quite the ideal fit. And so, I discounted it. They didn’t fully understand the vision. They were evaluating it through the wrong lens. The right customers would get it.

Months later, when I finally stopped explaining and started listening, the feedback from my “ideal” customers was saying the same thing.

The customers I had written off were not the wrong customers. They were early signal I had chosen not to receive. A selective bias.

What I’d Tell Myself Now

Build a habit of naming the uncomfortable thing first. In every planning meeting, every strategy discussion, every co-founder conversation, make it someone’s job to say what is not working or what has not been tested. Not as an exercise in pessimism. As an exercise in intellectual honesty.

Separate your competitor’s tactics from your values. You do not have to use every tactic a competitor uses. But you do have to understand why it is working. Dismissing competitor behavior because it feels beneath you is just another form of looking away. Watch, understand, then decide.

Treat negative customer feedback as the most expensive data you will ever get for free. A customer who tells you something is wrong has done you a service. A customer who stops using the product and never says why has not. Create conditions where people feel safe telling you things you do not want to hear.

Find at least one person whose job it is to challenge you. An advisor, a co-founder, a board member, a peer. Someone who will not soften the thing that needs to be said. Someone who is not trying to protect your feelings. This person is more valuable than five people who tell you the product is great.

In India, name the cultural bias explicitly. When you notice yourself or your team avoiding a hard conversation because it feels culturally uncomfortable, say that out loud. “I know this is awkward to raise, and I’m going to raise it anyway.” That one sentence does a lot of work. It names the discomfort without letting it win.

The Broader Lesson

Startups run on information. The quality of your decisions is bounded by the quality of the information you are willing to receive.

Every time you speak no evil, you lose information about your own plan. Every time you see no evil, you lose information about the market. Every time you hear no evil, you lose information about your customers.

The three monkeys are not protecting you. They are just making the eventual collision with reality more expensive.

The startup that confronts reality clearly, even when it is uncomfortable, especially when it is uncomfortable, is the one that gets to keep adjusting. The one that looks away does not get that chance.

Optimism about outcomes is a virtue. Optimism about inputs is a liability.

You can believe the company will succeed. You should. But believing it will succeed despite the flaw you have not named, the competitor you have not watched, the customer you have not listened to. That is not optimism. That is the three monkeys at work.

The bottom line: The cultural instinct to avoid speaking, seeing, and hearing evil is deeply human and specifically sharp in the Indian context. In startups, it manifests as not naming flaws, not watching competitors, and not listening to bad feedback. All three compound over time. All three are correctable. The correction starts with naming what you have been avoiding.

Where have you caught yourself doing one of these three? I’d genuinely like to hear.

I’m Gopi Krishna, founder of Hyperleap AI, where we build enterprise-grade conversational AI but for small and medium businesses. This is part of an ongoing series on the mistakes I made in my first years as a founder, written for anyone thinking about starting something of their own. Subscribe to Second Order AI on Substack to follow along.

This one is hard to write. Not because the lesson is complicated. Because it requires saying something that founders rarely say in public: something everyone in the room already knows, and nobody wants to be the one to name.

So let me name it.

The Thing Nobody Says Out Loud

Not every co-founder brings the same passion to the table.

The founder who brings more knows they bring more. The founder who doesn’t. Knows too. This is not a secret inside the founding team. It is an open secret that everyone has silently agreed not to discuss.

And that agreement, that collective silence, is where the damage happens.

The imbalance usually does not show up on day one. Early on, everything is energy and possibility. Everyone is excited. Everyone is putting in hours. The gap is easy to overlook or explain away.

It shows up later. When the work gets harder. When the market does not respond the way you expected. When the thing that needed to be done this week did not get done, and the reason given sounds logical but something about it does not sit right.

That is when you start doing the math. And the math does not add up.

The 12-Hour Problem

Both founders are putting in 12 hours a day. You can see it. They are online. They are in the calls. They are busy.

But their 12 hours is your 4.

Not because they are lazy. Not necessarily because they are less intelligent. But because the level of investment is different. The skin in the game is different. The thing that keeps you awake at 11pm thinking about a customer problem. That thing is not keeping them awake.

And when you raise this, gently or otherwise, the responses come quickly.

“No one can sustain more than 4 hours of real productive work anyway.” “I work smart, not just hard.” “My contributions will show up in areas that are harder to measure.” “You’re too in the weeds to see the strategic value I’m adding.”

Each of these might be partially true in isolation. Together, they form a pattern: a sophisticated defense of undercontribution that sounds reasonable enough that you start to doubt your own read of the situation.

You are not wrong. Trust the math.

Equal Stakes, Unequal Investment

Here is where it gets genuinely painful.

Because alongside the imbalance in contribution, there is usually parity in expectation. Equal equity. Equal say. Equal claim on the outcome, on the thing you are pouring everything into.

And that is not inherently unreasonable. Co-founders negotiate equity at the beginning, when nobody knows how things will go. The split reflects the deal that was made, not the reality that emerged.

But the reality that emerged is what you are living with every day.

In India, this compounds further. There is a cultural disinclination toward direct confrontation, especially in close relationships. Many co-founding teams start as friends, or at least as people who want to remain friends. The conversation that needs to happen, “this is not working and we need to restructure,” is the exact conversation that the culture makes hardest to have.

So it does not happen. Things just sit. Misalignment compounds. Resentment builds on one side, defensiveness on the other. And the company pays the price for a conversation two people could not bring themselves to have.

The Variation That Makes It Worse

Sometimes the co-founder is not even fully present.

They have a full-time job. They are doing this on the side. And they are still holding substantial equity in something they are treating as a side project.

This is more common than people admit. The arrangement often starts with good intentions: “I’ll transition fully once we get some traction.” But traction takes time, and the transition keeps getting pushed, and meanwhile the equity structure is frozen in place from a commitment that was made when the terms were different.

The founder who is all-in watches the co-founder juggle two lives. Takes calls between meetings at their day job. Reviews things on weekends when they have bandwidth. Contributes when convenient.

And holds 30, 40, 50 percent of the company.

This is not a character flaw on the co-founder’s part. It is a structural failure that was allowed to persist because the harder conversation was never had.

What I Did and What I Saw

I wasted about a year this way early on. I recognized it, addressed it, and moved on. I am not going to say it was easy. It wasn’t. But catching it at year one is very different from catching it at year three.

I watched a friend’s fintech go through this more recently. Two years of building. A real product, a real market, real early signals. It broke down not because the idea was wrong but because the founding team equation was wrong from the beginning. Two years. Gone. Not to competition, not to market forces. To a conversation that should have happened in month three.

That is the cost of the silence.

What I’d Tell Myself Now

Evaluate co-founder fit like you evaluate product-market fit. You would not let a product assumption go untested for a year. Do not let a founding team assumption go untested either. Set clear expectations early about what contribution looks like: in hours, in output, in accountability.

Equity should reflect reality, not aspiration. Vesting schedules with cliffs exist for this reason. Use them. A four-year vest with a one-year cliff means that if the fit is not there, you find out before someone walks away with equity they did not earn.

Name the thing when you see it. The longer you wait, the more expensive the conversation becomes: in equity, in time, in the relationship itself. Naming it early is uncomfortable. Naming it two years later is devastating.

In India specifically, find a way to have the direct conversation. The cultural resistance to confrontation is real. It is also something you need to work around if you are building something serious. The business does not care about cultural comfort. It cares about whether the right things are getting done by people who genuinely want to be there.

Side projects and serious startups have different clocks. If a co-founder is not fully committed, that needs to be reflected in the structure. A different equity split, a different role, a different timeline for transition. Whatever the terms are, they should match the reality, not the intention.

The Harder Truth

The hardest part of this mistake is that it is almost never about bad people. Co-founders who undercontribute are not villains. They often genuinely believe they are doing their part. They often genuinely want the company to succeed.

But belief and want are not enough. Startups run on execution. And execution requires the kind of investment that you cannot fake, cannot schedule around a day job, and cannot substitute with good intentions.

The question is not whether your co-founder is a good person. The question is whether they are the right person for this specific thing, at this specific stage, with this specific level of commitment.

Those are different questions. And conflating them is where the year, or two years, gets lost.

The bottom line: Co-founder misalignment on passion and commitment is one of the most common and most avoidable reasons early startups fail. The imbalance is usually visible early. The conversation is usually delayed too long. In India, the cultural tendency to avoid direct confrontation makes this worse. Name it early, structure for it honestly, and do not let politeness cost you years.

Have you navigated a co-founder mismatch? How did you handle it, or how do you wish you had? I’d like to hear.

I’m Gopi Krishna, founder of Hyperleap AI, where we build enterprise-grade conversational AI for small and medium businesses across the world. This is part of an ongoing series on the mistakes I made in my first years as a founder, written for anyone thinking about starting something of their own. Subscribe to Second Order AI on Substack to follow along.

Not a real person. A composite. A blur of faces from my Microsoft years: colleagues, managers, peers from across the org. Smart people. People whose opinions I respected. People who had nothing to do with what I was building.

And I was writing for them.

The Setup

I spent over 11 years at Microsoft. Nearly all of my post-college friendships were formed there. When I came back to Hyderabad in 2017 to do my MBA and start building, I didn’t leave that world cleanly. It came with me: in my contact list, in my LinkedIn network, in my head.

So when I sat down to write a post about something I was learning, or a take I had on the market, or something unconventional I wanted to try, the question that surfaced first was: what would X think of this? What would Y say?

X and Y were not my potential customers. They were not founders figuring out similar problems. They were engineers and product managers at one of the largest software companies in the world, looking at a former colleague who had gone off to “start something in India.”

I was optimizing my message for people who were never going to buy what I was selling.

What Optimization for the Wrong Audience Actually Looks Like

It is subtle. That is what makes it hard to catch.

It does not mean you write badly. It means you write safely. You pick angles that feel respectable rather than angles that feel true. You avoid takes that might read as desperate, or naive, or too salesy, or too raw.

You stay legible to people who already know you, instead of becoming findable to people who need to find you.

Every time I tried something different, a more direct take, a more vulnerable post, something that felt genuinely useful to an early-stage founder or a business owner exploring AI, the DMs would come. Old friends from Microsoft. Sometimes encouraging. Sometimes curious. Occasionally skeptical.

And my brain would register that as signal. People noticed. People responded. Keep doing this.

But those people were not the signal I needed. They were comfortable noise.

The posts that reached actual potential customers, that got shared in circles I had no visibility into, that led to someone reaching out about a real business problem. Those looked different. They felt different to write. More exposed. Less polished. More direct about the specific pain I was trying to solve.

I wrote fewer of those, for longer than I should have, because they made me uncomfortable in front of the wrong audience.

The Deeper Problem

When you come from a large company, especially one with a strong culture like Microsoft, you internalize a certain standard of how a professional presents themselves.

Measured. Credible. Not too promotional. Thoughtful about optics.

Those instincts are not wrong inside that context. Inside a large organization, managing perception across a complex stakeholder map is a real skill that has real value.

Outside it, as a founder trying to find your first hundred customers, those same instincts become a handicap.

Your potential customers do not care about your optics. They care about whether you understand their problem. The fastest way to demonstrate that is to talk about it directly, specifically, and without the careful hedging that reads as professional in a corporate context and reads as vague in a founder context.

I knew this intellectually. I had read enough about founder-led content to understand the theory. But theory does not override the discomfort of posting something raw and knowing that your former skip-level manager might read it over their morning coffee.

What Actually Changed

It took a long time. And it was not a single realization. It was a gradual loosening.

Part of it was simply time. The further I got from Microsoft, the less that mental editor had authority. New connections started to outnumber old ones. The feedback I was getting from posts started to come from people who were actually in my world: founders, business owners, operators. Rather than people who were curious about what I was up to from a previous life.

Part of it was watching what actually worked. The posts that performed, not just in likes but in conversations that led somewhere real, were consistently the ones that ignored the composite editor on my shoulder.

Part of it was accepting that the discomfort was not a warning signal. It was a calibration signal. If a post felt uncomfortable to publish, it usually meant it was saying something true and specific, which is exactly what it needed to say.

You are not writing for the audience you have. You are writing for the audience you need.

Those are different people. And until you accept that, every post is a compromise between the two.

What I’d Tell Myself Now

Your LinkedIn network at the start is a historical artifact, not your target market. The connections you have reflect where you have been. The connections you need reflect where you are going. Optimize for the second group, even when the first group is louder.

DMs from old colleagues are not product validation. Engagement from people who already know and like you is warm and real, but it tells you nothing about whether strangers will find you relevant. Track the responses from people you do not recognize. Those are the ones that matter.

The posts that feel most exposed are usually the most useful. The instinct to soften, qualify, and hedge comes from a corporate context where those things protect you. In a founder context, they obscure you. Say the thing directly.

Write as if your best potential customer is reading, not your former manager. This sounds simple. It is not. But it is the right frame. Every post is an audition for the customer you want, not a performance review for the career you left.

Eight Years Later

I still occasionally feel that old pull. A thought before hitting publish: what would someone from my Microsoft days think of this?

It comes up less now. The network has shifted. The context has shifted. And I have enough evidence from posts that worked, that found the right people and started the right conversations, to trust the discomfort more than the caution.

But I wasted real time getting here. Years of posts that were competent and forgettable. Years of playing to a room that was never going to become my business.

The room you are writing for shapes everything you write. Make sure you know which room that is.

The bottom line: Early-stage founders who come from large companies often carry an invisible audience in their heads: former colleagues whose approval they are still, unconsciously, seeking. That audience is the wrong one. You need to write for the people who do not know you yet, which means being specific, direct, and comfortable with being uncomfortable.

Who are you actually writing for when you post? I would genuinely like to hear how others have navigated this.

I’m Gopi Krishna, founder of Hyperleap AI, where we build enterprise-grade conversational AI but for Small and Medium Businesses. This is part of an ongoing series on the mistakes I made in my first years as a founder, written for anyone thinking about starting something of their own. Subscribe to Second Order AI on Substack to follow along.

When you decide to start a company in India, everyone talks about the idea, the market, the team. The fun stuff. Nobody sits you down and says: “Before you do anything else, understand that you are about to create a legal entity that is extremely easy to start and extremely hard to stop.”

I learned this the hard way. Three times.

How It Started

Within a month of incorporating my first company, a friend came to me with an idea in the real estate space. He had the domain expertise. I had the technical capability. It seemed obvious. Let’s build together.

So we incorporated a second company.

A year later, I started a third, this time in HR tech. Different space, different collaborator, same pattern: enthusiasm first, paperwork second, consequences much later.

Three companies. One common founder. Me. Zero understanding of what that actually meant on paper.

The Logic That Made Sense at the Time

I wasn’t being reckless. There was actual reasoning behind each decision.

The thinking went something like this: one product, one company. Cleaner co-founder dynamics. Cleaner cap table if we ever went to raise money. Each venture would stand on its own. No cross-contamination of equity, no messy shared structures.

On paper, that logic holds. In practice, what it meant was that I was a single individual carrying the compliance obligations of three separate legal entities, simultaneously, while trying to build product, find customers, and figure out what I was actually doing.

That’s where the logic broke down. Not in the structure. In the execution capacity of one person.

Looking back, I think part of it was jetlag from my corporate journey. At Microsoft, there were entire teams for legal, finance, compliance. You filed a form and someone else handled it. Structure felt like infrastructure: invisible, always there, always working. I carried that assumption into a world where I was the infrastructure.

Where Those Three Companies Ended Up

Company one is my current company, which I’m still building. Eight years in. Real customers, real revenue.

Company two, the real estate venture, is still alive. Not active. Just... alive. Every year, nil returns. Every year, a CA invoice. Every year, the intention to finally initiate the strike-off process. That intention is now in its sixth year.

Company three, the HR tech venture, we managed to shut down during COVID. That was the first time I actually understood what a proper wind-down looks like.

What “Running a Private Limited Company” Actually Means

When you incorporate a Pvt Ltd in India, you’re not just creating a business. You’re creating a compliance obligation that runs independently of whether the business is active or not.

Every year, regardless of whether you have a single rupee of revenue, you need to:

• File annual returns with the MCA

• File income tax returns

• Maintain a registered office address

• Hold a board meeting (yes, even if it’s just you)

• File audited financial statements

This is manageable when you have an active business and a CA who handles it routinely. It becomes a recurring low-grade headache when the company is dormant and you keep telling yourself you’ll deal with it properly next quarter.

And dissolving a Pvt Ltd in India? That’s a separate ordeal. Strike-off applications, NOCs, clearances, timelines that stretch for months. Most founders I know with dormant companies have made the same quiet calculation: it’s easier to just keep filing nil returns than to go through the process of shutting down properly.

The compliance burden of a private company in India doesn’t scale with your revenue. It runs on its own clock, regardless of how the business is doing.

That asymmetry is brutal in the early days. And surprisingly persistent years later.

What You Actually Need When You’re Starting Out

Here’s the thing nobody tells you clearly enough: when you’re in the early days of building something, what you need is users. People who are even remotely interested in what you’re making. Signal that the idea has any pull at all.

What you don’t need, at least not yet, is papers on papers of documentation, board resolutions, MCA filings, and registered office maintenance for two companies you haven’t had time to build anything inside of.

The compliance overhead isn’t fatal. But it consumes the one resource early-stage founders have least of: attention. Every hour spent on administrative obligations for a dormant entity is an hour not spent talking to customers, shipping product, or figuring out whether the business has any reason to exist.

I underestimated this completely. And I think the reason I did is that I came from a world where compliance was someone else’s problem.

What I’d Tell Myself Now

Start with an LLP or a sole proprietorship for early experiments. Unless you’re raising institutional money from day one, the Pvt Ltd structure is overkill for a company that hasn’t found product-market fit. An LLP has significantly simpler compliance. A sole proprietorship even more so. You can always convert when the business justifies the structure. There are reasons you might not even want to start a company in India, and incorporate elsewhere, but that’s for a later blog.

Treat company formation like a hiring decision. You wouldn’t hire someone without understanding the full commitment: salary, notice period, obligations on both sides. Think about incorporating the same way. What are you signing up for, not just this year, but every year this entity exists?

Don’t co-found a company out of convenience. Convenience and genuine alignment are different things. Shared enthusiasm in the first conversation is not the same as shared vision over five years. If you’re going to carry the compliance burden of a co-founded company, make sure the foundation is real.

If a company is genuinely dead, kill it properly. This sounds obvious. It isn’t. There’s always a reason to delay. The process is annoying, you might need the entity someday, nil returns are cheap. But cheap and free are different things. Every dormant company is an open loop. Multiply that by years and it becomes real cognitive overhead.

Eight Years Later

My primary company (Hyperleap) is still going and strong. The HR tech company is cleanly shut down. The real estate company exists in a permanent state of administrative limbo. Not dead enough to bury, not alive enough to matter.

This isn’t a story with a clean resolution. It’s a story about a class of mistake that compounds quietly. Not the kind that threatens the business in a visible, dramatic way. The kind that drains time and attention in small, regular doses, year after year, until the cost is too distributed across time to even add up properly.

The first mistake in this series, not having a product idea before starting, is visible. You can point to it. This one is invisible. It hides in a CA’s calendar, in MCA portal reminders, in the annual ritual of signing documents for a company that hasn’t done anything meaningful in years.

But invisible mistakes have a way of becoming visible at the worst times.

The bottom line: Starting a company creates obligations that run independent of whether the business works. What early-stage founders need is users and signal, not administrative complexity across multiple entities. Understand what you’re creating before you create it, and think hard before creating more than one.

Have you dealt with dormant companies as a solo founder? Still in the “just file nil returns” stage? I’d genuinely like to hear how others have handled this.

I’m Gopi Krishna, founder of Hyperleap AI, where we build enterprise-grade conversational AI for businesses across India. This is part of an ongoing series on the mistakes I made in my journey as a founder, written for anyone thinking about starting something of their own. Subscribe to Second Order AI on Substack to follow along.

I had just finished my MBA at the Indian School of Business. I had conviction, energy, and a genuine desire to build something of my own. What I didn’t have, and this took me embarrassingly long to admit, was any idea what to build.

Not “a fuzzy idea I needed to sharpen.” Actual zero. A blank whiteboard.

I assumed this was a temporary problem. I’d figure it out. I’d read enough startup content to know you’re supposed to “find a problem worth solving.” So I started looking for problems.

What followed was months of spinning. I had lists of ideas. I talked to people. I changed direction every few weeks. And underneath all of it was a quiet panic that I was somehow doing it wrong, that other founders just knew, and I didn’t.

Eight years later, after COVID, failed startups, failed products (they’re not the same thing, by the way), raising money, and waking up the next morning anyway, things are actually working. Real customers, real growth, across industries I never imagined.

But I made mistakes that cost me years, not months. This is the first in a series where I’ll be talking about them in the hope that I can help atleast one of you to not make mistakes too similar to mine.

The Mistake: Starting with the Product

The conventional startup narrative goes like this: you have an insight, you build a product, you find customers.

It sounds logical. It’s mostly backwards.

If you’re a technology person, and I am, unapologetically, your instinct is to build first. You want to code something, ship something, have something to show. The problem is that without deep domain knowledge, you’re building in a vacuum. The product comes later. Sometimes much later.

I didn’t have a domain. I had skills. That’s not enough.

What I’d Actually Do Differently

Here’s the honest answer, and it’s not what most people (incl. me at that time) want to hear:

Start with a consulting business.

Not as a fallback. Not as a “side thing while I figure out the product.” As an intentional first step.

Pick an industry where you have some access, through your network, your background, your geography. Offer to solve real problems for real businesses. Charge for it. Not for free, not for “experience.” Money.

This does three things that no amount of ideation can replicate:

You learn what the actual problems are. Not the problems people say they have in a survey. The ones they’ll pay someone to fix. Those are very different lists.

You build domain expertise fast. When you’re a pure technology person entering an industry cold, you don’t know what you don’t know. Consulting forces you to get fluent in the language, the workflows, the actual pain.

You find your product. You do something manually for three clients. You realize you’re building the same thing every time. That’s your product. If you can’t sell the solution as a service, you can’t sell it as a product.

The pattern isn’t: build a product, then find customers. It’s: find customers, do the work, then productize what works.

The Co-Founder Problem Nobody Talks About

There’s a compounding issue here that I learned the hard way.

If you’re a solo technical founder with no domain expertise, you are in a genuinely difficult position. You know how to build. You don’t know what to build or for whom. And without a co-founder who brings that domain knowledge, there’s no one to pressure-test your assumptions.

Things get messy. Quietly, slowly messy. You make product decisions based on what’s technically interesting rather than what the market actually needs. You mistake complexity for progress.

If you don’t have a co-founder, especially early, find domain experts to work closely with. Consult with them, hire them as advisors, give them equity if you have to. The gap between “can build anything” and “should build this specific thing” is wider than it looks.

And if your instinct right now is “I’ll just learn the domain myself,” yes. Consulting is how you do that. That’s the whole point.

A Note on the AI Era

I keep seeing a version of this mistake accelerate in 2025 and 2026.

A lot of smart people are thinking: I can vibe-code now. I can build a product in a weekend. I should start a company.

The tooling has changed dramatically. The fundamentals haven’t.

You can ship a working prototype faster than ever. That’s real. But shipping fast doesn’t solve the core question of whether you’re building something anyone needs. In fact, it can make the problem worse. You burn three weeks shipping the wrong thing at speed and feel like you’ve been productive the whole time. Then that will spill over into a few more months.

Domain knowledge isn’t something you vibe-code your way into.

If you’re non-technical, the advice is even sharper: find a technology partner before you build anything. Don’t assume you can handle the tech side yourself with AI tools. You can get further than you could five years ago, but building any product is still a craft, and the gap will show up at the worst possible moment.

Where This Series Goes

Next up: the difference between a failed startup and a failed product, and why confusing the two nearly broke me. They require completely different post-mortems, and most founders never separate them. I’m going to be talking about specific companies, products and markets so you get the full picture.

After that: what happened when I finally did pick a domain, what consistent growth actually looks like after years of not having it, and the moment I realized my mistakes had compounded into something worth sharing.

The bottom line: If you’re starting from zero with strong technical skills but no clear product, don’t go looking for ideas. Go find customers first. Build a small consulting business in a domain you can access. Let the product emerge from the work. It’s slower to start and faster to succeed.

What’s the mistake you made earliest in your founding journey? I’d genuinely like to know.

I’m Gopi Krishna, founder of Hyperleap AI, an enterprise-grade conversational AI platform but built for SMBs. I write about building companies, second-order effects of AI, and the parts of the founder journey people usually skip over. If this resonated, subscribe. There’s more where this came from.

“At this point, it is best for those of us who depend on writing code for a living to start considering alternative livelihoods.”

He said it with calm acceptance. No panic. Just a quiet surrender to what he sees as inevitable.

And I think he’s wrong. Not about the direction AI is heading — he’s absolutely right about that. But about what it means for the people who build software.

The Pattern We Keep Forgetting

I’ve been in this industry long enough to have lived through multiple “coding is dead” cycles.

In the early 2000s, it was outsourcing. American developers were told their jobs were shipping to Bangalore, and they should start learning “business skills” instead. What actually happened? The global demand for software exploded. There was more work than ever.

In 2012, it was no-code platforms. Drag-and-drop tools were going to eliminate the need for developers. WordPress, Wix, Squarespace, and hundreds of “app builders” — anyone could build anything now. What happened? The companies behind those tools hired more engineers, not fewer. And the complexity of what businesses needed from software only grew.

The pattern is remarkably consistent: every time the barrier to producing code drops, the demand for people who understand what to build, why to build it, and how to make it work at scale goes up.

What Sridhar Gets Right

Let me be fair to his argument, because the underlying observation is correct.

Anthropic did build a C compiler with Claude. That is an extraordinary engineering achievement. The raw capability of AI to produce working code — sometimes complex, sometimes elegant — is no longer in question. I use it every day at Hyperleap AI. My team uses it. It’s real.

And yes, if your entire job is translating a well-defined specification into syntactically correct code — what I’d call “spec-to-syntax” work — then you should be concerned. Not because AI will replace you tomorrow, but because the value of that specific skill is being rapidly commoditized.

But here’s the uncomfortable truth: that job was already on borrowed time.

The “spec-to-syntax” developer was always the most vulnerable role in software. Before AI, they were vulnerable to better frameworks, to low-code tools, to offshore teams. AI just accelerated an existing trend.

The Confusion Between Writing Code and Engineering Software

This is where I think the conversation goes sideways.

There’s a fundamental difference between writing code and engineering software. They look similar from the outside. They happen in the same editor, use the same languages, produce the same file types. But they’re entirely different activities.

Writing code is the act of translating a known solution into a programming language. It’s implementation. It’s the mechanical part.

Engineering software is the messy, human, deeply contextual work of figuring out what problem you’re actually solving, what trade-offs are acceptable, how the system interacts with other systems and with real humans, what happens when things fail, and how to evolve the solution over time.

AI is getting remarkably good at the first part. It can write functions, build components, even architect small systems. But it’s essentially operating in a world where the problem has been fully defined — where the ambiguity has already been removed by a human.

The second part? That’s where the real engineering lives. And it’s not getting automated anytime soon.

Here’s why:

1. The Problem Definition Problem

The hardest part of building software has never been writing the code. It’s been figuring out what to build.

After 11 years at Microsoft, building systems for Office 365 and Outlook.com that served billions of users, I can tell you — the code was the easy part. The hard part was sitting in rooms with product managers, designers, business stakeholders, and customers, trying to reconcile contradictory requirements, budget constraints, performance targets, and organizational politics into a coherent technical direction.

No AI model does this. Not because it can’t write code, but because the inputs are ambiguous, political, emotional, and constantly shifting.

2. The Systems Thinking Gap

A C compiler is a well-defined, bounded problem with a formal specification. Most real-world software is nothing like this.

Real software lives in an ecosystem. It talks to databases that have quirky legacy schemas. It integrates with third-party APIs that change without warning. It serves users who do things you never anticipated. It runs on infrastructure that has hard limits you discover in production at 2 AM.

Understanding this ecosystem — and making sound technical decisions within it — requires the kind of contextual judgment that AI fundamentally lacks. AI can generate code that works in isolation. Engineers build systems that work in context.

3. The Failure Mode Problem

When AI generates a C compiler and it works, that’s impressive. But what happens when it doesn’t work? Who debugs it? Who understands why it failed? Who decides whether the failure mode is acceptable or catastrophic?

This is the part nobody talks about in the “AI replaces coders” narrative. Production software fails constantly — in subtle, context-dependent, non-obvious ways. Diagnosing and resolving these failures requires the kind of deep understanding that comes from having built the system, from understanding the design decisions, the trade-offs, the reasons behind specific architectural choices.

You can’t outsource debugging to something that doesn’t understand intent.

What Actually Changes (And It’s Significant)

None of this means the software industry stays the same. It doesn’t.

Here’s what I think actually happens over the next 3-5 years:

The productivity explosion is real. Engineers who embrace AI tools will be dramatically more productive. At Hyperleap, we’re already seeing this. Tasks that took days take hours. Prototypes that took weeks take days. This is not hype — it’s our lived experience.

The floor rises. The minimum viable competence for a software engineer goes up. You can no longer coast on being a decent coder with good Stack Overflow skills. The baseline expectation is now: you use AI tools fluently, you move faster, you ship more.

Small teams dominate. This is perhaps the most consequential shift. A team of 5 exceptional engineers with AI tools will outperform a team of 50 average ones. This doesn’t mean fewer engineers in absolute terms — it means the organizational structure of software companies changes dramatically.

New roles emerge. “AI-assisted development” is not a buzzword. It’s an entirely new way of working that requires new skills: prompt engineering, AI output evaluation, system-level thinking about where to use AI and where not to, and the ability to debug AI-generated code that you didn’t write yourself.

The demand curve shifts, but doesn’t disappear. There will be fewer opportunities for pure implementation roles and more opportunities for people who can think at the system level, who understand business context, and who can orchestrate AI tools alongside human judgment.

The Real Risk Isn’t AI. It’s Mindset.

Here’s what actually worries me: not that AI will replace engineers, but that talented engineers will hear advice like “consider alternative livelihoods” and actually leave the field.

That would be a tragedy.

The world needs more people who understand how software systems work, not fewer. We need people who can think critically about AI-generated code, who can architect systems that are reliable and safe, who can bridge the gap between what technology can do and what humans actually need.

If you’re an engineer reading this, here’s my honest assessment:

Don’t panic. Don’t leave. But don’t stay still either.

The engineers who thrive in the next decade will be the ones who stop defining themselves as “people who write code” and start defining themselves as people who solve complex problems using software — with AI as the most powerful tool in their toolkit.

That’s not an alternative livelihood. That’s the same livelihood, upgraded.

The Bhagavad Gita Connection

There’s an irony in Sridhar’s post that I want to highlight. He quote-posts a Bhagavad Gita app.

The Gita’s entire message is about performing your duty (dharma) with skill and detachment from the outcome. Chapter 2, Verse 47: “You have the right to perform your duty, but you are not entitled to the fruits of your actions.”

The Gita doesn’t tell Arjuna to find an alternative livelihood. It tells him to master his craft with full commitment, adapting to the reality of his situation.

For engineers, the dharma hasn’t changed. The tools have. The context has. The expectations have. But the core work — understanding problems deeply, building solutions thoughtfully, creating systems that serve people — that remains deeply human work.

The bottom line: AI doesn’t eliminate the engineer. It eliminates the distance between thinking and building. That’s not a threat to the profession — it’s the most exciting evolution our field has seen in decades. The engineers who recognize this will build things that weren’t possible two years ago. The ones who hear “consider alternative livelihoods” and walk away will miss the greatest period of leverage in the history of software.

Don’t look for alternative livelihoods. Build an alternative understanding of what engineering actually is.

What’s your take? Are we witnessing the end of software engineering, or its most important evolution? I’d love to hear from builders who are living this transition.

I’m Gopi Krishna, founder of Hyperleap AI, where we’re building enterprise generative AI infrastructure. Previously at Microsoft for 11+ years, where I built systems for Office 365 and Outlook.com serving billions of users. I write about the second-order effects of AI on Substack.

In all that time, I’ve never seen a shift like this one.

Claude Code isn’t just another tool. It’s the single biggest productivity unlock a developer can get today. But most developers are using it like a fancy autocomplete. Scratching the surface and calling it revolutionary.

I’ve been deep in it. And I can tell you: the gap between developers who really know how to use Claude Code and everyone else is going to define careers over the next few years.

Here are the 10 tactical things I’d do (and am doing) to stay ahead.

#1. You Can’t Win at Depth. Win at Breadth.

This is the most counterintuitive thing on this list, so I’m putting it first.

Every developer’s instinct is to go deep. Master one thing. Become the expert. That instinct served us well for two decades.

But the game has changed.

With Claude Code, your competitive advantage isn’t knowing every edge case of a single framework. It’s in looking into every function across your organization and figuring out how your mini/micro apps can help people automate their boring work. Help them gain time. Help them gain money. Ideally, both.

The developer who builds a small tool that saves a sales team 5 hours a week is more valuable than the one who shaves 200ms off an API call nobody notices.

Help others achieve their KPIs, and you become indispensable. Not because of your code, but because of your impact.

#2. Stop Evaluating. Start Building.

I see this constantly. Developers spending weeks comparing IDEs, CLIs, models, benchmarks. Cursor vs. Windsurf vs. Claude Code. GPT-4 vs. Claude vs. Gemini. Endless Reddit threads. Endless Twitter debates.

Let me be direct: you are there to maximize the tools for your benefit, not to be a test subject for the AI providers.

Pick Claude Code. Learn it deeply. Ship things with it. The developer who ships 10 projects with one tool will always outperform the developer who evaluates 10 tools and ships nothing.

The best tool is the one you’ve mastered. Full stop.

Every hour spent evaluating is an hour not spent building. The market doesn’t reward your tool selection. It rewards your output.

#3. Context Is Everything. Use /add-dir Aggressively.

One of Claude Code’s most powerful (and most underused) features is the ability to cross-reference code with /add-dir.

Here’s what I do: I always work from one project and edit in multiple projects in a coordinated way. This matters a lot when you’re managing micro-services, shared libraries, or an ecosystem of related tools.

The quality of Claude Code’s output is directly proportional to the context you give it. Most developers give it a single file and wonder why the output is mediocre. Give it the full picture. Your project structure, your related repos, your dependencies. Watch the quality of suggestions go from “okay” to “this thing just read my mind.”

Claude Code is only as good as the context you feed it. /add-dir is how you make it understand your codebase, not just your current file.

#4. Use Subagents. But Don’t Overcomplicate.

Subagents are powerful. They let you trigger specific agents for specific tasks (code review, test generation, documentation, refactoring) and keep things modular.

But here’s where I’ve seen developers go wrong: they build elaborate multi-agent systems with 15 subagents, each with custom prompts, talking to each other in a complex orchestration graph, and then spend more time maintaining the system than doing actual work.

Use subagents wisely. Start with one or two for your most repetitive tasks. Add more as you need them. If your agent setup needs its own documentation, you’ve gone too far.

Subagents should save you time, not become a project of their own. Complexity is the enemy of velocity.

#5. Use Agent Teams. Released Yesterday. Use It Today.

This one’s big. Agent Teams just dropped, and it collapses what used to be a serious engineering effort into a single line.

Before this, if you wanted multi-agent orchestration in Claude Code, you had to build it yourself. I used Gastown from Steve Yegge. It worked, but it was extra infrastructure to maintain, extra complexity to manage.

Now? It’s built in. One line. Multiple agents working together on coordinated tasks.

If you’re still doing everything with a single agent, you’re leaving a lot on the table. Agent Teams lets you parallelize work, have agents specialize, and coordinate in ways that feel like having a small dev team running alongside you.

The barrier just dropped to zero. There’s no excuse not to use this.

Agent Teams turns Claude Code from a solo assistant into a coordinated squad. Adopt this early and you’ll have an edge that’s hard to close.

#6. Use Beads. Seriously.

This is a tool recommendation I don’t make lightly. I’m not one to hype every shiny new thing.

Beads is a separate install that helps you keep track of your work. Split up tasks, manage epics, track how you’re progressing through closing out your backlog. It’s the project management layer that Claude Code was missing.

Once you start using it, you’ll realize how much context and progress you were losing between sessions. Beads gives you structure without overhead.

I’ll say it plainly: once you use it, you cannot go back. Having your entire workstream organized and visible while Claude Code handles execution? That’s how software should be built.

Claude Code gives you speed. Beads gives you direction. You need both.

#7. Use /insights Periodically

Also released yesterday. /insights helps you understand your own usage patterns with Claude Code.

Here’s why this matters: most of us have blind spots in how we use tools. Maybe you’re spending 40% of your time on boilerplate that could be automated. Maybe you’re not using certain features at all. Maybe your prompting patterns are limiting the quality of output you’re getting.

/insights surfaces all of this. Think of it as a coach that watches your workflow and says, “Hey, you’re leaving performance on the table here.”

Make it a weekly habit. Check your patterns. Adjust. Improve. The developers who iterate on their own process, not just their code, are the ones who pull ahead over time.

You can’t improve what you can’t measure. /insights turns your Claude Code usage into a feedback loop.

#8. Move Your Marketing Sites to Code. Kill the CMS.

This one is a broader philosophy, but it’s directly enabled by Claude Code.

CMS platforms (WordPress, Webflow, whatever) existed because code was complex to maintain. Non-technical people needed a way to manage content without touching HTML or deploying servers.

That constraint is gone now.

With Claude Code, everything software is simple. Content belongs in code. You can plug in emails, workflows, and automations in a single command. You can version-control your content. You can deploy in seconds.

Here’s my opinionated stack, and I’d recommend having one of your own:

NextJS + Supabase + Vercel + Resend

This gives you the frontend, the database, the hosting, and the email layer. All in one cohesive, code-first setup. No CMS admin panels. No plugin conflicts. No security patches for WordPress.

The reason I’m opinionated about this: speed. When you have a default stack, you don’t waste time making architectural decisions for every new project. Claude Code + a known stack = shipping in hours, not days.

CMS was a workaround for a problem that no longer exists. Code-first content is faster, more flexible, and way more powerful. Especially with Claude Code in the loop.

#9. Don’t Work With Companies That Won’t Sponsor Your Claude Code Subscription

This might be the most controversial point on this list. But I mean it.

If a company doesn’t see the value in sponsoring a Claude Code subscription for their developers, that tells you everything you need to know about how they think about productivity and competitive advantage.

Move out. The first chance you get.

Now, the practical reality: while you’re looking for that right opportunity, sponsor the thing yourself. This is not an expense. It’s an investment in yourself. In your career. In your earning potential.

The developers who are 10x more productive because of Claude Code won’t stay at the same salary for long. The market will find them. And when it does, the ROI on that subscription will look laughable in hindsight.

A Claude Code subscription costs less than a nice dinner. The productivity it unlocks is worth more than most professional certifications. Treat it as what it is: career infrastructure.

#10. Have Fun.

I know this sounds like fluff at the end of a tactical list. It’s not.

The developers who are going to thrive in this era are the ones who are genuinely excited about building. Who stay up late not because they have to, but because they want to see what Claude Code can do with their next idea.

We’re in a moment where a single developer can build what used to require a team. Where an idea in the morning can be a working prototype by evening. Where the gap between thinking of something and shipping it has never been smaller.

If that doesn’t excite you, I don’t know what will.

The best code is written by people who enjoy writing it. The best products are built by people who enjoy building them. And the best careers are built by people who never lost the curiosity that got them into this in the first place.

So have fun. Build weird things. Ship fast. Break stuff. Fix it with Claude Code. Ship again.

The developers who have fun will outwork, outlearn, and outlast everyone else. Because they won’t want to stop.

The bottom line: Claude Code is the most significant productivity tool a developer can have today. But the tool isn’t the advantage. How you use it is. Win at breadth, not depth. Give it context. Use Agent Teams and subagents. Track your work with Beads. Invest in yourself. And above all, keep building with joy.

The gap between developers who master these tactics and those who don’t is going to be enormous. Choose which side you want to be on.

What’s your top Claude Code tactic? I’d love to hear what’s working for you. Connect with me and let’s compare notes.

I’m Gopi Krishna, founder of Hyperleap AI, where we’re building infrastructure for businesses to deploy AI chatbots, tools, and assistants. I write about AI, developer productivity, and building in the age of intelligent tools. Previously at Microsoft, where I built systems for Office 365 and Outlook.com serving billions of users.

You can connect with me on Twitter and LinkedIn.

Take a moment with that question please. And reallllly think about it.

Now apply it to how your organization is building AI solutions.

Subscribe now

I’ve spent the last 2 years building our product, an enterprise-ready Generative AI platform, and before that, 11+ years at Microsoft working on systems that serve billions of users. And I’ve noticed something troubling across the Enterprise AI landscape today:

Companies are building AI solutions with the mindset that if AI doesn’t work, humans can always jump in—the ever-present Plan B.

And in my opinion, that’s exactly why most AI implementations are failing to deliver transformational value.

The Comfortable Lie We Tell Ourselves

Here’s how the conversation typically goes in enterprise boardrooms:

Executive: “How confident are we that this AI will work?”

AI Team: “Well, we’ve built in human oversight. If the AI makes a mistake or isn’t confident, we escalate to a human agent. Best of both worlds—AI efficiency with human judgment.”

Executive: nods approvingly “Smart. Let’s proceed.”

Everyone leaves the meeting feeling good. The AI team gets their budget. The executive feels responsible. The operations team feels secure that their jobs aren’t disappearing overnight.

But here’s what nobody says out loud: You just greenlit a solution designed to underperform.

The Psychology of Plan B

When you build AI knowing humans will catch the failures, something insidious happens at every level of development:

1. Threshold Compromise

Your accuracy target subtly shifts from “production-ready” to “good enough for supervised use.”

Instead of demanding 95%+ accuracy on critical tasks, you settle for 75% because “humans will handle the rest.” You’ve just mathematically guaranteed that 25% of your workload still requires human intervention—forever.

2. Edge Case Avoidance

Those tricky scenarios that require deep thinking and robust handling? They get tagged with “escalate to human” and you move on.

The hard work of actually solving the problem—improving training data, refining prompts, building better retrieval systems—gets perpetually postponed. Why solve it when you can route it?

3. Data Quality Deterioration

When humans are standing by to fix mistakes, the pressure to maintain pristine training data and knowledge bases diminishes.

“We’ll catch it in review” becomes the refrain. Except you won’t catch all of it. And the AI learns from the garbage, compounding the problem.

4. Testing Theater

Your testing becomes perfunctory rather than rigorous. You’re not testing for autonomous operation—you’re testing whether the escalation logic works.

The bar drops from “can this AI handle production?” to “can this AI recognize when it needs help?”

It’s like training a pilot who only knows how to engage autopilot and call for help, but never actually learned to fly the plane.

The Real Cost: A Vicious Cycle

This Plan B mindset creates a self-fulfilling prophecy of AI underperformance:

Stage 1: Mediocre AI Deployment → System goes live with 70-80% accuracy → Humans handle 20-30% of cases → “See? Human in the loop works!”

Stage 2: Reality Bites → Volume scales up → Human intervention becomes bottleneck → Costs don’t decline as expected → Response times suffer during peak loads

Stage 3: Degradation → Humans get fatigued from constant context switching → Quality of human interventions drops → AI never learns from edge cases (they’re all routed away) → System improvement stagnates

Stage 4: Disillusionment → ROI analysis shows marginal gains → “AI doesn’t work for our use case” becomes the narrative → Project gets quietly shelved or relegated to minor tasks → Organization becomes AI-skeptical

I’ve watched this play out dozens of times. The tragic part? The problem was never the AI’s capability. It was the organization’s commitment level.

The Microsoft Lesson: Systems That Can’t Afford Plan B

During my time at Microsoft working on Office 365 and Outlook.com, I learned something fundamental about building systems at scale:

When you’re serving billions of users, Plan B isn’t an option.

You can’t have human oversight for spam filtering when you’re processing millions of emails per second. You can’t have manual review for calendar conflict resolution when you’re managing schedules for hundreds of millions of people.

The system has to work. Period.

And guess what? When “it has to work” is your only option, it does work. You invest in:

• Robust data pipelines that catch anomalies before they poison your models

• Comprehensive testing frameworks that simulate millions of edge cases

• Gradual rollout strategies with automatic rollback mechanisms

• Continuous monitoring with real-time performance metrics

• Rapid iteration cycles to fix issues within hours, not weeks

You build like your business depends on it—because it does.

The All-In Approach: Building AI Without a Safety Net

At Hyperleap AI, we’ve taken a contrarian stance: Build AI that doesn’t need a Plan B.

Not because humans aren’t valuable—they absolutely are. But because when you architect AI solutions with the expectation that they WILL handle production workloads autonomously, everything about how you build changes.

The Technical Shift

Traditional Approach:

User Query → Basic AI Processing → Confidence Check

→ If < 80% confident → Route to Human

→ If ≥ 80% confident → Return Response

All-In Approach:

User Query → Comprehensive RAG Pipeline → Multi-Stage Validation

→ Context Enhancement → Response Generation

→ Quality Verification → Delivery

→ Continuous Learning Loop

See the difference? No escape hatch. No “route to human” cop-out. The AI either handles it correctly, or you fix the system so it can.

The Architectural Shift

When humans aren’t there to catch failures, your architecture evolves:

1. Hierarchical RAG, Not Basic Retrieval You can’t just throw documents into a vector database and hope for the best. You need:

• Document preprocessing and chunking strategies

• Multi-level retrieval (semantic + keyword + metadata)

• Re-ranking and relevance scoring

• Context window optimization

• Source attribution and verification

2. Prompt Engineering as a Discipline Your prompts can’t be afterthoughts. They become:

• Versioned and tested like code

• Optimized through hundreds of iterations

• A/B tested against production workloads

• Monitored for drift and degradation

3. Testing That Matters You build:

• Comprehensive test suites covering edge cases

• Regression testing for every system update

• Load testing for realistic usage patterns

• Adversarial testing to find failure modes

4. Observability and Monitoring You implement:

• Real-time accuracy tracking

• Latency monitoring at every stage

• Cost-per-query optimization

• Automated alerting on degradation

None of this is optional when Plan B doesn’t exist.

Let me give you a concrete example.

The Plan B Version

A company builds a customer support chatbot:

• Uses basic LLM with their docs

• Routes “complex” queries to humans

• Defines “complex” as: anything the AI isn’t 90% confident about

Result after 6 months:

• 60% of queries still go to humans

• Customer satisfaction drops (inconsistent experience)

• Support costs only reduced by 25%

• Team declares “AI isn’t ready for support”

The All-In Version

Same company, different approach:

• Invests in comprehensive knowledge base architecture

• Builds multi-turn conversation handling

• Implements context retention across sessions

• Creates feedback loops for continuous improvement

• Treats AI as the primary support channel, not an experiment

Result after 6 months:

• 92% of queries fully resolved by AI

• Customer satisfaction improves (faster, 24/7, consistent)

• Support costs reduced by 70%

• Human agents focus on truly complex cases and system improvement

The difference? Commitment level.

The first team built AI expecting it to fail. The second team built AI expecting it to succeed—and made sure it did.

“But What About Responsible AI?”

I can hear the objections already:

“Isn’t human oversight necessary for responsible AI deployment?”

“What about hallucinations and errors?”

“Aren’t you advocating for reckless automation?”

Let me be crystal clear: Responsible AI deployment and the All-In approach are not mutually exclusive.

In fact, they’re complementary.

Responsible AI Without Plan B Looks Like:

1. Extensive Pre-Deployment Testing

• Thousands of test cases before going live

• Red team exercises to find failure modes

• Bias and fairness audits

• Security and privacy reviews

2. Gradual Rollout with Guardrails

• Start with low-risk use cases

• Expand gradually based on performance data

• Implement hard constraints (e.g., can’t process transactions above $X without confirmation)

• Build in verification steps where consequences are high

3. Continuous Monitoring and Improvement

• Real-time performance tracking

• Automated anomaly detection

• Rapid response to issues

• Regular audits and updates

4. Human Oversight of the System, Not Each Transaction This is the key distinction. Humans should oversee:

• System performance metrics

• Model drift and degradation

• Edge case patterns emerging

• Strategic improvements

NOT:

• Every individual AI decision

• Routine queries the system is proven to handle

• Cases that fall within well-tested parameters

Think about it this way: You don’t have a human review every calculation your accounting software makes. But you do have accountants who oversee the system, audit outputs, and ensure it’s working correctly.

That’s the model for responsible AI at scale.

The ROI Reality Check

Let’s talk numbers, because that’s ultimately what matters to businesses.

Scenario: 10,000 customer queries per month

Plan B Approach:

• AI handles 70% autonomously

• 30% escalated to humans

• Monthly cost: $15,000 (AI infrastructure) + $30,000 (human agents for 3,000 queries)

• Total: $45,000/month

• Savings vs. all-human: 25%

All-In Approach:

• AI handles 95% autonomously

• 5% truly complex cases to specialized humans

• Monthly cost: $20,000 (AI infrastructure + higher quality) + $10,000 (human experts for 500 complex queries)

• Total: $30,000/month

• Savings vs. all-human: 50%

But wait, there’s more:

Intangible Benefits of All-In:

• 24/7 availability (no night shift premiums)

• Instant response times (no queue waiting)

• Consistent quality (no bad days or training gaps)

• Infinite scalability (handle 100,000 queries at same cost)

• Continuous improvement (gets better over time)

The Plan B approach can never achieve this because it’s architected for mediocrity.

The Mindset Shift Required

Moving from Plan B to All-In requires a fundamental mindset shift at every level:

For Executives:

Old Thinking: “Let’s pilot AI on low-risk tasks and see if it works.”

New Thinking: “Let’s identify where AI can deliver transformational value and commit to making it work.”

Treat AI deployment like any other mission-critical system implementation. You wouldn’t deploy a half-baked ERP system with “humans can fix the data issues” as your strategy.

For AI Teams:

Old Thinking: “Let’s build something quickly and iterate based on human intervention feedback.”

New Thinking: “Let’s build something that can run autonomously in production from day one.”

This means longer development cycles upfront, but dramatically faster value realization and lower long-term costs.

For Operations Teams:

Old Thinking: “AI will take our jobs, so let’s make sure it depends on us.”

New Thinking: “AI will handle routine work, freeing us to focus on complex problems and strategic improvements.”

The humans who win in an AI-driven world aren’t the ones catching AI failures—they’re the ones making AI systems better.

Subscribe now

The Competitive Advantage

Here’s what most people miss: The companies that figure this out first create an insurmountable competitive advantage.

When your competitors are running AI systems that require human intervention on 30% of cases, and you’re running systems that handle 95% autonomously, you can:

• Operate at 1/3 the cost structure

• Scale 10x faster (no human hiring bottleneck)

• Deliver better customer experience (faster, more consistent)

• Innovate faster (AI systems can be updated rapidly; human processes can’t)

This isn’t incremental improvement. This is step-function change.

And it’s only available to organizations willing to commit fully.

The Hard Questions You Need to Ask

If you’re building or deploying AI in your organization, here are the questions you need to honestly answer:

1. What’s our AI accuracy target, and did we choose it based on autonomous operation requirements or human supervision availability?

2. How many of our AI’s “limitations” are actually limitations of our commitment to solving hard problems?

3. Are we using “human in the loop” as a responsible AI practice or as an excuse for mediocre AI?

4. What percentage of our AI development time is spent making the AI better vs. building escalation and routing logic?

5. If humans weren’t available as a safety net, would we deploy our current AI system? If not, why are we deploying it now?

6. What would our AI architecture look like if we designed it to be fully autonomous from day one?

7. Are we building AI as a competitive advantage or as a buzzword-compliant checkbox?

The answers to these questions will tell you whether you’re on the path to transformational AI or incremental disappointment.

The Path Forward

If you’re currently trapped in the Plan B paradigm, here’s how to break free:

Phase 1: Acknowledge the Problem (Week 1)

• Audit your current AI systems

• Calculate actual human intervention rates

• Measure true ROI vs. projected ROI

• Identify where Plan B mentality is holding you back

Phase 2: Pick Your Battle (Week 2-3)

• Choose ONE use case for the All-In approach

• Select something meaningful but not business-critical to start

• Define clear success metrics (95%+ autonomous handling)

• Get executive commitment for proper investment

Phase 3: Build for Autonomy (Month 1-3)

• Design architecture without human fallback

• Invest in comprehensive testing

• Build robust monitoring and observability

• Plan for gradual rollout with hard guardrails

Phase 4: Deploy and Iterate (Month 3-6)

• Start with small user subset

• Monitor relentlessly

• Fix issues rapidly

• Expand gradually based on performance

Phase 5: Scale and Replicate (Month 6+)

• Achieve target performance metrics

• Document lessons learned

• Apply approach to additional use cases

• Build institutional knowledge

The journey isn’t easy. But neither is building any mission-critical system.

The question is: Are you building AI to check a box, or to transform your business?

The Bottom Line

Here’s the uncomfortable truth that needs to be said:

If your AI solution requires constant human intervention to function, you don’t have an AI solution—you have an expensive routing system.

The companies that will win the AI revolution aren’t the ones with the best safety nets.

They’re the ones who committed to making AI work—period.

They invested in proper architectures. They refined their systems through thousands of iterations. They built comprehensive testing frameworks. They treated AI deployment with the same rigor as any mission-critical system.

Because when Plan B isn’t an option, Plan A gets really, really good.

At our company, we’ve made this commitment. We build enterprise-ready AI that doesn’t need human supervision to function—not because we don’t value humans, but because we believe AI should deliver transformational value, not incremental improvement.

The question for you is simple:

Are you building AI solutions that need constant human supervision?

Or are you building AI that humans can trust to run independently?

The difference isn’t just technical. It’s philosophical.

And it’s the difference between AI as a cost center and AI as a competitive advantage.

What’s your experience? Are you seeing the Plan B trap in your organization? Have you successfully built AI systems that run autonomously? I’d love to hear your perspective in the comments.

Subscribe now

I met someone at a conference recently who introduced herself as the “Chief AI Officer” at a large GCC. When I asked what that actually meant, she paused. “I’m basically the person who explains to the board why we’re not as AI-forward as they think we should be,” she said. Then laughed. “I spend most of my time in meetings about meetings about AI strategy.”

She’s been using AI to write those strategy documents. The board uses AI to generate questions about them. The consultants they hired use AI to create frameworks for implementing AI. Everyone’s using AI to talk about using AI, in an endless recursive loop that would be funny if it wasn’t so expensive.

This is the reality of generative AI in 2025: a technology powerful enough to transform work, deployed primarily to maintain the illusion that work is happening.

The Great Pretending, Automated

The numbers tell one story: 95% of companies are using generative AI. Productivity is supposed to increase by 25%. C-suite executives are euphoric. AI budgets have doubled. We’re on the cusp of transformation.

The reality tells another: 77% of employees say AI has actually decreased their productivity. Half don’t know how they’ll ever achieve the gains their bosses expect. One in three are ready to quit from AI-induced burnout. The people actually using these tools are drowning in the gap between promise and reality.

But here’s what nobody’s talking about: everyone’s using it anyway. Not for the revolutionary transformation promised in board decks. They’re using it for the same thing that’s kept corporate culture running for decades—maintaining appearances.

A developer friend showed me his screen recently. Three windows open: his actual code, AI generating documentation that nobody will read, and another AI window writing his status update about the documentation. “I’m using AI to create the performance of productivity,” he said. “The actual coding takes two hours. The theatrical demonstration that I’m coding takes six.”

The technology that was supposed to eliminate bullshit jobs has instead become the ultimate bullshit job enabler. We’ve automated the pretense.

The Secret Everyone Knows

A recent survey found that 71% of full-time employees are burned out and 65% report struggling with employer demands on their productivity. Meanwhile, executives believe AI will boost productivity. The disconnect is staggering, but it makes perfect sense when you understand what’s actually happening.

Walk into any office and you’ll find the same pattern. Junior employees using AI to write emails that sound more “professional.” Managers using it to generate performance reviews that sound more “strategic.” Executives using it to create presentations that sound more “visionary.”

Everyone’s in on the secret: we’re using AI to sound like we think we’re supposed to sound. To perform the role of the employee we think we’re supposed to be. To generate the artifacts of work without the substance.

A friend in consulting admitted their entire team uses AI to generate client deliverables. “The client knows we’re using AI. We know they know. They know we know they know. But we all pretend it’s our ‘proprietary methodology’ because that’s what justifies the fee.”

The consultants use AI to create frameworks. The clients use AI to evaluate them. Soon, it’ll just be AIs talking to AIs, with humans attending the meetings to maintain the fiction that decisions are being made.

The Burnout Nobody Expected

The promise was that AI would handle the mundane, freeing us for creative work. Instead, almost 80% of workers who use generative AI in their jobs said it has added to their workload. They spend more time reviewing AI output than they would have spent doing the work. More time learning tools that don’t quite work. More time managing the expectation that they should be exponentially more productive.

“I spend half my day fact-checking ChatGPT,” a marketing director told me. “Then I spend the other half pretending the efficiencies are transformational. It’s exhausting.”

The cruel irony: Workers with the least experience see the biggest gains from AI—35% productivity improvements for newcomers versus essentially flat for experienced workers. The people who actually know how to do the work see no benefit. They’re spending their time teaching the machine to approximate competence.

Meanwhile, the executives who’ve never done the actual work are the most convinced of AI’s transformative power. They see demos, not daily reality. They see potential, not practice. They’re making decisions about AI implementation based on AI-generated reports about AI capabilities.

The Agents That Never Arrive

Everyone’s talking about AI agents—autonomous systems that will actually do work rather than just generate text about work. 2025 was supposed to be the year of the AI agent. The year we go from experimentation to implementation.

But talk to anyone actually trying to deploy these systems and you hear the same story. The agents work perfectly in demos. They fail spectacularly in reality. They can’t handle edge cases. They hallucinate. They need so much human oversight that you might as well do the work yourself.

“We spent six months building an AI agent to handle customer service,” a tech executive told me. “It works great 80% of the time. The other 20% it tells customers to go fuck themselves. Politely, but still.”

The dirty secret of AI agents: they’re just more sophisticated performance art. More elaborate ways to pretend automation is handling things while humans scramble behind the scenes to clean up the mess.

Subscribe now

The Parallel Reality

What’s emerging isn’t the AI transformation executives imagine. It’s something more subversive.

Employees are using AI, but not how their companies think. They’re using AI to do their corporate job in two hours, then spending the rest of the day on what actually matters to them. Building side projects. Learning real skills. Creating actual value.

A product manager at a major tech company told me she uses AI to generate all her required documentation. “I can produce a week’s worth of ‘deliverables’ in a morning,” she said. “The rest of the time, I’m building my own product. My boss thinks I’m incredibly productive. I am—just not for them.”

This is the real transformation: AI hasn’t replaced human workers. It’s revealed how much of work was always theater. Now we can automate the performance and focus on what matters.

The question isn’t whether AI will take your job. It’s whether your job was ever real to begin with.

The Skills That Actually Matter

In this new reality, the most valuable skill isn’t prompt engineering. It’s understanding the game being played. Knowing when to deploy AI for maximum theatrical effect. When to generate the appearance of work. When to actually do work.

The people thriving aren’t the AI evangelists or the skeptics. They’re the pragmatists who understand that generative AI is a tool for navigating corporate theater, not transforming it.

They use AI to write the emails that need to sound professional. They use it to generate the reports nobody reads. They use it to create the presentations that justify decisions already made. And then they use the time saved to do something real.

“I’m not worried about AI replacing me,” a designer told me. “I’m using it to replace the parts of my job that should never have existed.”

The Moment of Recognition

“We’ve done a disservice by anthropomorphizing AI—talking about agents as employees or coworkers,” says a BCG managing director. He’s right, but not for the reasons he thinks.

The disservice isn’t that we’ve made AI seem too human. It’s that we’ve revealed how robotic human corporate work has become. How much of our professional lives consist of generating predictable text outputs based on pattern recognition.

When ChatGPT or Claude can write your performance review, what does that say about performance reviews? When AI can generate your strategy document, what does that say about strategy? When a large language model can do your job, what does that say about your job?

The existential crisis isn’t that AI might replace us. It’s that it’s showing us how replaceable we always were—not because we lack value, but because the system never valued what makes us human in the first place.

The New Corporate Reality

The companies that will thrive aren’t the ones that successfully “implement AI.” They’re the ones that recognize what AI reveals about work itself. That acknowledge the performance. That stop pretending the emails matter more than the ideas. That value human creativity over algorithmic productivity.

But that would require admitting that much of corporate work is theater. And nobody’s ready for that conversation. So we’ll keep using AI to optimize the pretense. To make the meaningless more efficient. To automate the artifice.

A startup founder told me they explicitly hire people who are “good at the real work, terrible at the corporate performance.” Then they use AI to handle the performance part. “ChatGPT writes our investor updates. Our team builds the actual product. It’s the only sustainable division of labor.”

Permission to Stop Pretending

The liberating truth about generative AI is that it proves what we’ve always suspected: most of what we do at work doesn’t matter. The reports, the decks, the emails, the strategies—they’re props in an elaborate play about productivity.

AI can generate all of it. Faster, cheaper, more consistently. And if a pattern-matching machine can do it, maybe it was never worth doing in the first place.

So here’s your permission, if you need it: use AI for the performance. Automate the artifice. Generate the deliverables. But save your humanity for what matters. For the work that requires genuine thought, creativity, connection—the things that can’t be prompted into existence.

The death of the corporate AI role isn’t about AI replacing humans. It’s about AI revealing that the role was always an algorithm—a predictable pattern of inputs and outputs that we convinced ourselves was meaningful.

Now that a machine can perform it, we’re free to be human again. The question is whether we remember how.

The Future That’s Already Here

The transformation is already happening, just not where the executives are looking. In the gaps between meetings. In the hours reclaimed from meaningless tasks. In the side projects and secret innovations of employees who’ve figured out the game.

They’re using AI to maintain their corporate presence while building their actual future. They’re automating the performance of work while doing real work elsewhere. They’re treating their corporate role as infrastructure for their actual ambitions.

The corporate AI role is dead. Not because AI killed it, but because AI revealed it was never alive. It was always an algorithm, waiting to be automated. Now that it can be, we can finally focus on what can’t.

The employees who understand this aren’t worried about the future. They’re already building it, while their AI assistant writes another strategy document about digital transformation that nobody will read.

The revolution isn’t coming. It’s here. It’s just not evenly distributed. And it’s happening in the spaces between the prompts, in the humanity that refuses to be optimized, in the work that matters too much to delegate to a machine.

The corporate AI role is dead. Long live whatever you build in the time it frees.

The irony isn’t lost. Subscribe for more uncomfortable truths about the future of work.

Subscribe now

I just finished watching Andrej Karpathy’s latest conversation, and his one statement hit me like a freight train: we’re not building digital humans—we’re building ghosts.

This might sound like semantic wordplay, but the more you think on it, it’s actually the key to understanding why AI timelines keep surprising everyone (in both directions), why coding agents work but your PowerPoint bot doesn’t, and why the path to AGI looks nothing like the sci-fi script we’ve been reading from.

Subscribe now

The Ghost in the Machine

Here’s Karpathy’s crucial insight: animals evolved through a very different optimization process than LLMs. When a zebra is born, it’s running within minutes—not because it learned to run, but because evolution encoded that capability directly into its neural architecture through millions of years of natural selection. That’s hardware, not software.

LLMs, by contrast, are trained by imitating the digital exhaust of human civilization—internet documents, code repositories, conversations. They’re not animals. They’re “ethereal spirit entities,” as Karpathy puts it, that exist purely in the realm of bits and patterns. They’re ghosts of human knowledge, not biological intelligences.

This distinction matters enormously. It means we can’t simply map animal learning onto AI development. It means the cognitive architecture of these systems is fundamentally different from ours. And it means we need to stop making lazy analogies to “kindergarteners” or “high schoolers” when describing model capabilities.

The March of Nines

The second revelation: every improvement in AI is a constant amount of work, regardless of where you are on the capability curve.

Karpathy calls this “the march of nines.” Getting from 90% to 99% accuracy takes just as much effort as getting from 99% to 99.9%. This is why self-driving took a decade despite perfect demos in 2014. This is why coding agents are impressive but not yet replacing senior engineers. This is why ChatGPT can write a sonnet but can’t reliably book you a vacation.

Each nine represents thousands of edge cases, corner cases, integration challenges, and silent failures that only emerge when the system meets reality. The demo-to-product gap isn’t a gap—it’s a canyon that requires constant, grinding work to cross.

Why Code? Why Now?

So why do coding agents work (relatively) well while agents for slides, customer service, or strategic planning still feel half-baked?

Because code has always been text.

The entire edifice of software engineering—IDEs, version control, diff tools, test suites, CI/CD pipelines—was already built around manipulating text. LLMs are exquisite text processors. The fit is natural.

But more importantly, code is structured, verifiable, and operates in a closed world. You can run tests. You can see if it compiles. The feedback loop is immediate and binary. Compare this to making a slide deck, where “success” is subjective, culturally dependent, and requires sophisticated aesthetic judgment.

This is why API revenue is dominated by coding applications. Not because LLMs are narrow tools, but because coding was accidentally pre-adapted for the specific cognitive architecture of transformer-based language models.

The Slop Problem (Or: Why Your AI Tutor Isn’t Here Yet)

Karpathy wants to build an AI tutor that matches his experience learning Korean from a skilled human teacher. Here’s what that teacher did:

1. Instantly diagnosed exactly what he knew and didn’t know

2. Served him material at the precise edge of his capability

3. Never gave him something too hard (frustrating) or too easy (boring)

4. Made him feel like he was the only constraint on his learning

Current LLMs can’t do this. Not even close. They’re “collapsed”—they sample from a narrow manifold of responses. Ask ChatGPT for a joke and you’ll get the same three jokes. Ask for reflection on a book chapter and you’ll get variations on the same shallow take.

This collapse isn’t just annoying—it’s fundamental. LLMs are too good at memorization and too eager to regurgitate. They produce what Karpathy calls “slop”: plausible-sounding content that lacks genuine insight or novelty. They can’t maintain the entropy needed for true exploration of ideas.

The technical challenge isn’t just making them smarter. It’s making them more diverse without letting them drift into incoherence. It’s teaching them to know what they don’t know. It’s giving them something analogous to intellectual humility.

Subscribe now

What This Means for Timelines

If you’re building an AI company or investing in one, here’s what this framework implies:

The tasks that will be automated first:

• Involve pure information processing (no physical component)

• Have clear success criteria (can be verified programmatically)

• Live in closed, well-defined domains

• Benefit from the existing text-based tooling infrastructure

• Can tolerate 80% automation with 20% human supervision

The tasks that will take another decade:

• Require genuine creativity or taste

• Span multiple domains with messy handoffs

• Need “common sense” in truly novel situations

• Have high costs of failure (safety-critical, security-critical)

• Demand the kind of contextual judgment that comes from deep experience

The corporate knowledge worker doing PowerPoint and email isn’t getting replaced next year. The consultant synthesizing disparate information into strategic recommendations isn’t either. But the junior developer writing CRUD applications? The call center employee following scripts? The paralegal doing document review? Those roles are in the crosshairs right now.

The Intelligence We’re Missing

What’s still missing from these systems? Karpathy has a list:

• Continual learning: The ability to update themselves based on experience without full retraining

• Genuine reflection: Going beyond surface-level pattern matching to meta-cognitive reasoning

• Cultural accumulation: Building a shared knowledge base that compounds over generations of models

• Self-play and competition: The evolutionary pressure that drove biological intelligence

• Emotional and motivational systems: The instincts and drives that guide exploration vs. exploitation

We have cortical tissue (the transformer). We have something like a prefrontal cortex (chain-of-thought reasoning). But we’re missing the basal ganglia, the hippocampus, the amygdala—all the subcortical structures that make human intelligence human.

The Real Timeline

So when does this all come together? Karpathy’s answer is refreshingly honest: probably not as fast as VCs need, but faster than pessimists expect.

He’s not betting on a discrete jump to AGI. He’s betting on the same hyper-exponential curve humanity has been riding since the Industrial Revolution. AI isn’t a discontinuity—it’s an acceleration. Just like computers, just like the internet, just like mobile phones.

The pattern is always the same: miraculous demos, then years of grinding through the march of nines, then gradual diffusion throughout the economy, then complete transformation of how we work and live. We’re in the middle of that cycle right now, mistaking demos for products and hype for progress.

But make no mistake: the transformation is real. We’re just on a longer fuse than most people think.

Building in the Gap

If you’re building AI products today, the opportunity isn’t in replacing humans wholesale. It’s in creating the interfaces and workflows for human-AI collaboration.

It’s building the “operation centers” that sit behind the autonomous systems—the human oversight layer that handles the 1% of cases the AI can’t. It’s designing the autonomy slider that lets companies dial up AI assistance as the technology matures. It’s creating the feedback loops that turn deployment experience back into training data.

The winners in this space won’t be the ones with the best AI. They’ll be the ones with the best understanding of where the march of nines currently sits, and what humans and machines each do best at this particular moment in time.

The Education Bet

Karpathy’s building Eureka Labs to create what he calls “Starfleet Academy”—an elite institution for technical learning in the age of AI. His thesis: even in a post-AGI world, humans will want to learn for the same reason they go to the gym today.

Not because we need physical strength (we have machines for that), but because it’s fun. Because it’s how we signal status. Because it’s how we connect with something primal in our nature.

If he’s right, the highest value education won’t be vocational training for jobs that AI will automate anyway. It’ll be the pursuit of human excellence for its own sake—the cognitive equivalent of running a marathon or climbing a mountain.

The market for this might be smaller than mass education. But it might also be the only education that matters.

The Bottom Line

We’re not in the year of agents. We’re in the decade of agents. The march of nines continues. The ghosts are getting smarter, but they’re still ghosts.

Build accordingly.

Here’s the full podcast:

I debated a lot about whether or not to write on this one. Because while most regulators are going to force businesses to be transparent, most businesses may not want to be super transparent either.

It’s a paradox. One that is emerging around AI transparency that most businesses haven’t fully grasped yet.

Subscribe now

Everyone agrees AI should be transparent—users should know when they’re talking to AI, what sources it’s using, how it reaches conclusions. Transparency builds trust.

But here’s the uncomfortable truth: transparency also creates liability.

The more you reveal about how your AI works and what it’s based on, the more accountable you become for its outputs. And that creates a strategic dilemma businesses aren’t prepared for.

The Transparency Push

Let’s start with why transparency is becoming table stakes:

Regulatory pressure: The EU AI Act requires explainability. Other jurisdictions are following.

User demand: People want to know “why did the AI say that?” especially for high-stakes decisions.

Trust building: “Here’s why we gave this recommendation” feels more trustworthy than “trust us, the AI knows.”

Competitive differentiation: “Our AI shows its sources” vs. “our competitors’ AI is a black box.”

These are all valid reasons. Transparency is good. I’m not arguing against it.

But there’s a second-order effect that creates serious challenges: when you show your work, you become accountable for it.

The Black Box Protection

Traditional software had an advantage: it was opaque.

If a recommendation engine suggested a product and the user didn’t like it, they moved on. The company wasn’t liable because the logic was proprietary and unexplained.

If an automated system made a mistake, you could claim “algorithmic error” without revealing the underlying logic. Users couldn’t scrutinize the decision-making process.

This opacity provided legal protection. Not maliciously—just practically. You can’t be held accountable for reasoning you never revealed.

The Transparent Liability

But transparent AI changes everything.

Scenario 1: Healthcare AI

Black box: “The AI suggests this treatment approach.”

Liability: Limited. You didn’t explain why, so users can’t challenge the logic.

Transparent: “Based on these 5 studies and your medical history, the AI suggests this treatment.”

Liability: Significant. Now you’re accountable for the accuracy of those studies, the relevance of that medical history, and the soundness of the logical connection.

If one of those cited studies turns out to be flawed or retracted, you have a problem. Your AI explicitly relied on it, and you showed your work.

Scenario 2: Financial AI

Black box: “The AI declined your loan application.”

Liability: Minimal legal exposure beyond basic discrimination laws.

Transparent: “Your application was declined because of: credit score X, income Y, debt ratio Z.”

Liability: Every factor is now challengeable. Is the credit score data accurate? Is the income calculation fair? Is the debt ratio threshold reasonable?

You’ve given plaintiffs a roadmap for challenging your decision.

Scenario 3: Hiring AI

Black box: “The AI didn’t select you for an interview.”

Liability: Hard to challenge without knowing the criteria.

Transparent: “You weren’t selected because you lack certification X and experience in Y.”

Liability: Now candidates can argue whether those requirements are actually necessary, legally defensible, or consistently applied.

In each case, transparency increases trust—but also exposure.

The Citation Problem

One of the biggest transparency features in modern AI is source citation: “This answer is based on documents A, B, and C.”

Users love this. They can verify information. They can see the reasoning. They trust the answer more.

But for businesses, this creates several problems:

Problem 1: Source Liability

If your AI cites a source that’s wrong, outdated, or problematic, you’re now explicitly associating your brand with that source.

You can’t claim “the AI hallucinated.” You cited a specific document. If that document is wrong, you amplified misinformation.

Problem 2: Reasoning Liability

If your AI says “Based on X, I conclude Y,” you’re now on the hook for whether that logical connection is sound.

A human expert could make the same connection and be protected by professional judgment. But when your AI makes it and shows its reasoning, that reasoning becomes discoverable and challengeable.

Problem 3: Consistency Liability

If your AI cites different sources for similar questions from different users, you open yourself to claims of inconsistency or bias.

“Why did you cite source A for user 1 but source B for user 2 when they asked the same question?”

With black box systems, this never surfaces. With transparent systems, it’s evidence.

The “Explainability” Trap

The push for “explainable AI” sounds obviously good. But it creates a trap:

Simplify the explanation: Risk inaccuracy. You’re explaining complex model behavior in simplified terms that might not fully represent what’s happening.

Explain accurately: Risk incomprehensibility. Real model explanations are technical and don’t build trust with non-technical users.

Split the difference: Risk being accused of obscuring what’s really happening.

There’s no clean answer. Every choice has liability implications.

The Data Source Exposure

When you show sources, you reveal your knowledge base—which creates competitive and legal exposure:

Competitive exposure: Competitors can see exactly what knowledge you’re using, potentially revealing strategic information or trade secrets.

Legal exposure: In litigation, cited sources become discoverable. Plaintiffs can subpoena the full documents your AI referenced.

Quality exposure: Poor quality sources that would normally be hidden in a black box are now visible, damaging credibility.

This means transparency forces you to have higher quality knowledge management—which is good—but also means you can’t hide weak spots.

The Update Problem

Here’s a specific liability scenario that transparent AI creates:

Your AI cites a policy document from your website. A customer makes a decision based on that information.

Later, you update the policy. Your AI now cites the new version.

But the customer says “when I made my decision, your AI cited version 1, which said X. Now you’re holding me to version 2, which says Y.”

With black box systems, there’s no record of what version was cited when.

With transparent systems, you might have timestamped citations proving exactly what you told the customer and when.

This is good for customers (they have receipts) but creates compliance complexity for businesses.

The Reasonable Person Standard

There’s a legal concept called the “reasonable person standard”—what would a reasonable person believe or do in this situation?

Transparent AI changes this:

If your AI explicitly cites authoritative sources and explains its reasoning, a reasonable person would trust it more than a black box recommendation.

But that increased trust means increased liability when it’s wrong.

You’ve essentially provided a more convincing wrong answer, which arguably causes more harm than an unconvincing wrong answer.

The legal question becomes: does transparency increase your duty of care?

I think courts will eventually say yes.

The Strategic Responses

Given these challenges, businesses are developing several strategies:

Strategy 1: Selective Transparency

Be transparent about some things (general methodology) but not others (specific weights, exact algorithms).

This threads the needle: builds trust without full exposure.

Risk: Might be seen as hiding something.

Strategy 2: Confidence-Gated Transparency

Show sources only when the AI is highly confident. For uncertain answers, be less specific.

This limits exposure to cases where you’re most defensible.

Risk: Creates inconsistent user experience.

Strategy 3: Disclaimer Heavy

Be transparent but add extensive disclaimers: “Sources cited for reference only, not verified, user should confirm.”

This is the equivalent of “I’m showing you my work but I’m not vouching for it.”

Risk: Undermines trust that transparency was meant to build.

Strategy 4: Curated Source Lists

Only allow AI to cite from a small set of highly vetted, regularly audited sources.

This limits exposure but reduces AI flexibility.

Risk: Less comprehensive answers, potential blind spots.

Strategy 5: Embrace Full Transparency

Go all-in on transparency and invest heavily in ensuring everything cited is accurate, current, and defensible.

This is the most principled approach but the most expensive.

Risk: High operational cost, slower iteration.

The Insurance Question

I predict we may even see AI liability insurance products specifically covering transparency risks:

“Coverage for claims arising from AI-cited sources, explanations, or reasoning.”

The premiums will vary based on:

• How transparent your system is

• How well you vet sources

• Your industry’s regulatory environment

• Your update and quality control processes

Businesses that want transparency benefits will need to pay for the associated risk coverage.

The Regulatory Wildcard

Here’s what businesses should be most worried about: regulators might mandate transparency without fully understanding the liability implications.

“All AI systems must explain their reasoning and cite sources.”

Okay, fine. But what’s the legal standard for those explanations and citations?

If the regulation says “be transparent” but the legal system then holds you fully accountable for everything you reveal, you’re in an impossible position.

The businesses that navigate this best will be those actively engaging with regulators to ensure transparency requirements come with appropriate liability frameworks.

The Philosophical Question

There’s a deeper question here about the nature of AI:

If AI is just a tool, should businesses be liable for its outputs when they’ve shown their work?

If you provide a calculator and show the calculation, are you liable if the math is wrong? No—the user should verify.

If you provide an AI and show the reasoning, are you liable if the reasoning is wrong? This is less clear.

The more sophisticated and convincing the AI, the more liability probably attaches.

But we don’t have case law on this yet. We’re in legal gray area.

The Practical Path Forward

For businesses deploying transparent AI, here’s what I recommend:

1. Legal Review: Have lawyers review not just your AI’s functionality but your transparency mechanisms specifically.

2. Source Vetting: If you’re citing sources, vet them with the same rigor you’d use for content you’re directly publishing.

3. Update Protocols: Have clear processes for deprecating outdated information and updating sources.

4. Versioning: Track what version of knowledge your AI was using when, so you can defend historical decisions.

5. Scope Limitation: Be very clear about what your AI is and isn’t claiming. “Here’s information” vs. “Here’s advice” have different liability profiles.

6. Insurance: Seriously consider AI liability insurance, especially as you increase transparency.

7. Disclaimer Design: Work with legal to craft disclaimers that provide protection without completely undermining trust.

The Uncomfortable Prediction

I think we’re heading toward bifurcation:

High-trust, high-liability AI: Fully transparent, heavily vetted, expensive to maintain. Used for high-stakes decisions in regulated industries.

Low-trust, low-liability AI: More opaque, lighter vetting, cheaper to run. Used for low-stakes recommendations and general information.

The middle ground—”sort of transparent but not really accountable”—won’t be sustainable.

You’ll either go all-in on transparency and accept the liability, or you’ll stay more opaque and compete on other dimensions.

The bottom line: Transparency in AI systems builds trust but creates liability. The more you reveal about sources, reasoning, and methodology, the more accountable you become for accuracy and soundness. Most businesses haven’t thought through this trade-off. Those that do will develop clear strategies around what to reveal, how to vet it, and how to manage the associated legal exposure. Those that don’t will face unpleasant surprises when transparency commitments create unexpected liability.

How are you thinking about the transparency-liability trade-off in your AI systems? What’s your strategy? I am really curious to know.

I’m Gopi Krishna, founder of Hyperleap AI, where we’re building infrastructure for businesses to deploy AI chatbots, tools, and assistants. These observations come from watching businesses navigate the tension between user demands for transparency and legal concerns about liability. Previously at Microsoft, where I built systems for Office 365 and Outlook.com serving billions of users.

I had a conversation recently with a founder who was struggling to explain his business model to investors.

“We’re a team of 12,” he said, “but we’re shipping work that would normally require 50 people. How do I explain that? What metrics do I use?”

This is a question that’s about to become universal. And most businesses aren’t remotely prepared for it.

For the past century, we’ve measured business capacity primarily through headcount. Revenue per employee. Output per worker. Productivity ratios. Our entire framework for understanding organizational capability is built on human units.

But what happens when a significant portion—perhaps the majority—of your organization’s productive capacity comes from AI agents, not human employees?

Our measurement systems are about to break. And the second-order effects will reshape everything from how we value companies to how we structure organizations.

The Headcount Era: What We’re Leaving Behind

Let’s start by acknowledging what headcount metrics actually measured: they were a proxy for organizational capacity, complexity, and value creation.

When you said “we’re a 500-person company,” that communicated:

• How much work you could handle simultaneously

• Your organizational complexity and management overhead

• Your ability to scale operations

• Your burn rate and cost structure

• Your market positioning (startup vs. enterprise)

These metrics worked because human capacity was relatively standardized and easily measured. One engineer = roughly X amount of code per year. One salesperson = roughly Y pipeline generated per quarter.

Messy, yes. But consistent enough that investors, analysts, and operators could make meaningful comparisons.

That era is ending.

Subscribe now

The New Reality: Hybrid Capacity

I’m seeing businesses where the breakdown looks something like this:

Company A: SaaS Platform (Traditional)

• 50 human employees

• Revenue: $10M

• Revenue per employee: $200K

Company B: SaaS Platform (AI-Augmented)

• 15 human employees

• 25 AI agents handling customer support, content, data analysis

• Revenue: $10M

• Revenue per employee: $667K

By traditional metrics, Company B looks 3x more productive. But is it? What’s the actual capacity of those AI agents? How do you compare them to humans? What are the marginal costs?

The traditional metrics tell you nothing useful here.

The Measurement Problem: Five Key Dimensions

As I’ve watched businesses integrate AI at scale, five distinct measurement problems have emerged:

1. The Capacity Question: How Much Work Can AI Actually Do?

An AI agent can handle thousands of conversations simultaneously. Does that count as 1 “employee” or 100?

A human analyst might spend 40 hours analyzing data and writing reports each week. An AI can do equivalent analysis in minutes. Is that 1x the capacity or 100x?

The answer is: it depends on what you’re measuring. AI can handle enormous volume but often requires human oversight for quality control. So is the capacity multiplicative or additive?

We don’t have good frameworks for this yet.

2. The Cost Structure Question: Fixed vs. Variable

Human employees have relatively fixed costs. You pay salary, benefits, overhead—whether they’re working at 50% capacity or 100%.

AI has primarily variable costs. You pay per API call, per token, per computation. This fundamentally changes cost structures.

A company that runs entirely on AI agents during peak season and scales down during slow periods has a radically different cost profile than a company with the same capacity in human employees.

But how do you communicate this to investors? What’s the right way to model this? Traditional financial metrics aren’t built for it.

3. The Quality Question: Is AI Output Equivalent to Human Output?

This is perhaps the most contentious issue. An AI can write a product description in seconds. A human copywriter might take an hour. Are these equivalent?

Sometimes yes. Sometimes the AI output needs significant human editing. Sometimes the AI is actually better.

How do you measure productivity when quality is inconsistent and context-dependent?

4. The Scaling Question: What Does Growth Mean?

In traditional businesses, growth meant hiring. If you wanted to 2x your capacity, you 2x your headcount (roughly).

But if you’re AI-enabled, growth might mean:

• Adding more AI capacity buying more AI tools (relatively cheap)

• Adding more human oversight (still expensive)

• Building better systems (upfront investment, long-term leverage)

What does “scaling” even mean in this model? How do you forecast it?

5. The Value Question: What Are Investors Actually Buying?

When a VC invests in a company, they’re buying future capacity to create value. Traditionally, that meant betting on the team’s ability to hire and scale operations.

But if most capacity comes from AI, what are they buying? The quality of your AI systems? Your ability to architect reliable automation? Your human talent at oversight and strategy? Your judgement on what AI systems and tools to leverage?

The value drivers have fundamentally changed, but the valuation models haven’t caught up.

The New Metrics We Need

If traditional headcount metrics are breaking down, what should replace them? Here are some early thoughts:

Hybrid Capacity Units (HCU)

Some companies are trying to create standardized units that combine human and AI capacity. For example:

• 1 HCU = 1 full-time human OR X amount of AI driven work OR some combination

The problem is determining the conversion rate. How much AI equals one human? The answer varies wildly by task.

Output-Based Metrics

Rather than measuring inputs (headcount), measure outputs directly:

• Customer conversations handled per month

• Documents processed per week

• Analyses produced per quarter

This works better for some functions than others. Easy for customer support. Harder for strategic work.

Leverage Ratio

A metric I find interesting: Human employees / Total productive capacity

This tells you how much leverage each human has via AI tools. A leverage ratio of 1:5 means each human is amplified 5x by AI.

As businesses become more AI-enabled, their leverage ratio should increase. This could become a key differentiator.

Marginal Capacity Cost

What does it cost to add one more unit of capacity?

For traditional businesses, this is the fully-loaded cost of one employee (~$100K-200K/year for knowledge workers).

For AI-enabled businesses, marginal capacity cost might be pennies on the dollar.

This fundamentally changes growth economics, but we need better ways to model and communicate it.

System Reliability Metrics

In an AI-enabled business, your productive capacity depends on your systems’ reliability. If your AI goes down, you lose capacity.

Metrics like uptime, error rates, and fallback protocols become as important as employee retention once was.

The Organizational Implications

This measurement crisis isn’t just an accounting problem—it reshapes how businesses operate:

Will This Result in a Death of the Org Chart?

Traditional org charts mapped reporting relationships between humans. But what’s the org structure when half your “workforce” is AI agents?

Do AI agents report to the humans who oversee them? Are they tools or team members? How do you represent decision-making authority?

Some businesses are moving toward “pod” structures: small teams of humans with significant AI augmentation, rather than traditional hierarchical departments.

Rethinking Compensation

If productivity is determined more by the AI systems you build than the hours you work, how should compensation work?

Should we pay based on:

• The value created (output-based)?

• The quality of AI systems architected?

• The leverage achieved (capacity multiplier)?

Traditional salary bands based on seniority and role start to feel outdated.

The Workforce Planning Problem

CFOs typically forecast hiring plans: “We’ll add 20 engineers next year to hit our roadmap.”

But in an AI-enabled world, that forecast becomes: “We’ll add 5 engineers and expand our AI footprint/usage by 500%.”

How do you model that? What’s the risk profile? How do you communicate it to boards and investors?

Subscribe now

The Competitive Shakeout

Here’s what I think happens over the next 3-5 years:

Phase 1 (Now): Everyone celebrates AI productivity gains. “Look how much more we can do with fewer people!”

Phase 2 (2025-2026): Investors start asking hard questions about sustainability and defensibility. Can this productivity be maintained? What happens when everyone has AI?

Phase 3 (2027+): New measurement standards emerge. Companies that figured out how to properly model and communicate their AI-augmented capacity will be valued correctly. Those that didn’t will be undervalued or overvalued in confusing ways.

The businesses that navigate this transition best will be those that develop clear, defensible metrics for their hybrid capacity—and can articulate them to investors, customers, and employees.

The Uncomfortable Truth

There’s an uncomfortable question lurking beneath all of this: if AI can deliver capacity more cheaply than humans, why hire humans at all for most work?

The answer is: for the things AI can’t do. Strategy. Judgment. Relationship-building. Oversight. Taste.

But this means human roles are fundamentally changing. We’re not “workers” in the traditional sense anymore. We’re architects, supervisors, and decision-makers for AI systems.

And if that’s true, we need entirely new mental models for what “employment” means, how we measure contribution, and what business capacity actually is.

Where This Leads

We’re entering a period of profound confusion in how we measure business capacity. The old metrics are breaking down faster than new ones are emerging.

This creates both risk and opportunity:

Risk: Businesses that cling to traditional metrics will be misunderstood by markets, investors, and talent. They’ll hire wrong, value wrong, and operate wrong.

Opportunity: Businesses that develop clear frameworks for measuring hybrid human-AI capacity will have better operational clarity, make better strategic decisions, and communicate their value more effectively.

The winners will be those who stop trying to force AI capacity into human-shaped boxes and instead develop new measurement frameworks that acknowledge the fundamentally different nature of AI-augmented work.

The bottom line: We’re about to experience a measurement crisis as traditional headcount metrics become meaningless in AI-enabled businesses. The companies that develop new frameworks for measuring hybrid capacity will make better decisions and communicate their value more effectively. Those that don’t will flounder in confusion.

How are you measuring capacity in your AI-augmented business? What metrics are you finding useful? I’d love to hear what’s actually working.

I’m Gopi Krishna, founder of Hyperleap AI, where we’re building infrastructure for businesses to deploy AI chatbots, tools, and assistants. These observations come from watching businesses struggle to measure and communicate their AI-augmented capacity. Previously at Microsoft, where I built systems for Office 365 and Outlook.com serving billions of users.