Why Adding a New Feature to Existing Software Sometimes Costs More Than Rewriting It

A founder came to me recently wanting to add a 'simple' feature to their existing CRM — a loyalty-points field on the customer record, with an automatic discount rule tied to it. They got quotes from three different dev teams. All three came in higher than what it would cost to write a small module of similar size from scratch. The founder's reaction was familiar: 'How can something this small cost this much?' This is one of the most misunderstood things in software development: why adding a new feature sometimes costs more than rewriting from scratch — and the reason isn't laziness or overpricing, it's a pretty logical piece of engineering reality.

##Why does adding a feature feel so counterintuitive?

When you write something from scratch, you're not at risk of breaking anything. You start on a blank page, pick whatever data model you want, choose whatever library you want, and the only thing you need to test is the code you just wrote. Adding a feature to an existing system is the opposite: every line interacts with hundreds of assumptions baked into the code that were never written down anywhere. Adding a 'loyalty points' field looks like a simple migration — until you realize the reporting screen reads that field, three different integrations (POS, e-commerce, accounting) write to it, and an old invoice-calculation function never considered that the field could be null. Suddenly 'add one field' turns into a week of regression testing. The developer writing from scratch never deals with these assumptions; the developer touching an existing system has to find them first, then work around them safely.

##What actually drives the cost: dependencies and invisible work

The real cost of a feature isn't measured by how many lines of code you write — it's measured by how many places those lines connect to. That connectedness is usually called coupling, and it accumulates over years: every shortcut, every 'let's solve this properly later' decision, every deploy that shipped without a test adds one more layer to the cost of some future feature. The invisible work usually hides under these headings:

• ▸Data migration: deciding what happens to the new field on old records — a default value, a backfill, or manual correction
• ▸Test coverage: if existing tests don't cover the area, every change ships with 'did I break something?' uncertainty
• ▸Integration impact: re-verifying the behavior of every external system (payments, accounting, e-commerce) the feature touches
• ▸Performance: a new query or field can slow down a table that's already under load
• ▸Team memory: if the person who wrote the original logic has left, understanding it becomes a research project on its own
• ▸Backward compatibility: not breaking the flow for existing customers who don't use the new feature

##A real scenario: adding a 'simple' feature to a booking SaaS

Say you run an appointment/booking SaaS with about 40 small-business customers, and the product has been live for three years. One customer asks for 'staff selection' — letting the client pick which staff member they want when booking. Sounds small: a dropdown, a foreign key. But once you look at the code, the booking table was built three years ago on the assumption 'every booking belongs to a business, there's no concept of staff.' The availability calculation runs per business, not per staff member. The notification system emails 'a booking came in for the business,' not 'for this staff member.' The reporting screen shows revenue per business with no staff breakdown. The calendar integration (Google Calendar sync) writes to a single business calendar.

