The Most Dangerous Instinct in the AI Era

Every builder has the same instinct: see a problem, start coding.

In the AI era, this instinct is more dangerous than ever. Tools are so good now that you can ship a prototype in a weekend. The friction between “I have an idea” and “I have a product” has collapsed to almost nothing.

That’s the trap. The faster you can build, the faster you can waste months building the wrong thing.

RigorJobs: death by instinct

I had a hunch that job seekers needed better ways to prepare for technical interviews. It felt obvious. The market was huge. AI could personalize the experience. I’d seen people struggle with it. I told myself that was research.

So I built RigorJobs.

I didn’t talk to users first. I talked to the idea. I turned it over in my head, convinced myself of the pain, mapped out the features, and started building. Every line of code felt like progress.

When I eventually showed it to people, they said things like “this is cool” and “I could see myself using this.” I heard validation. What they were actually doing was being polite — getting me off their face without causing conflict.

The real signal came later, when I asked people to pay. Nobody did. Not because the product was broken. Because the problem wasn’t urgent enough. They were already solving it — with YouTube, with LeetCode, with free mock interview sites, with a friend who’d been through the process. My “obvious” pain point was a mild inconvenience sitting inside a saturated solution space.

Months of work. Gone. Not because I couldn’t build — because I never stopped to ask whether I should.

PrepCall: survival by validation

PrepCall started differently. Not with a hunch — with a conversation I wasn’t trying to have.

I was talking to someone about their work — not pitching, not researching, just asking questions about what their day looked like. They told me, unprompted, about the anxiety they felt before high-stakes presales calls. Not “it would be nice if there was a tool for this.” Not “have you thought about building something for this?” They described the feeling. The night before a call with a major prospect. The uncertainty about what objections would come. The fear of walking into the room underprepared and losing a deal that took months to get.

Then I asked what they did about it. That question matters more than most people realise. If someone can’t tell you what they’re already doing to solve the problem, the problem probably isn’t real enough to pay for. They told me exactly what they did — the hours spent manually researching the company, piecing together context from LinkedIn and Crunchbase and old emails, trying to anticipate questions. It was time-consuming, incomplete, and they knew it.

That’s a different signal entirely. That’s someone already paying a cost — in time, in stress, in lost sleep — for a problem they can’t fully solve. I didn’t have to convince them the problem existed. The problem was already costing them something before I walked in.

I asked if they’d ever looked for a tool. They had. Nothing fit. The generic prep tools didn’t understand the presales context. The CRM data was there but disconnected. They’d cobbled together a workaround that kind of worked, but they hated it.

PrepCall survived because that conversation happened before a single line of code was written. The pain was real, urgent, and already costing people something. I just had to build something better than their workaround.

What validation actually sounds like

Most founders think validation sounds like enthusiasm. “That’s amazing, I’d definitely use that.” That’s not validation. That’s a compliment. Compliments are free. They cost the person giving them nothing and they cost you everything if you believe them.

Real validation sounds different. It sounds like someone describing a problem in their own language, not yours. It sounds like specifics — this happened on Tuesday, it cost me three hours, I ended up doing it this way because there was nothing better. It sounds like someone who’s already tried to solve the problem and failed.

The test isn’t “would you use this?” The test is “what are you using now, and what’s wrong with it?” If they’re using nothing, the pain probably isn’t real. If they’re using something imperfect and complaining about it, you have a market.

The AI era made this worse

Before AI tools, the gap between idea and shipped product was wide enough that you were forced to think. You’d spend weeks just setting up infrastructure. That friction, frustrating as it was, created space for doubt — and doubt is where validation happens.

Now you can prompt your way to a working prototype before you’ve finished your coffee. The gap is gone. Which means the forcing function is gone too. You can ship your hunch before you’ve had time to question it.

The instinct to build is the most dangerous instinct a technical founder has. Not because building is bad — but because building feels like progress even when it’s not.

Validation doesn’t feel like progress. Talking to people doesn’t feel like progress. Sitting in a coffee shop asking questions instead of writing code does not feel like progress.

But it is. It’s the only real progress there is before you write the first line.

I built RigorJobs in weeks. I killed it in months. The conversation that saved PrepCall took forty minutes.

The math isn’t complicated.