The First Mistake Most Founders Make (I Made It Too)
Part 1/n of an ongoing series on what I’d do differently across 8 years of building. These are short blogs I am planning to post almost everyday.
It was early 2018.
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.