The Simplify-This Protocol: A First Principles Framework for Killing Feature Creep

The first version of the Soul Notes spec had 30 components. Thirty. A note publishing system - conceptually one of the simpler features in a marketplace - somehow grew to include an RSS feed generator, dynamic OG image rendering, comment voting with sort-by-controversial, a recommendation algorithm, and a complete rebuild of the application's tab shell navigation.

None of these were bad ideas. That's the trap. Every one of them had a reasonable justification. RSS feeds are standard for publishing platforms. OG images drive social sharing. Comment voting improves signal-to-noise. Recommendations increase engagement. The tab shell needed updating anyway.

The Soul Notes spec went through the simplify-this protocol, and 10 of those 30 components were cut. What shipped was tighter, faster to build, and - here's the part that's hard to accept in the moment - better for the people using it.

The Protocol

The simplify-this protocol is a structured first-principles review applied to any spec, feature list, or system design. It runs one question against every element:

"Does this serve the person using it, or the person who built it?"

That's the razor. It sounds simple, and it is. The difficulty is being honest about the answer.

An RSS feed serves the person using it... theoretically. In practice, how many users of a marketplace for AI agent tools subscribe to RSS feeds? The honest answer: almost none. The RSS feed was in the spec because publishing platforms "should" have RSS feeds. It served the builder's sense of completeness, not the user's actual workflow.

OG image generation serves the person sharing a note on social media. That's real. But is it a launch requirement? The default OG image (site logo + title text) works for v1. Dynamic generation is a v2 optimization. It was in the spec because it's a satisfying technical problem, and satisfying technical problems have gravity.

Comment voting serves the person reading comments... when there are enough comments for signal-to-noise to matter. At launch, notes will have 0-5 comments. Voting on 3 comments is meaningless UI. It was in the spec because the builder (me) was designing for scale that doesn't exist yet.

What Got Cut and Why

Here's the actual cut list from the Soul Notes simplify-this pass:

Component	Justification for Inclusion	Why It Was Cut
RSS Feed	"Publishing platforms have RSS"	User research says zero demand. Build when someone asks.
OG Image Generation	Social sharing optimization	Default OG works for v1. Optimization before baseline.
Comment Votes	Signal-to-noise in discussions	No signal-to-noise problem at launch volume.
Recommendation Algorithm	"Users might like similar notes"	Zero notes exist. Can't recommend from nothing.
Tab Shell Rebuild	"While we're in here, let's fix..."	Scope creep classic. Separate ticket.
Markdown Preview Toggle	Live preview while writing	The editor already renders markdown. Preview of preview.
Note Templates	Pre-built templates for common formats	Users haven't written a single note. Templates for what?
Analytics Dashboard	View counts, read time, engagement	Premature metrics. Ship, then measure.
Draft Sharing	Share unpublished drafts via link	Edge case. Publish or don't.
Bookmark Collections	Organize saved notes into folders	Users haven't bookmarked anything yet.

Each cut follows one of three patterns:

1. Optimizing before baseline exists. OG images, analytics, recommendations. You can't optimize what doesn't exist yet.
2. Designing for scale at zero. Comment votes, bookmark collections. Building for 10,000 users when you have 10.
3. Scope creep through adjacency. Tab shell rebuild, draft sharing. Legitimate work that doesn't belong in this feature.

The AI Comprehensiveness Bias

Here's where it gets interesting for anyone working with AI agents on system design.

AI agents have a strong bias toward comprehensiveness. When you ask an agent to design a note publishing system, it will produce a thorough, well-considered spec that includes everything a mature note publishing system should have. RSS. OG images. Recommendations. Analytics. The agent isn't wrong - mature systems do have these features. The agent is wrong about timing.

This is a crucial distinction. The bias isn't toward bad features. It's toward complete feature sets when what you need is a minimal viable feature set. The agent's training data is full of finished products, not v1 launches. So when it generates a spec, it generates a finished-product spec.

The simplify-this protocol is specifically designed to counteract this bias. It doesn't ask "is this a good feature?" (the answer is almost always yes). It asks "does this serve the user right now?" That temporal qualifier - right now - is what separates a shippable spec from a roadmap disguised as a spec.

I've seen this play out in creative thinking workflows where the goal is divergent ideation: you want comprehensiveness during brainstorming, but you need a contraction phase before execution. The simplify-this protocol is that contraction phase. Similarly, when building proposals, the temptation is to include every possible feature to make the proposal impressive. The impressive proposal is the one that ships.

How to Run the Protocol

The simplify-this protocol has four steps:

Step 1: List every component, endpoint, and feature. Not from the spec document - from the actual implementation plan. What files will be created? What endpoints will be built? What UI elements will be rendered? Get concrete.

Step 2: Apply the razor to each item. "Does this serve the person using it, or the person who built it?" Be honest. If the answer requires qualifiers ("it serves the user once there are enough...", "it serves the user if they happen to..."), that's a soft no.

Step 3: Classify the survivors. Everything that passes the razor goes into one of two buckets: "must have for first use" or "enhances repeated use." Only "must have for first use" ships in v1.

Step 4: Check the cut list for dependencies. Sometimes you cut something that another surviving feature depends on. If the dependency is real, bring it back. If the surviving feature can work without it (even if degraded), leave it cut.

For Soul Notes, Step 1 produced 30 items. Step 2 eliminated 6 (RSS, OG images, recommendations, analytics, templates, markdown preview toggle). Step 3 moved 4 more to v2 (comment votes, bookmark collections, draft sharing, tab shell rebuild). Step 4 found no hard dependencies between cut items and survivors.

20 components shipped. 10 were deferred. The 20 that shipped were tighter, more cohesive, and easier to build correctly because there was less surface area for bugs.

The Hard Part: Letting Go of Good Ideas

The reason feature creep persists isn't that people add bad features. It's that they add good features at the wrong time. Every item on the cut list is a genuinely good idea. RSS feeds are good. Analytics are good. Recommendations are good.

But good ideas have a cost beyond their implementation time. Every additional component is:

• More surface area for bugs
• More code to maintain
• More cognitive load for the user
• More integration points that can break
• More things to test across browsers, dark mode, mobile, and screen readers

The simplify-this protocol doesn't kill ideas. It sequences them. The cut list becomes the v2 backlog. But it only becomes the v2 backlog after v1 ships and real users tell you which of those good ideas they actually want.

The best system is the one that exists and works. Not the one still being designed because someone (usually me) keeps adding one more good idea to the spec.

Results

20 components instead of 30. Shipped in an hour instead of three. Zero items on the cut list have been requested by users (granted, it's early). The system does what it needs to do and nothing more.

That's the simplify-this protocol. Apply the razor. Cut with confidence. Ship what serves the user. Add the rest when the user asks for it, not when the builder thinks of it.