The first startup I joined from day one failed.
That's not the interesting part. What was uncomfortable was that after it failed, I couldn't really tell you why. We'd built for a long time. We'd shipped a product. We had users, sort of. But somewhere along the way, the actual lessons had slipped through our fingers.
We'd been doing what I now call the grand reveal: heads down, building in something like secret, planning to unveil the finished thing to a market we assumed would love it. The market didn't love it. And because we hadn't been testing along the way, we couldn't even sort the signal from the noise. Was the product wrong? Was the audience wrong? Was the timing wrong? All three? We had no way to know.
So I read.
The Lean Startup was the first one. Then The Phoenix Project. What they did wasn't introduce new ideas — most of the build/measure/learn loop is intuitive once you see it. What they did was give me a vocabulary for what we'd skipped, and a framework for not skipping it again.
The headline isn't "build fast." It's: don't do more than you need to validate the hypothesis. Every line of code, every feature, every week of work is a bet against a hypothesis that may or may not be right. The only way to know is to release something and pay attention to what comes back.
SKUit: when your customer is you
I've been running SKUit — a warehouse management system I built for the supply chain business I co-founded — for about seven years. The reason that project has worked, to the extent it has, is that the end customer was us. Every release gets used the next morning at a warehouse. The feedback loop is impossibly tight: I ship, and within hours someone tells me whether it helps or gets in the way. After seven years of that, the codebase is shaped by what actually works, not by what we guessed would work at the start.
KnowThySurvey: doing it on purpose from day one
KnowThySurvey — a science-backed mental health survey platform I'm building with a co-founder who holds a PhD in psychology — is doing the same thing from day one. Initial version is live. One survey is in. We meet weekly at a dive bar, ship, watch, and adjust. Methodical, repetitive, and easily the most exciting part of the work.
The caveat: "release early" is contextual
"Release early" doesn't mean "release to production fast" in every context. If you're building a SaaS or a survey, sure — production is your test environment. If you're building software for a hospital or a self-driving car, that posture will hurt people. The principle is the same — learn before you commit, validate before you scale — but the mechanics have to fit the stakes. Sometimes "release early" looks like a clickable Figma in front of three users. Sometimes it's a sandbox environment. Sometimes it's a user interview with no software involved at all. The creativity is in figuring out what the cheapest viable form of learning is for your context.
The whole job
So when founders ask me how I'd approach building their thing, the answer almost always boils down to: what's the smallest possible bet you can make right now that will teach you the most about whether this is worth scaling? Then make that bet. Then make the next one.
Get good at learning. That's it. That's the whole job.