Core and Bloat Work with me Subscribe →
A classification for technology organizations

Core and Bloat.

A way to make better product and technology decisions before they become expensive. Sort every part of a growing product, team, or system into four categories, and the room finally has a shared language for what is worth keeping and what has quietly accumulated.

Core
What must be there.
Platform
What holds it up.
Bloat
What accumulated.
No-Go
What we chose not to build.

I have sat in the meeting where a company quietly decides to die.

Nobody in the room calls it that. Everyone is trying. The decision that gets made sounds like a solution. More features. A pivot. A new tool that will speed things up. Six months later the burn is the same, and the thing that was wrong is still wrong. Only now it is more expensive, and welded into the architecture.

I have watched that happen across SaaS, IoT, fintech, marketplaces, and enterprise systems, in enough companies to know it is not a leadership problem. It is a missing question. Nobody had a shared way to ask the one thing that mattered before the expensive decision got made.

What here actually matters,
and what has just accumulated?

That is the whole method. I call it Core and Bloat.

Asked early, that question changes what happens next. You start to see which parts of a system earn their place and which are just there, taking up room and nerve. You make the expensive call with your eyes open instead of in the dark. This was never about less software. It is about seeing clearly enough to choose.

What it is

Core and Bloat, defined.

Core and Bloat is not a framework you apply to a system. It is a classification of what is already in it. Every part goes in exactly one box.

Core is what the product must do. The value people actually came for. Take it away and there is no product left.

Bloat is what someone hoped it might do, or what used to be Core and quietly stopped being it. Bloat is rarely junk at birth. It accumulates. Yesterday's good idea, still there because nobody is sure what breaks if it goes. That fear is usually the only thing holding it up.

Most technical debt is a product decision wearing a technical costume. The code is not the root. The code is where the root became permanent.

The four categories

Every part of a system goes in exactly one box.

Core

Core

What the product must do. The value the user actually came for. Take it away and the product stops being the product.

The question: If this disappeared tomorrow, would anyone still pay?
Failure mode: Core that was assumed, never proven. Or Core that stopped being Core, and nobody re-checked.
From the work: One dashboard had 91 configurable widgets. Most active users touched three.
Platform

Platform

What the product needs in order to operate. Not the value itself, but what the value stands on: authentication, payments, infrastructure, the plumbing. Necessary, not differentiating.

The question: Does the user pay for this, or does the product just need it to keep the lights on?
Failure mode: Platform decisions made for the business you were, which are the wrong decisions for the business you became.
From the work: A managed-MongoDB bill made the unit economics unworkable. Six months to rebuild.
Bloat

Bloat

What someone hoped the product might do, or what Core used to be and no longer is. Accumulated complexity. Features nobody asked for. Processes nobody can explain. Bloat is rarely junk at birth. It becomes Bloat.

The question: Who asked for this, and are they still here? Can anyone explain why it exists without telling a story about the past?
Failure mode: Bloat is load-bearing in fear, not in function. The team keeps it because nobody is sure what breaks if it goes. That fear is the tell.
From the work: A 47-item roadmap cut to eleven. Only the eleven shipped in the year that followed.
No-Go

No-Go

What has been considered and consciously rejected, written down, with the reason. The category that is almost always missing, and the cheapest artifact with the highest leverage.

The question: What are we deliberately not building, and does everyone new know why?
Failure mode: A No-Go nobody wrote down gets re-proposed by every new hire, every new investor, every new board member, until one day it gets built by accident.
From the work: A feature explicitly rejected by three founders in a row. Built by the sixth new hire, because nobody wrote it down.
Adding engineers is often the most expensive way to hide structural problems.
A pattern I keep seeing
The mechanism

Drift.

The four categories are not fixed. Things move between them, almost always in one direction: toward Bloat.

Core outlives its reason. Platform built for the old business turns into a liability under the new one. A hope that was never Core hardens into a feature the team is now afraid to remove.

Drift is normal. It is not bad leadership. The job is to catch it while removal is still cheap, before it welds itself into the architecture. So Core and Bloat is a practice, not a one-time audit: sort, wait a quarter, sort again, watch what moved.

How to use it

