I had the last slot of the day. A room full of engineers at Khalifa University who don’t just want to write code — they want to start companies. Two excellent sessions had already run before mine: one on validation and business modelling, one on design thinking. By the time I stood up, the room had heard, twice, why you should validate before you build.
So I didn’t relitigate it. I picked up where they left off. They’d learned how to find a problem worth solving and how to test it. My job was the next question, the one that keeps me up at night more than any other: once you know what to build — how do you build the smallest right thing, fast, without wasting a year?
Here’s the short version of what I told them.
The trap every engineer falls into
Building feels safe. Testing is scary, because a test can say no.
So we hide inside building. We add a feature, then another, then a dashboard nobody asked for, and it feels like progress. It isn’t. Busy is not the same as forward. I’ve watched brilliant technical founders — people who could ship anything — pour eighteen months into the wrong thing simply because building was more comfortable than finding out they were wrong.
The uncomfortable truth I opened with: most startups don’t die because they built the wrong thing. They die because they built too much of the right thing, too early.
Every idea rests on exactly one belief. If that belief is false, the whole thing collapses. Your only real first job is to find that belief and test it as cheaply as humanly possible. Everything else is decoration.
The cheapest test I ever ran
I told them the TheCloud story, because it’s the clearest example I have.
TheCloud was a big idea — using spare capacity in existing kitchens to run delivery brands, leaner and faster than anyone else. The obvious plan was twelve to eighteen months of platform building. Instead, we launched in two days. No app. No system. We took orders through WhatsApp, by hand, like it was 2010.
Within a month we were doubling sales every month. That was the proof — and, later, the investor story. Doubling money is a fact nobody can argue with. A survey can’t give you that.
The system came after the proof. Then it scaled to $26M a year across eight markets. But if those first customers hadn’t paid and come back when three people were running the whole thing off a phone, no beautiful platform would have saved us.
I told them the Eyewa story too, as the counter-example — the moment success tempts you to build the impressive thing instead of the valuable thing. The lesson that stuck: the feature that gets you funded is rarely the feature that makes you big. Watch what customers do with their money, not what they compliment.
The part nobody else talked about: AI
This is where I earned my slot. Nobody before me had mentioned it, and it’s the biggest shift in how we build since I started.
Most people use AI like a vending machine — they type “build me an app for X” and take whatever falls out. And here’s the thing: the AI doesn’t fail you by being stupid. It fails you by being too eager to please. Ask for the least, and it gives you the most — twenty features you never validated, generated in an afternoon, that you now feel weirdly attached to before a single customer has weighed in. A vague prompt is permission to give you everything.
The fix is one idea: hand it a limit. Constraint is the whole skill.
I showed them how I actually use AI — not to get answers, but to attack my own idea. Point it at your plan and ask it to be a skeptical investor. Ask it to rank every assumption by how fatal it is if wrong. Ask it to design the cheapest test that could prove you wrong in two weeks. Ask it what you can cut and still learn. AI is brutal about cutting, because — unlike you — it has no ego in your idea. That’s exactly why it’s useful. It’s a sparring partner, not a vending machine.
The same discipline applies when you finally write code. “Build me the app” gets you four thousand lines you don’t understand and can’t fix. But spec one core feature, make the AI plan before it codes, build one slice at a time and test as you go — and you move five times faster while staying the architect. Same AI. Different operator. The tool is identical; the skill is yours.
What I left them with
I sent them home with three lines and one piece of homework.
The three lines: find the one belief that could kill your idea and test it first. Make people spend something — a free “yes” is noise. And treat AI as a sparring partner, not a vending machine.
The homework: take the riskiest assumption in whatever you’re building, run it through those questions tonight, and come back with the belief that could kill it and the cheapest test to check it.
Because here’s what’s genuinely new. The tools used to be slow and expensive. Now one person can do what took a team of eight a decade ago. TheCloud didn’t have any of this. You do. The edge is no longer building fast — everyone can build fast now. The edge is learning fast.
Build less. Learn faster. Ship the right thing. Everything else is slideware.
If you’re building something and want a sparring partner who’s actually done it — raised the rounds, shipped the product, made the wrong calls and a few right ones — reach out here. I share real-world lessons for founders on the blog and in my advisory sessions. Let’s build something remarkable together.
