First Principles vs. Best Practices

Best practices are borrowed answers — what worked for someone else, packaged for reuse. First principles are your own answers, reasoned up from what's actually true for your business. Both have a place, and the skill is knowing which to reach for. Lean on best practices where being ordinary is fine, and think from first principles where being ordinary is fatal. Here's how to tell the two apart, and how to do the harder one well.

Two ways to answer a question

Faced with any real decision — how to structure your offer, how to run onboarding, how to reach your market — you can answer it in one of two ways. You can look at what others in your position do and copy the consensus. Or you can start from what's actually true in your situation and reason your way to an answer. The first is best practices. The second is first principles.

Best practices are answers that have been abstracted away from the situation that produced them. Somewhere, someone solved a problem, it worked, it got written up, and now it circulates as "the way to do it." That's genuinely useful — most of the time you don't need to reinvent anything, and the consensus is consensus for good reason. But an abstracted answer has lost the context it was born in, and context is often the thing that mattered most.

First principles keep the context. Instead of asking "what's the standard approach?" you ask "what's true here, and what does that imply?" It's slower and it's harder, which is exactly why so few businesses do it — and exactly why it produces advantages the fast-copiers can't reach.

Why best practices are so tempting

Best practices earn their popularity honestly. They're fast: you skip the thinking and go straight to a workable answer. They're safe: if it's what everyone does, nobody can fault you for choosing it, and "we followed the standard approach" is a comfortable thing to say when something goes sideways. And they're often genuinely good enough — for the majority of decisions a business faces, ordinary is completely fine.

There's nothing wrong with any of that. You should not reason a payroll schedule or a file-naming convention up from first principles; life is short and the consensus is fine. The reason best practices dominate is that they work well enough, most of the time, for most things. The problem isn't that they're bad. It's that "most things" quietly expands to include the few things that were supposed to set you apart.

The expansion happens for an understandable reason: nothing about a decision announces which category it belongs to. A positioning choice and a payroll choice arrive in your inbox looking identical — both are just something to be settled before Friday. Without a deliberate filter, the fast route wins every time, because the fast route always feels like the responsible one when there's a queue behind it.

The trap hidden inside best practices

Here's the trap: best practices, by definition, produce average results, because they're the average of what everyone already does. If you and every competitor follow the same playbook, you all end up in the same place — indistinguishable, competing on price and luck. Copying the consensus is a reliable way to be exactly as good as everyone else, which in a crowded market is another way of saying invisible.

The deeper problem is that a best practice arrives stripped of its reasoning. You inherit the "what" without the "why," so you can't tell whether it still applies. The advice that was perfect for a venture-backed company with a big team can be actively wrong for a lean founder-led business, but it reads identically on the page. Follow it anyway and you've imported someone else's constraints as if they were your own.

And best practices lag. They describe what worked, which means what worked in the past, in conditions that may already have changed. By the time an approach is common enough to be called a best practice, the edge that made it valuable has usually been competed away. You're copying the answer to yesterday's question.

None of this makes the practice wrong — it usually still works. It just stops being a differentiator and becomes table stakes, which is a completely different kind of thing to own. Table stakes are worth having and never worth being proud of, and the businesses that get stuck are the ones that mistake one for the other.

What first-principles thinking is

First-principles thinking is the discipline of breaking a problem down to the things you actually know are true, and reasoning up from there. Instead of starting with the borrowed conclusion, you start with the foundations — your real constraints, your real goals, the facts of your specific situation — and you build the answer from the ground, checking each step against what's true rather than against what's common.

It doesn't mean ignoring everything anyone has ever learned; that would be reckless. It means refusing to accept a conclusion just because it's popular, and insisting on understanding why something is recommended before you adopt it. Often you'll reason your way back to something close to the best practice — but now you'll know why, know where it applies, and know exactly when to break it. Sometimes you'll reason your way somewhere no one else is, and that's where advantage lives.

That last point is worth sitting with, because it's the one people get wrong about first principles. The output is not usually an exotic answer. Most of the time it's the ordinary answer plus a reason — and the reason is the valuable part, because it tells you the conditions under which the answer stops being right. A borrowed answer can only be followed. A reasoned one can be maintained.

This is the mode of thinking behind everything we design. A system built from first principles fits the business it's built for. We reason up from how a business actually works — which is also why we start every build by organizing what it truly knows, in the knowledge architecture framework.

How to reason from first principles

The method is more approachable than it sounds. Start by stating the problem plainly, without any assumed solution baked in — "we need to onboard clients," not "we need a better onboarding checklist," because the second smuggles in an answer. Then list what you actually know to be true about your situation: your real constraints, your real goal, the facts you're confident in. This is your bedrock.

