# A Never-Build List Protects Product Identity ## Claim A focused tool stays focused only for as long as its declined capabilities remain explicitly off the roadmap, not merely absent from the current release. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds when users retain a dependable, low-friction route to the fuller tool for whatever the focused tool declines to do — the "never-build" list only works alongside a working handoff. - Breaks when a declined capability turns out to be required for the tool's actual core job, or when reimplementing one control to satisfy a vocal segment starts a pattern that erodes the boundary. - The article names the mechanism directly: every control a focused tool reimplements becomes a permanent maintenance obligation tracking the larger platform's next release, not a one-time cost. ## Evidence > [!quote] > Every control you reimplement becomes a permanent parity treadmill against the vendor's next release. Minn Admin's stated boundary — writing, not layout construction — only holds because the team maintains a list of things it will not build (nested layout canvases, pattern authoring, Full Site Editing) rather than treating each missing feature as an eventual backlog item. ## Links - [[Open Source Governance MOC]] — declining capability explicitly as a governance act, not merely a roadmap gap - [[3. Resources/Literature Notes/Gutenberg Is Huge for a Reason]] — source literature note, §H3 - [[3. Resources/Permanent Notes/Preservation Compatibility Differs From Editing Parity]] — because extends: declining to edit is the concrete form this scope discipline takes for unsupported markup - [[3. Resources/MOCs/Product & Startup Instincts MOC]] — applies-in: any smaller product positioned next to a dominant platform ## Tests / falsifiers - A focused tool that successfully absorbs a "never-build" capability without losing its identity or ballooning its maintenance surface — would show the boundary is negotiable rather than structural. - A focused tool that loses users specifically because a declined capability turned out to be core to the job it claimed to do — would show the boundary was drawn in the wrong place, not that boundaries don't matter. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [Gutenberg Is Huge for a Reason. That Does Not Mean Every Editor Has to Be.](3.%20Resources/Readwise/Articles/Gutenberg%20Is%20Huge%20for%20a%20Reason.%20That%20Does%20Not%20Mean%20Every%20Editor%20Has%20to%20Be..md) — states the writing-versus-layout split and the parity-treadmill cost of reimplementation.