Tech Is the Easy Part
The hard part isn't building. It's everything else.
Last week, a founder reached out for advice. Two co-founders — one technical, one not — a couple years of R&D, patents pending. They’d built something they described as a breakthrough: AI-powered app generation, any app, a few hours. They were ready to raise several million euros. Think Lovable, but better.
I asked the usual questions. What’s the product? Who’s the customer? How do you distribute it? What’s your unfair advantage?
The answers were thin. No clear vertical. No distribution plan. No product, really, just capability.
I pushed on all of this for an hour. And then the non-technical co-founder said the thing that made me sit back in my chair:
“Well, we did the hard part. We solved the tech.”
Here’s what’s actually happening.
If you’re an engineer — or if you’ve built a company around one — tech feels hard because it is hard. It’s complex, demanding, and requires real skill. But it’s also legible. You write code, you get feedback. You solve a problem, you know it’s solved. Effort correlates with output. The system makes sense.
The rest of the business doesn’t work like that.
Distribution is not legible. You can do everything right and still fail. Positioning is not legible: you’re trying to exist in someone else’s mind, and you can’t compile that. Saying no to opportunities, picking a vertical, pricing, hiring, firing; none of it gives you the clean dopamine hit of a passing test suite.
So technical teams do what’s rational: they retreat to where effort is rewarded. They keep building. They add features. They refactor. They convince themselves that if the tech is good enough, the rest will follow.
It won’t.
Ben Horowitz called his book The Hard Thing About Hard Things because the hard things aren’t the technical problems. They’re the ambiguous, human, no-right-answer problems. The ones where you have incomplete information and the consequences are irreversible.
For a technical founder, the hard thing is almost never the tech. The hard thing is:
Picking one customer, one use case, one vertical, and ignoring everything else
Building distribution before you feel ready
Charging money before the product is “done”
Talking to the market more than you talk to your codebase
The tech is the part you already know you can solve. That’s exactly why it’s the wrong place to start.
If you’re a technical founder and you’ve spent two years on R&D with no product, no customers, and no distribution, you haven’t done the hard part.
You’ve been avoiding it.