Next, take the standard approach and interrogate every assumption inside it. For each piece, ask why it's there and whether that reason holds for you. Some will survive the question and stay — keep them, now on purpose. Others will turn out to rest on conditions you don't share, and those you discard without guilt. Finally, rebuild the answer from your bedrock upward, using only the pieces that survived. What you're left with is a solution shaped to your situation instead of someone else's.

You won't run this on every decision — it's too slow for that, and it's meant to be. You run it on the handful of choices that determine whether you're genuinely different or just another option on the list.

One decision, reasoned out loud

Here is the method on one real-shaped decision. A four-person consultancy. The best practice on offer: a services business should publish a blog every week. It is everywhere, it is not stupid, and nobody has ever asked this particular business whether it applies. Step one is to state the problem without the answer inside it — not "how do we publish weekly?" but "how do more of the right people end up in a conversation with us?"

Step two is the bedrock, and this is where most of the work happens. Rather than guessing, we point Claude Code at what the business already has: the CRM records, the last year of call notes, the referral emails. The question isn't "what should we do?" — it's "what is true here?" The numbers below are one business's, from a real-shaped example; they are not a benchmark for anyone else.

Look at what changed. The best practice said "publish weekly," which is a volume answer to a volume problem. The evidence said the pipeline was already working — the leak was that the people doing the referring couldn't articulate the difference. Seen that way, a weekly blog is effort aimed at the wrong target entirely, and the fitted answer is two or three definitive pages that give referrers the exact words. Far less content, far more effect.

Same starting problem, opposite conclusion, purely because the answer was reasoned up from this business's own facts. That's the whole return on the slower path: it aims your effort at what actually moves your business. And note where the tooling sat — Claude Code, n8n and the rest did the gathering and the plumbing, and every judgment in that transcript was made by a person. Software can hold a decision; it can't make one for you.

What the slower route actually costs

The honest accounting matters, because "think from first principles" is easy advice to give and uncomfortable advice to take. The cost isn't really time, though it takes time. The cost is that you have to say what's actually true about your business, out loud, including the parts you'd been leaving vague — and then defend a decision with no consensus behind it.

There is also a real risk, and it's worth naming plainly: reason from the ground up on bad facts and you'll build something confidently wrong. A best practice at least carries the wisdom of everyone who tried it before you. That's why step two of the method isn't optional, and why we start every engagement by organising what a business actually knows before anyone designs anything on top of it.

Set against that, the ongoing cost is genuinely low. A reasoned answer maintains itself better than a borrowed one, because each part of it is attached to a fact you can check. When the market shifts, you don't have to go looking for a new article; you look at which fact moved and re-run that branch of the reasoning. Borrowed answers give you no such handle — when they stop working, all you know is that they've stopped working.

The two approaches at a glance

Two tools, two jobs.

The row that decides everything else is "carries the why." A best practice hands you a conclusion with the reasoning removed, which is what makes it fast — and also what makes it impossible to maintain. You cannot tell whether it still applies, because you were never told what it depended on. A reasoned answer arrives with its dependencies attached, so it can be checked, adjusted and eventually retired on purpose rather than abandoned in confusion.

Read the "risk" row honestly too. Neither column is risk-free, and the risks are opposites: borrowing makes you safely invisible, reasoning makes you distinctively wrong if your facts are shaky. That symmetry is why this is an allocation question rather than a philosophy one — you're not choosing a worldview, you're choosing which risk you'd rather carry on a given decision.

When to use each

The whole skill is allocation. Use best practices for everything that isn't core to how you win — the plumbing of the business, where a standard, competent approach is exactly right and originality would just be a waste of scarce thinking. Reserve first-principles thinking for the few decisions that define you: your positioning, your offer, the parts of your process that are supposed to be different from everyone else's.

A simple filter: for each decision, ask "does being ordinary here cost me anything?" If the honest answer is no, take the best practice and move on — spend your energy elsewhere. If being ordinary here means blending into a crowd you're trying to stand out from, that's a first-principles decision, and it deserves the slow, careful thinking that most of your competitors won't be bothered to do. The advantage isn't thinking hard about everything; it's thinking hard about the right few things.

The frequency axis matters more than people expect. A decision you make weekly gets refined by repetition whichever route you took, because you see the results and adjust. A decision you make once every three years gets made in an afternoon, from whatever was nearest to hand, and then quietly governs everything for three years. Those are the ones worth booking real time for — and they're the ones that never feel urgent enough to book it.

Telling a real best practice from a fashion

All of that assumes you can tell which is which, and often you can't at a glance — the two arrive in identical packaging, usually as a confident sentence from someone successful. Three questions separate them quickly, and none of them requires knowing the subject well.