Six steps. Six principles baked in.

  1. 01
    List the system honestly.

    Every feature, service, and process. No exceptions for the ones people are proud of.

    Principle Nothing stays Core by default. Everything begins as Core or as a hope.

  2. 02
    Put each item in exactly one box.

    Core, Platform, Bloat, No-Go. No hybrids, no "sort of both."

    Principle Bloat is rarely born; it accumulates. It is yesterday's Core, or a hope that was never Core.

  3. 03
    Watch the arguments during sorting.

    Where the room cannot agree which box something belongs in, that is where the risk lives. The disagreement is the finding.

    Principle The tell for Bloat is fear. If the team keeps something because nobody is sure what breaks, that is the box it belongs in.

  4. 04
    Keep the No-Go list written and visible.

    It is the item most likely to be skipped, and the one that pays back the most.

    Principle A No-Go you did not write down will be built by accident.

  5. 05
    Re-sort on a cadence.

    Quarterly is enough. Track what moved since last time. Drift toward Bloat is expected. Catch it early.

    Principle Sorting is a practice, not an audit. What you did not re-check stopped being what you thought it was.

  6. 06
    Remove deliberately.

    When something has become Bloat, cutting it is the work, not a cleanup task for later.

    Principle Removing beats adding. Subtraction compounds; addition just accumulates.

Where it lives

Same method, different subject. Same shapes, named.

Subjects it sorts
Roadmaps Architecture Teams Meetings Ownership Features AI Hiring Processes Metrics Technology
Shapes we name
Core Drift

The label stays. The value has moved.

The Tell

Kept because nobody knows what breaks if it goes. That is the box.

Load-Bearing Fear

What holds Bloat in place. Fear, not function.

Platform Mismatch

Built for the business you were. Running the one you became.

Unwritten No-Go

Never made it onto paper. Every new hire proposes it. Gets built by accident.

The Missing Question

The one nobody asked before the expensive decision got made.

The easiest test. One question per box:

  • Core. Look at your current roadmap. Which three items are actually Core?
  • Bloat. What is one feature your team is afraid to remove?
  • Platform. What is one platform decision you have not questioned in two years?
  • No-Go. What are you deliberately not building?

If any of these take more than a minute, you have already found something worth sorting.

Everything starts as Core.
Everything can become Bloat.
Why this exists

The distinction I kept arriving at.

I did not build Core and Bloat in a meeting room. Every hard problem I looked at over three decades eventually reduced to the same split. Something that still created value, and everything that had accumulated around it. Once that split had a name, the same meetings started ending differently.

Most of the real thinking happened before the traffic starts, or from a corner table with a flat white going cold next to the laptop. This is what stayed after everything else I tried and failed with.

A No-Go you did not write down
will be built by accident.
The fifth principle
Applying Core and Bloat

How it gets used, in practice.

Knowing the framework is not the difficult part. Applying it objectively inside your own company is. Everyone in the room has a stake in what stays Core, in whose feature stopped being Core last quarter, in which platform decision quietly turned into a liability. That is where an outside pair of eyes earns its keep.

Let's see whether this is worth talking about.

One conversation. Founder-led teams, pre-seed to Series B, are where I fit best — ask either way. If I am not the right person for your situation, I will tell you directly.

Advisor

Monthly retainer. A sparring partner for the decisions the room cannot yet decide. We talk on a rhythm that fits your situation, usually a call each month with async access between them. There is no bulk version. I take a small number of these at a time, because the value is in the attention. If the fit is right, we start small and see what it becomes.

Start a conversation
Fractional CTO

When a monthly conversation is not enough. Someone in the room with the team, in the work, applying Core and Bloat inside the engagement itself. Defined period, in the seat, not in slides.

See if this could fit
The newsletter

Field notes from real product decisions.

Each issue takes one real product decision. A roadmap review, an architecture crisis, a hiring reorg. It runs the decision through Core, Platform, Bloat, and No-Go. See where the other team missed it. Learn to see it earlier in your own.

If you have ever left a planning session with the quiet sense that the room agreed on the wrong thing, and you could not name why. This is written for you.

Read what comes next. Learn to see the same patterns in your own systems. One click, one issue at a time.

Once you start seeing Core and Bloat,
you can't stop seeing it.
Fair warning.