First Principles Thinking

Break a problem down to what must be true, then rebuild the solution from there instead of copying others.

Strip a design back to what must be true, drop the habits, and build up again from the constraints alone.

To an executive

Copying what others do is cheap but can lock in costs that never applied to you. Starting from your real needs can find savings competitors miss.

To an engineer

For costly choices, write down what the workload truly needs, such as throughput, ordering and retention, then build from that rather than from another team's setup.

The idea

Aristotle opens his Physics by arguing that we do not really know a thing until we know its first principles: the basic conditions and elements it rests on. First principles thinking applies that to problem solving. Break a problem down until you reach things that must be true, then build the solution back up from them.

The alternative is reasoning by analogy: "Company X uses Kafka, so should we." Analogy is fast and usually good enough. Reasoning from first principles asks what the workload actually needs (throughput, ordering, retention, latency) and builds from those constraints.

It is expensive thinking. Reserve it for decisions where inherited assumptions might be wrong, or where your context really differs from the reference case.

Why it works

Conventions carry hidden assumptions. A pattern that suited another organisation's scale, team or regulator may not suit yours. Breaking it down shows which parts transfer.

Real constraints are fewer than they look. Once regulatory, physical and economic limits are separated from habits, there is usually more room to design than the team assumed.

It makes reasoning checkable. A design built from stated constraints can be challenged one step at a time, where "everyone does it" cannot.

Where it applies

Platform and technology choices, especially when the default is to copy a well-known company.
Cost problems, where breaking a bill down to its drivers often shows a different design.
Strategy work, where the question is whether a long-standing approach still fits.
Design reviews of options that rest on "we always do it this way".

How to apply

List every requirement and assumption the current answer depends on.
Sort them into constraints and conventions. Constraints are regulatory, physical or economic facts; conventions are choices someone made.
Test each convention: what would happen if we dropped it?
Rebuild from the constraints alone, then compare the result with the conventional answer and keep whichever wins on evidence.

Example scenario

A team of four developers proposed a microservices platform with a service mesh and event streaming, because it was what large digital companies used. Their product served one domain at around 200 requests a minute.

Working from first principles, the architect listed what really had to be true: one team, one domain, modest load, strong consistency for orders and a small operations budget. The result was a modular monolith on managed Postgres, with clear module boundaries so parts could be split out later if load or team size demanded it. It cost a fraction of the original plan to run.

Questions to ask

Which of these are real constraints, and which are just habits?
If we were starting from nothing, would we choose this?
What would have to be true for the obvious answer to be wrong?

When not to use it

Well-trodden problems where an industry pattern fits and the stakes are low; re-deriving it wastes time.
Decisions under time pressure, where a sound analogy and a reversible choice beat a slow analysis.

How it misleads you

Re-deriving everything from scratch can mean ignoring hard-won industry experience. Patterns often encode lessons about failure that no first-principles analysis on a whiteboard will rediscover. Use first principles to challenge assumptions, not to throw away accumulated knowledge.