What problem does it solve? A real best practice is a compressed answer to a specific question somebody had. If nobody in the room can state the problem it was invented to fix, you are looking at a habit that spread, not a solution that worked. This one filter removes most of what circulates, because fashions are transmitted as practices while genuine practices are transmitted with their reasons attached.

Whose situation produced it? Most widely-repeated advice was derived in conditions unlike yours — a company with a hundred people, a different market, a budget that made the trade-off obvious. Practices don't travel between contexts nearly as well as the confidence with which they're repeated. The question isn't whether it worked there. It's whether the thing that made it work there is also true here.

Has anyone succeeded without it? If the answer is obviously yes, the practice is one route rather than the route, and treating it as mandatory is what turns a reasonable option into a constraint you never chose. If the answer is genuinely no, you have probably found a real one, and you can adopt it quickly and spend your thinking elsewhere.

The move that follows is not rejection — it is decompression. Take the practice, work out which question it answers, and answer that question for your own situation. Much of the time you will arrive back at the same practice, which feels like wasted effort and isn't: you now know why it holds, which is precisely the knowledge that tells you when it stops holding. A borrowed practice you understand is no longer borrowed.

Why this matters for the systems you build

This isn't only an abstract thinking exercise — it decides the quality of everything you build. Every system encodes a stack of decisions about how work should happen. Build a system on borrowed best practices and you get a generic system that produces generic results, indistinguishable from the one your competitor built from the same article. Build it from first principles — from how your business actually operates and actually wins — and you get a system that fits you, and a fitted system compounds into an advantage that can't be copied by reading a template.

That's why the systems we design don't start from a stock playbook. A Content OS or Business OS is reasoned up from the specific business it serves, which is what makes it worth owning rather than renting. And it's why the systems-minded way of working — building structure instead of grinding effort — depends on thinking clearly first. If you want the case for that, it's in why systems beat effort every time, and the same argument applied to buying rather than building is in why templates fail serious businesses.

Frequently asked questions

Are best practices always the wrong choice?

No. Best practices are a fast, safe default for anything that isn't core to how you win — where being ordinary is perfectly fine. The mistake is applying them to the parts of your business that are supposed to be different. Borrow best practices for the commodities; reason from first principles for the things that make you you.

What does thinking from first principles actually mean?

It means breaking a problem down to the things you know are true — your actual constraints, goals, and facts — and reasoning up from there, instead of starting from what everyone else does. You strip away the borrowed assumptions, ask why each one is there, and rebuild the answer from the ground for your specific situation.

Isn't first-principles thinking slower and riskier?

It's slower per decision, which is exactly why you don't use it for everything. Reserve it for the few choices that determine whether you're different or just another option. For those, the time spent reasoning from the ground up is what produces an advantage a competitor can't copy by reading the same best-practices article you did.

How does this connect to building systems?

Every system you build encodes a set of decisions about how work should happen. Build it on borrowed best practices and you get a generic system that produces generic results. Build it from first principles — from how your business actually works and wins — and you get a system that fits you and compounds into a real advantage.

How do I know which decisions deserve first-principles thinking?

Ask one question of each decision: does being ordinary here cost me anything? If the honest answer is no — invoicing, file naming, holiday policy — take the consensus and spend your thinking elsewhere. If being ordinary means blending into a crowd you're trying to stand out from — your positioning, your offer, the parts of delivery clients actually notice — that decision has earned the slow route.

Can AI tools help you reason from first principles?

They help with the mechanical half, not the judgment. A tool like Claude Code is very good at pulling apart a standard approach into its assumptions and checking each one against data you already have — call records, delivery notes, past projects. What it cannot do is decide what you want to be true about your business. The evidence gathering gets faster; the deciding does not.

Does a first-principles answer stay right forever?

No. A first-principles answer is only as current as the facts it was reasoned from, and facts change — your market, your clients, your capacity. The advantage over a borrowed answer is that you can tell when it has expired, because you know which fact each part of it rests on. Re-run the reasoning when a fact underneath it moves, not on a calendar.

The bottom line

Best practices are a shortcut, and shortcuts are fine for the parts of your business that are supposed to be ordinary. But you can't shortcut your way to being different — that only comes from thinking about your own situation more clearly than anyone else has bothered to. Borrow the consensus where ordinary is fine. Reason from the ground up where it isn't. The businesses that stand out are the ones that knew which was which.

And if you can't remember the last time you took the slow route on anything, that's the finding, not a failure. It usually means the filter was never installed — not that the thinking was avoided. Pick the one decision that would cost you most to be ordinary about, and start there.

Keep reading

• Why systems beat effort every time — the case for building structure instead of grinding.
• The knowledge architecture framework — organizing what's true for you, so you can reason from it.
• How to build a Business OS — encoding first-principles decisions into a system.