MadeCurious has built, supports and maintains a significant number of large applications with 10-15 year+ useful lives. When you work across the whole of the Software Development Lifecycle in this way, you become deeply aware that every stage of a digital product affects the next one.
That’s why we’ve put together a series: The Long View - linking up the full shape of a system's life from the decisions made before build, through the pressures of delivery, to the ongoing care that keeps a system valuable.
See here for Part 1: De-risking Before the Build
This article looks at Part 2: The Feature Pressure Problem
See here for Part 3: Why Software Maintenance Deserves Your Attention
________________________________________________________________
The Feature Pressure Problem
The pressure to keep shipping features is real. So is the debt it creates. This article is about what happens during delivery and what it costs later.
Key takeaways:
- Every software feature adds long-term complexity to a system
- Shipping features under pressure often leads to technical debt
- Over-specifying requirements reduces developer judgement
- Technical debt accumulates and increases maintenance costs
- Strong teams protect architecture, testing and refactoring even under delivery pressure
________________________________________________________________
Every feature you ship has two costs.
The first is visible: the design time, the sprint capacity, the testing, the release. It gets estimated, budgeted, and felt. Teams know what it costs to build a feature because they live through it.
The second cost is quieter. It's the ongoing weight of carrying that feature, the surface area it adds to the system, the edge cases it creates for the next feature to navigate, the complexity that accumulates in the codebase over time. Nobody estimates this. It rarely appears in a business case. But it shows up, eventually, in every project that's been running long enough: slower delivery, harder releases, a team that seems to be working harder for diminishing returns.
This is the feature pressure problem - when teams are pushed to keep shipping new features, without accounting for the long-term complexity those features add to a system. Over time this creates technical debt, slows delivery and increases maintenance costs. Not that organisations shouldn’t want features - of course they should - but that the drive to keep shipping them often crowds out the thinking that would make the whole system more valuable in the long run.
How over-specification makes software delivery harder
When a feature request arrives, there's a natural impulse to define it completely before handing it to the team. Write down every screen. Specify every field. Anticipate every state. Lock it down so nothing is left to chance.
This feels like rigour. Often it's the opposite.
When requirements are defined too tightly, too early, something specific happens: developers stop making decisions and start executing instructions. The problem is that good developers make dozens of small judgement calls inside any feature. How to structure the data, where to draw this boundary, what to handle gracefully and what to surface as an error. Those decisions are almost always better when they're made in context, by the people doing the work, at the moment the tradeoffs are visible.
Pre-specified requirements made before implementation begins are made with less information than will exist during implementation. They lock in answers to questions that haven't been fully understood yet.
There's a subtler cost too. A requirement that's been written down feels like a commitment. Teams become reluctant to push back even when build reveals that the requirement was based on a misunderstanding, or that a simpler approach would solve the actual problem better. The spec creates its own momentum, and the momentum can be harder to stop than the original decision was to make.
This is particularly worth sitting with in an AI-assisted world, because AI makes the over-specification problem worse before it makes it better. Give a language model a feature brief and it will return detailed acceptance criteria, exhaustive edge cases, a full breakdown of sub-tasks confidently, quickly, and with no sense of whether any of it should actually be built.
AI is exceptionally good at generating more. It has no mechanism for the question that matters most in feature work: should we?
That judgement of what not to build, which requirement to challenge, where a simpler solution is actually better is a distinctly human contribution. It requires understanding the business context, the users, the existing system, and the long-term cost of carrying what gets built. Joshua Vial, one of our Directors and a key hand in our AI capability programme frames this beautifully ”the true value isn't in what AI can produce, it's in the thinking that decides what's worth producing in the first place”.
The alternative to over-specification isn't vague requirements. It's finding the right layer of definition: clear enough that everyone understands the problem to be solved, open enough that the people solving it can bring their best thinking to how and honest enough to say when the feature itself needs rethinking.
How feature pressure creates technical debt
The pressure to ship features is usually legitimate. Users need things. Business goals require things. There are genuine external drivers, competitors, regulatory timelines, stakeholder expectations. These things aren't going to wait for a clean codebase.
The problem isn't wanting to ship. It's what happens to decision quality when shipping is the only thing that's measured.
Under sustained delivery pressure, teams make compromises they know aren't ideal. Technical debt gets parked because there's no sprint capacity to address it. Tests get thin because the deadline is real and the test coverage is theoretical. Architectural concerns get deferred because raising them will slow things down. Each of these calls is defensible in isolation. Cumulatively, they produce a system that's increasingly expensive to change and the irony is that the feature pressure that created the shortcuts eventually causes the very thing it was trying to avoid. Delivery gets slower, because the system is harder to work in.
There's another dynamic worth naming. Feature pressure tends to compress the conversations that matter most. Discovery gets shortened. Stakeholder alignment sessions get skipped. The team moves to build before it fully understands the problem. And when reality arrives mid-delivery (we promise, it always does) there's no room to respond to it without something else giving way.
The projects we've seen struggle most aren't the ones with the hardest technical problems. They're the ones where the pressure to move meant the important questions were glossed over.
The maintenance bill arrives later
Steve Liew wrote about this from the other end of the timeline in “Why Software Maintenance Deserves Your Attention”. His core argument is that maintenance isn't optional, it’s only a question of when and how it's addressed. But it's worth tracing the line from cause to consequence a little more directly.
The maintenance burden on most long-running systems isn't random. It's a fairly legible record of the build decisions made under pressure.
Systems that were over-specified tend to carry features that are technically correct but architecturally awkward, solving the stated requirement in a way that doesn't quite fit how the rest of the system works, creating drag for everything built after them. Systems built under sustained feature pressure tend to have corners that were never cleaned up, dependencies that were never properly managed, test coverage that was always going to be addressed next sprint.
Over time, the cost of these decisions compounds. Fixing things that were built quickly under pressure requires understanding why they were built the way they were and that context is usually gone. The team that built it has moved on. The original reasoning wasn't documented. The feature made sense at the time, and now it's an obstacle.
This is what Steve means when he talks about technical debt as something that accumulates silently and surfaces at the worst possible moment. The pipe bursts at 3am not because pipes randomly fail, but because the pressure has been building for a long time.
A different kind of discipline
None of this is an argument against ambition, or for doing less. It's an argument for accounting honestly for the full cost of a feature decision, not just the sprint it takes to build it, but the ongoing weight of carrying it.
In practice, that changes a few things.
It changes how requirements are written. The goal is to describe the problem clearly enough that the team can solve it well, not to specify the solution so precisely that the team is executing rather than thinking. The acceptance criteria that matters is the one that tells a developer what a successful outcome looks like for the user … not the one that lists the SDK to use and the composables to create.
It changes how the backlog is read. Every unbuilt feature on a backlog represents future complexity that hasn't been committed to yet. Treating that as a neutral list of good intentions understates the weight of it. Some features, examined honestly, are worth that weight. Others quietly fall away when the full cost is on the table.
It changes what gets protected under pressure. The instinct when delivery is squeezed is to cut the things that feel theoretical. Time and again, there’s pressure to skip documentation, refactoring, revisiting that architectural conversation. These are usually the things that matter most for what comes next and the future pain of today’s gain is one we don’t like to pay! Holding ground on them is one of the most valuable things a delivery team can do, and one of the hardest to justify in the moment.
It changes the maintenance conversation. If the cost of a feature isn't just what it takes to build but what it takes to carry, then maintenance isn't a separate budget line that gets negotiated after go-live. It's part of the original investment decision. The organisations we've seen get the most value from their digital systems are the ones that understood this from the start and built accordingly.
The systems that age well aren't the ones that shipped the most features. They're the ones where someone, at each stage, asked whether the next thing was worth the weight it would add and had enough room to get the answer right.
That's a harder conversation to have in a sprint planning session than it sounds. But it's the conversation that separates a system that keeps delivering value from one that becomes an obstacle to it.
Build the right thing. Carry it carefully. Keep it right.
________________________________________________________________
Next in The Long View: Part 3: Why Software Maintenance Deserves Your Attention → The feature pressure problem doesn't end at go-live. It shows up later - in the systems that are slow to change, expensive to fix, and harder to love than they should be.
Previously in The Long View: Part 1: De-Risk Before the Build → how early assumptions and unclear problems create risk, and what teams can do to reduce it before build begins.
