In 2014 I started VipKing, an app for getting into Barcelona nightclubs. We later spun a piece of it out as Pictus. Neither made me rich. Both taught me things that ten years of engineering jobs had not.
I bring it up because I now spend a lot of time in rooms where a founder and an engineering lead are talking past each other, and the reason I can usually see the gap is that I have been wrong from both chairs.
Mistake one: I optimised the part I enjoyed
I'm an engineer. So I built. The architecture was clean, the animations were smooth, the release process was tidy. I spent weeks on things no user would ever notice, and I felt productive the entire time, because building is measurable and selling is not.
Meanwhile the actual question — will club owners give away entry to strangers? — went untested for months. It was answerable in two weeks with a spreadsheet and ten phone calls.
This is the single most common failure I see in technical founders, and it never looks like a failure from the inside. It looks like progress.
Mistake two: I confused the product with the business
The app worked. Users liked it. That felt like traction. It wasn't — traction was clubs renewing, and clubs renewed for reasons that had almost nothing to do with the software: relationships, timing, whether the promoter that month liked us.
I was iterating hard on a variable that wasn't the constraint. If your product improves and nothing changes, you're improving the wrong thing, and no amount of engineering rigour will save you.
Mistake three: I treated running out of money as a finance problem
It's a decision-speed problem. Every week spent on something that didn't reduce a real uncertainty was a week of runway spent for nothing. I didn't think in those terms until it was late.
I learned that framing properly in the two programmes I went through that year — Yuzz, Banco Santander's pre-accelerator, and NEXT, Powered by Google for Entrepreneurs. What both drilled was uncomfortable: what would have to be true for this to work, and what's the cheapest way to find out? I've written separately about what those programmes got right.
Every week that doesn't reduce an uncertainty is runway spent on nothing.
The lesson that cost me a company to learn
What it changed about how I work
When I later became the technical lead on products with real users — an iOS app with over a million downloads among them — I brought back three habits that no engineering job had taught me.
- Ask what happens if we're wrong. Before estimating anything. If being wrong is cheap, ship and find out. If it's expensive, slow down. Most teams apply the same rigour to both, which is wasteful in one direction and reckless in the other.
- Say the business consequence out loud. Not "we should refactor the sync layer" but "if we don't, every new customer takes three weeks to onboard instead of one day." Executives aren't ignoring technical debt — they're being told about it in a language that gives them no way to prioritise it.
- Protect the decision, not the code. Beautiful code implementing the wrong decision is the most expensive thing an engineering team can produce, and it's produced by good people every day.
Why any of this matters to you
If you're a founder without a technical background, the person you most need is not the best engineer you can afford. It's someone who will tell you that the thing you asked for isn't worth building — and who has enough scar tissue to be right about it.
If you're a CTO whose CEO seems unreasonable, they're usually optimising a variable you can't see, on a clock you're not being shown. That's a translation problem, not a competence problem.
I've been the founder who built the wrong thing carefully, and the engineer who was right about the code and wrong about what mattered. Being wrong from both chairs is, as far as I can tell, the only way to learn where the gap actually is.