Startup First Principles

Every startup framework started as someone’s insight based on real experience. Then it’s written about in books and blogs, and eventually followed like a recipe, and the principles are forgotten.

The lean startup, build-measure-learn, building an MVP and iterating. These were powerful concepts that emerged from real struggle some years ago, and have set a foundation for how many founders have operated since.

Is it wrong? No. Is it right? Also, no.

They are not universally right or wrong, but highly contextual. Is a hammer the right tool? It depends on what you want to build.

The problem is founders began following these frameworks like a map. But there is no map for building a startup. Only raw constraints, principles, and problems.

By nature, a successful startup must challenge conventional wisdom, be contrarian and navigate uncharted waters. So then, why do we expect to look for answers in frameworks? Why would there be an operating manual?

The concept of an MVP, for example, was born in a world where building was dreadfully expensive, and so was building the wrong thing. Where building the wrong thing could mean life or death for your company.

But the world changes, and so do the constraints we work within.

It’s no longer expensive to build. You can ship a fully working version of your product (not an MVP) in an afternoon with nothing but a cup of coffee and a Claude subscription. The risk profile of making a “wrong” product decision has changed.

So, let’s step away from frameworks, and instead think from first principles. Startup first principles. These are laws of physics. Unmoving, and non-expiring. A small set of primitives you can use to reason about any startup decision from scratch.

First principles thinking beats any framework because it lets you navigate the unknown. Exactly what early‑stage startup life is.

The primitives

Here are seven building blocks. Every framework, methodology, and piece of startup advice can be expressed as some combination of these.

Time. Your only real resource. Everything else is derived from it. Money is stored time – you trade hours for dollars, then trade dollars back for someone else’s hours.

Risk. The probability that something you believe is wrong, or that something you haven’t anticipated will hit you. Risk is the reason you validate before building. It’s also the reason you sometimes shouldn’t – if the risk is already low enough, validation could be waste.

Facts. Things that are objectively true, as opposed to things you merely believe. The gap between facts and beliefs is where risk lives. Closing that gap – through evidence, experiments, conversations – is most of what early-stage work actually is.

Objectives. Future states you’re working toward. The destinations you can articulate and communicate to a team. Without clear objectives, time gets spent in every direction, which is the same as spending it in no direction.

Assets. Anything you own or have built, that is worth something: product, equity, IP, brand, data, relationships.

Obstacles. External forces that consume time with zero return. Regulatory blockers, team conflicts, market shifts. They don’t advance your objectives – they just burn your resources.

Leverage. Anything that multiplies the impact of time spent. A great hire is leverage. A distribution channel is leverage. So is morale – a motivated team gets more from every hour than a demoralised one. Leverage is why some startups move ten times faster than others on the same resources.

Frameworks in terms of primitives

Once you see the primitives, you can decompose any motion into its moving parts.

Fundraising: Exchanging a portion of your assets (equity) for time (via money) and often leverage (the investor’s network, credibility, advice).

A hypothesis: A believed fact combined with the risk that you’re wrong.

When you can see something as a combination of primitives, you can decide whether it actually applies to your situation, or whether a different combination would serve you better.

The MVP, decomposed

Let’s explore a bigger example.

Building an MVP is fundamentally: Spending time on a short-term objective (the MVP) designed to gather facts and lower risk, in service of a bigger objective (the real product).

Strip away everything you’ve read about MVPs in books and blogs, and that’s what’s left. A formula. And once you have the formula, you can actually think about it.

Should you build an MVP?

Start with the risk. What’s your current level of understanding? What evidence do you already have? What assumption, if wrong, would kill you?

Then ask: is an MVP the best way to gather evidence, lower risk, and avoid obstacles – or is something else better, given your primitives?

A prototype is for you. It reduces technical or experience risk: “can we build this?” “what might this feel like?” An MVP is for the market. It reduces demand and behaviour risk: “will anyone actually use or pay for this?” Same activity (building), different primitives you’re trying to move.

Some examples:

If your biggest uncertainty is technical feasibility, a prototype makes more sense. You’re trading a bit of time to lower risk and turn a belief into a fact: “this can actually work.” Shipping an MVP to real users before you know that is just an expensive way to learn the same thing.

If your biggest uncertainty is demand or behaviour, an MVP or landing page is better. You already know you can build it; now you want new facts about whether people care enough to change what they do. Here, over‑investing in prototype polish doesn’t change your risk profile much.

If your biggest uncertainty is regulation or distribution, neither helps much. Your risk sits in external obstacles. The right move is to stop building and go create facts by talking to lawyers, partners, or platforms first.

Seen through primitives, “build an MVP” is never the starting point.

The starting point is: what is the most critical assumption we have right now? What do we believe to be true that, if wrong, will kill our thesis?

Then devise a way to gather evidence and learn. Whatever you learn may change your course of direction, and that’s a great thing. The more often you can do this, the more rapidly you reach product-market fit.

Sometimes that’s an MVP, sometimes it’s a prototype. Sometimes it’s something completely different.

Swimming against the current

Successful founders are able to take contrarian positions, which comes from understanding a situation or topic clearly enough to decide what’s best for you, despite what everyone else is doing or saying.

That’s what first principles thinking buys you. Not a license to blindly ignore conventional wisdom, but the ability to evaluate it and decide if it’s for you. Everyone might be telling you to interview more users (and most of the time they’re probably right) but if your biggest risk is something user interviews can’t touch, spending time on them isn’t just unhelpful; it could be harmful, because of the opportunity cost and the false sense of progress.

There is no single correct answer to any startup question. The right move depends on your specific combination of time, risk, facts, objectives, assets, obstacles, and leverage. Startups are inherently resource-constrained. Sometimes you have to swim against the current to do what’s right for you, in that moment.

That takes judgment. And judgment comes from thinking in primitives, not following playbooks.