At this point the dev team faces two options. First: bring staff into the system as a real data model — changes to booking, availability, notifications, reporting, and calendar sync, plus a backward data migration (assigning a 'default staff member' to the existing 40 customers' bookings), plus regression testing every one of those flows. That's easily three to four weeks of work. Second: bolt the feature on superficially — just show the dropdown without wiring up the real logic underneath. That takes a week, but six months later it comes back as a separate request — 'why is staff-level reporting wrong' — and by then the cost has effectively doubled. That's exactly the gap the founder saw in the quotes: the 'simple feature' price was really the price of three to four weeks of hidden engineering work.

##How to make the cost predictable

You can't drive this cost to zero, but you can make it visible and predictable. An experienced team doesn't skip these steps before quoting:

• ▸Map every table and function the feature touches (codebase search, dependency graph)
• ▸Check whether existing tests cover that area — if not, add the cost of writing tests first to the quote
• ▸Make the data migration scenario concrete: what happens to old records, and who signs off on it
• ▸Ask the owners of each integration (payment provider, accounting system, etc.) what the change means for them
• ▸Write out, explicitly, the difference between the superficial fix and the durable one — and its future bill

Quotes that skip these steps usually end up either priced too low (and the project drags on half-finished) or the customer is blindsided asking 'why is this so expensive.' Both cost trust. A transparent cost breakdown — 'this part takes 3 days, this part takes 5, because we also have to update these three systems' — is usually more convincing than the price tag itself.

To make this concrete: in the booking SaaS scenario above, once the team broke the quote into line items, it looked something like this — 5 days for the data model change and migration, 6 days to make availability calculation staff-aware, 4 days to update notifications and reporting screens, 3 days to move calendar sync to per-staff, and 3 days of regression testing across every flow. Twenty-one working days total — close to four weeks. When the customer sees that breakdown, they understand where the price came from instead of just seeing a number next to a 'simple feature' request — and they usually don't push back, because the figure isn't pulled out of thin air, it comes from a real line-item breakdown.

##When does rewriting from scratch genuinely cost less?

None of the above means 'always add, never rewrite.' At some point, accumulated coupling gets heavy enough that building on top of it really does cost more than starting over. The usual signals: every small change needs sign-off from multiple teams; features of the same size keep taking longer over time (the clearest sign technical debt is growing); the original architectural assumption (say, 'every customer belongs to exactly one business') no longer matches how the business actually works; and nobody left on the team really understands the code, so every change turns into archaeology. At that point, 'small feature' quotes really do start ballooning — and that's the signal it's time to consider a rewrite, usually not all at once but piece by piece, isolating and rewriting one module at a time.

A more concrete version of this: picture an inventory system built three years ago on a 'single location' assumption. In year one, adding a new report took 2 days. In year two, once the business added more locations, a report of the same size started taking 5 days, because every query had to be rewritten with a location filter. By year three it was up to 9 days, because reporting, inventory sync, and invoicing logic had become so tangled that a single change touched three modules at once. That curve — the same-sized work steadily taking longer — is exactly the signal that tells a team it's cheaper to rewrite the core module than to keep building on top of it.

• ▸Features of the same size take more than 2x as long as they did a year ago
• ▸A new developer needs weeks just to get their bearings in the code
• ▸The core data model no longer reflects how the business actually works (e.g. single-location to multi-location)
• ▸Writing tests has become harder than writing the code itself
• ▸Every deploy carries a team-wide fear of 'did this break something somewhere'

##FAQ

>How do I tell if a feature quote is realistic?

A good quote breaks the work into pieces and explains why each piece takes as long as it does — how many systems it touches, whether there's a data migration, what the test coverage looks like. A one-line 'X days' quote usually either means a superficial fix or a hidden risk of a surprise bill later.

>How does a project on a small budget avoid falling into this trap later?

The most effective approach is writing tests from day one and not locking the data model into unnecessarily narrow assumptions — for example, not hardcoding 'single location for now' so tightly that it's baked into every query. That means moving a bit slower at the start, but it substantially lowers the cost of a 'simple' feature two years down the line.

>When does it make more sense to build a separate module/microservice instead of adding to the existing software?

If the feature fundamentally conflicts with the existing system's data model — say, a real-time inventory sync being bolted onto a system built for batch jobs — writing it as a separate service that talks to the existing system over an API can be both faster and safer. But that brings its own complexity (keeping two systems in sync), so it should be the exception, not the default.

>What questions should I ask when I get a quote like this?

Worth asking: which tables/services does this feature touch, do existing tests cover that area (and if not, is writing them included in the quote), what happens to old records for this field, and does this change affect any other integration (payments, accounting, e-commerce). If the answers are specific and concrete, the quote is probably realistic. If the answers are vague reassurances like 'don't worry, we'll handle it,' the risk of a surprise bill later is high.

When you get a feature quote, it's worth looking past the price itself to where it comes from — which systems it touches, whether there's a data migration, what the test coverage looks like. If you'd like to walk through a quote like that together, feel free to reach out.