A post on Zenn titled "[Failure Story] All That Remained After Massive Development Was Technical Debt: The Importance of Not Building" sparked widespread discussion. The core takeaway was a confession that building numerous unused features left behind heavy maintenance costs without generating actual business value. The crucial lesson is that the decision of what not to build impacts system lifespan and operational costs far more than the sheer ability to build.
In custom systems development, incidents such as "we built every requested feature, but half went unused and maintenance became overwhelming" or "we packed in everything requested, leading to schedule and budget overruns" happen constantly. When supporting systems through custom development, we view this not merely as checking off requirements, but as an architectural challenge: identifying what is truly needed, trimming excess, and handing over systems embedded within practical operations. Connecting with our previous articles on evaluating debt in Client projects: Refactoring decisions and technical debt governance in the AI era (GH Media), structuring requirements in Client projects: Specification and requirements harness design (GH Media), and designing adoption in Client projects: Test automation adoption support (GH Media), this article formalizes requirements and scope design support into a dedicated service package for client development.
Why design around what not to build now?
| Dimension | Building everything (overbuilding) | Building only what is necessary (2026) |
|---|---|---|
| Requirements | Included exactly as requested | Curated based on value |
| Scope | Expands without limits | Narrowed down progressively |
| Maintenance | Unused features must still be maintained | Maintenance surface minimized |
| Delivery schedule and budget | Prone to overruns | Easier to meet |
| Debt | Incurred as soon as development finishes | Generation minimized |
| Deliverable | Cumbersome burden | Continuously utilized |
In short, building everything is fundamentally different from generating value. Even in custom development, identifying what is truly needed, stripping away excesses, and embedding systems into operations before handover has become a core prerequisite for quality. This enables us to guarantee lightweight systems that remain continuously used as our deliverable.
Three structural changes beneficial to custom development projects
Structure 1: From "building as told" to "curating by value"
Implementing every request causes maintenance overhead to balloon. In custom development, we prioritize features based on value and usage frequency, and establish clear alignment on what not to build.
Structure 2: From "everything at once" to "phased releases"
Building everything in a single pass prevents meaningful validation. In custom development, we provide an architecture that launches with a minimal configuration to observe actual usage and scales based on real-world demand.
Structure 3: From "perfectionism" to "sunset planning"
Built features linger indefinitely. In custom development, we also design sunset criteria for retiring unused features, thereby preventing the accumulation of technical debt.
The 5 phases of requirements and scope design support for client projects
Phase 1: Clarifying value (1 week)
- Clarifying the problem to be solved and success metrics
- Identifying users and use cases
- Cataloging requests and interviewing stakeholders on background context
- Reviewing existing systems and alternative solutions
Phase 2: Scope design (1 week)
- Prioritizing requirements based on value and frequency
- Defining boundaries: build, don't build, and postpone
- Defining the minimum viable product (MVP)
- Setting criteria for sunsetting and re-evaluating features
Phase 3: Phased planning (1 week)
- Designing release phases and milestones
- Defining validation metrics for each phase
- Explicitly detailing risks and assumptions
- Reaching agreement on estimates and schedules
Phase 4: Implementation and validation (timeline based on project scale)
- Implementing the minimal configuration
- Monitoring usage metrics and operational data
- Deciding on expansion based on real demand
Phase 5: Ongoing operations (continuous)
- Re-evaluating unused features
- Regular scope auditing
- Monitoring debt accumulation
Standard technology stack set for custom development
| Layer | Recommended technology | Alternative |
|---|---|---|
| Defining requirements | User stories / issue breakdown | Feature list |
| Priority | Value × frequency matrix | MoSCoW |
| Verification | Usage tracking / feedback | Interviews |
| Phased delivery | Feature flags | Phased releases |
| Metrics | Adoption rate / success metrics | Analytics |
| Management | Scope ledger | Issue tracking tools |
Which projects need this and which do not
| Projects requiring this | Low-priority projects |
|---|---|
| Requests keep expanding out of control | Small scale with finalized specifications |
| Overbuilt in the past, resulting in heavy maintenance | Disposable, temporary systems |
| Tight schedules and budgets | Abundant resources available |
| Uncertain which features will actually be used | Usage patterns are fully determined |
| Intended for long-term operations | Short-lived and planned for decommission |
Six clauses to include in client contracts
| Clause | Details | What the client should verify |
|---|---|---|
| Target scope | Defining what to build and what not to build | Alignment on scope |
| Success metrics | How value is measured | Approval of metrics |
| Phases | Release plan | Milestones |
| Review | Sunset and expansion criteria | Decision Criteria |
| Handover | Procedures / runbook | Maintenance framework |
| Continuous operations | Scope auditing | Operating costs |
Client ROI projection (based on mid-sized enterprise business systems)
| Item | Existing (building everything) | Building only what is necessary | Difference |
|---|---|---|---|
| Initial development cost | Inflated by superfluous features | Compressed to only what is needed | Development cost reduction |
| Maintenance costs | All features maintained | Maintenance surface minimized | Maintenance cost reduction |
| Delivery schedule | Prone to overruns | Easier to meet | Risk reduction |
| Value realization | Delayed | Validated early | Early realization of value |
| Annual benefit | — | — | Reduced initial and maintenance costs by eliminating overbuilding |
Even if substantial upfront investment is required, avoiding the buildout and ongoing maintenance of unused features makes it fully justifiable.
Five common pitfalls
Pitfall 1: Implementing every single request
Maintenance balloons. Curate based on value.
Pitfall 2: Building everything at once
Validation fails, missing the mark. Release in phases and observe.
Pitfall 3: Failing to set sunset criteria
Features remain forever. Decide on sunset criteria upfront.
Pitfall 4: Not measuring usage
You cannot determine necessity. Track adoption rates.
Pitfall 5: Failing to articulate what not to build
Debates will resurface later. Document agreed decisions.
90-day action plan
| Week | Action |
|---|---|
| Week 1 | Organizing issues, success metrics, and requests |
| Week 2 | Designing scope using a value × frequency matrix |
| Week 3 | Agreeing on phased planning and sunset criteria |
| Week 4〜10 | Implementing the minimal configuration and observing usage |
| Week 11〜13 | Launching operational routines for expansion and review based on real demand |
Conclusion — Moving from building everything to building only what is necessary
What truly generates value is not the ability to build, but the judgment of what not to build. From our perspective of supporting systems through custom development, our requirements and scope design support, which identifies what is necessary, trims excess, and integrates systems into operations before handover, is a new flagship service for delivering lightweight systems that stay in active use, known as "Requirements and Scope Design Support."
If you are facing challenges such as "feature requests ballooning out of control," "systems overbuilt in the past causing heavy maintenance," or "a need to stay strictly within schedule and budget," please feel free to reach out via our inquiry form.
Sources
- "[Failure Story] All That Remained After Massive Development Was Technical Debt: The Importance of Not Building" (Zenn 2026-06-04)
- Client projects: Refactoring decisions and technical debt governance in the AI era (GH Media)
- Client projects: Specification and requirements harness design (GH Media)
- Client projects: Test automation adoption support (GH Media)
