Startup Post-Mortem: Lessons from My Startup Odyssey

Some of the most useful lessons I’ve taken from work have come from looking back honestly at things that didn’t work. In that spirit, this post is a collection of notes from my own failed startup journey — observations across engineering, business, design, and a handful of things that don’t fit neatly into any of those buckets.

Engineering

The biggest engineering advantage a startup has over a larger organisation is the ability to move fast. Embracing scrappiness was the single most underrated skill on our team. It’s tempting to plan features and services thoroughly before touching the keyboard, but the right move is almost always to implement, ship, and iterate.

A close cousin to that: always build the very first version of a product as quickly and as simply as you can, even if the code is ugly. You learn far more from putting something in front of people than you do from polishing a private prototype. Clean code can wait until there’s a baseline to clean.

Once that baseline exists, then invest the time to read through the code, refactor the rough edges, and optimise the parts that matter. Doing this regularly is what keeps a young codebase from becoming an old codebase three months after launch.

One thing we underestimated was the onboarding experience for new engineers. We ended up with too many repos and services for a team of our size, and every new joiner paid the tax. If I were doing it again, I would consolidate aggressively early on and treat “easy to clone, easy to run, easy to ship” as a first-class engineering goal.

The last engineering lesson is the simplest one: keep the team small until there is a clear, painful reason to grow. Lean teams stay agile. Bigger ones spend a surprising fraction of their time coordinating themselves.

Business

The most important business lesson I learned is that real problems are found, not theorised. The best ideas came when we paid careful attention to what people were actually doing, instead of looking for evidence to support a problem we had already decided existed.

Once you have a candidate problem, the second instinct should be to understand it deeply — and to fight your own cognitive biases on the way. It’s easy to talk yourself into believing you understand a customer’s pain. It is much harder, and much more valuable, to actually understand it.

A related lesson, and one I had to learn the hard way: separate your value as a builder from any single idea. The thinking process is the durable thing. If a specific idea is not working, let it go and apply the same thinking to the next one. Founders who attach their identity to one idea tend to ride it down.

Talk to customers as early as possible — earlier than feels natural. Their feedback shapes the product in ways that internal debate can never match. And once you have customers, never take customer service for granted; the way you handle the messy edges is often what builds long-term trust.

Finally, be uncomfortably clear about your value proposition. If you can’t say in one sentence why someone should care, the product probably isn’t ready to charge for.

Design

Two notes here, and they are both about restraint. First, don’t reinvent the wheel — established design patterns exist because they work, and you almost always have more interesting problems to spend creativity on than the parts of your product that already have good answers in the wild.

Second, especially in the early stages, use templates and starter kits. Design is enormously time-consuming when you start from a blank canvas. Save the bespoke work for the parts of the experience that are genuinely differentiated.

Miscellaneous

One last one that bridges everything above: study your competitors carefully, but resist the urge to mimic them. Understand why they made the choices they did, then use that understanding to inform a path that fits your team and your customers. Copying surface features rarely transfers the underlying advantage.

None of these lessons are unique to me. But writing them down, in my own words, is what makes them stick — and if any of them save someone else a few months of the same mistakes, the post will have done its job.