What Does It Cost to Extend an Existing System? Three Quoting Methods

Two years in, the business changes, and the boss says: "Add a distribution module to this system, and rework the membership tiers while you're at it." You go back to the original vendor and get a price that seems unreasonably high. You don't know how that number was built, or whether to switch suppliers. This is a very common quotation scenario in custom software: not building from zero, but extending a system that is already running in production.

We take on a fair number of these second-phase requests, and a secondary development quote rarely resembles the arithmetic of a new build. Why secondary development is not cheap, where the money goes, and how to sanity-check a secondary development quote deserve their own explanation, because the arithmetic is completely different from "how much does it cost to build a new app".

Why extending an existing system costs more than building a new one

A new project starts from an empty directory: code, database, deployment environment are all fresh, and the vendor can organise the architecture however it prefers. Secondary development cannot. Every piece of work has to fit inside rules someone else already wrote. That introduces three cost items a greenfield project simply does not have:

• Code comprehension. A mid-sized system two years into production typically holds 50,000 to 200,000 lines of code, plus configuration files, database scripts, and third-party integration records. A developer must read it before changing it correctly. For a competent engineer working on unfamiliar code, that is usually three to ten working days — and longer if the stack is unfamiliar.
• Regression testing. A new project only needs its new features tested. Secondary development touches a live system, where any change can affect flows that already work. A single modification often requires regression across a dozen existing business paths. This is the workload buyers underestimate most consistently.
• Environment and coupling. The existing system may be wired into payments, SMS, hardware devices, or a third-party ERP. If the new feature reuses those integrations, the vendor first has to reproduce them in a test environment. That preparation sometimes takes longer than writing the feature itself.

Stack these three together and the counter-intuitive result becomes explicable: a request that looks like "just add a page" can quote at two to three times the cost of building the equivalent feature from scratch.

Three ways to price second-phase work

The industry quotes this work in three ways, each placing risk differently.

Function-point estimation. Break the requirement into countable function points, assign a unit price to each, then add fixed hours for code comprehension and regression. Suits cases with a clear boundary, such as "add a distribution commission calculation module" where inputs and outputs can be specified. The weakness: once the requirement is vague, the function-point count drifts.

Day-rate billing. Estimate total person-days and multiply by a daily rate. Suits changes whose scope genuinely cannot be pinned down until work starts. The risk is that person-days inflate, so the contract needs a day cap and a rule for overruns.

Module-based fixed price. Split the phase into independent modules, each with a total price, paid on module acceptance. Suits requirements mature enough to ship in stages. This is the most buyer-friendly structure, because the price risk on each module is capped.

When we take on a second-phase project, we usually lead with the third. We run a one-to-two week technical due diligence first — code quality, interface status, database structure — then quote module by module. The due diligence itself is chargeable, but it buys a price that will not balloon halfway through.

Five variables that move a secondary development quote

The same "add a distribution module" request can quote anywhere from 30,000 to 300,000 CNY. The spread on any secondary development quote comes from five variables.

Who built the original system. If the original vendor is still available, the quote is usually lowest because code comprehension cost is zero for them. If a new company takes over, someone must pay for that reading. This is the most common hidden cost of switching vendors mid-life.

Readability of the code. A project with comments, interface documentation, and deployment scripts is cheap to inherit. A project with no docs, inconsistent naming, and business logic buried in front-end pages can double the reading time. This is assessable at due diligence, and it is exactly why we advise buyers to require documentation delivery from the very first build.

Scope of database change. Adding new tables and new fields is controllable. Altering existing table structures, cleaning and migrating historical data, raises both risk and hours, and requires a scheduled downtime window.

Third-party interfaces and hardware. Payment channel changes, SMS template filing, hardware protocol integration all carry a block of external waiting time that cannot be compressed. Quotes for these should include margin for joint debugging and repeated testing.

Deployment method. A staged rollout with rollback and data backup costs more hours than "replace production directly" — and it is the money worth spending. An incident during secondary development costs far more than the extra development fee.

Six documents to prepare before asking for a quote

Eighty percent of distorted second-phase quotes come from information asymmetry: the vendor cannot see the system, so they guess from a description, and a guess needs a safety margin. Prepare these six items and accuracy improves noticeably:

• A feature list or user manual for the existing system, showing current modules and permission structure;
• A database schema export, at minimum covering core business tables;
• An interface inventory marking which endpoints are internal and which connect to external services;
• Technology stack notes: backend language and framework, frontend framework, database version, deployment method;
• Server and operations details: cloud provider, sizing, whether CI/CD exists;
• Acceptance criteria for the new work, written as "what counts as done" rather than "add a distribution module".

If the original vendor refuses to provide these, that is itself a signal. Source code, database schema, and interface documentation are deliverables a client is entitled to. Not having them means you do not truly control the system, and secondary development becomes a negotiation you cannot win.

Controlling the budget on a second-phase project

Cut the phase into small steps. Adding three modules at once is worse than shipping the most urgent one first. After the first module, you have a real read on the new vendor's delivery quality, responsiveness, and code standard — and the budget for the next two is easier to negotiate.

Specify what will not change. Beyond what is being built, the contract should state which modules and interfaces are out of scope. With the boundary fixed, the regression scope has a basis and the timeline becomes predictable.

Put backup and rollback into the delivery standard. This is not optional. The go-live risk of secondary development exceeds a greenfield build precisely because the data is real.

Treat warranty the same as a new project. Modified features that fail are still the vendor's responsibility. Warranty scope, start date, and response time should all be in writing.

Assess rebuilding from scratch. When the original code is poor, undocumented, and every change carries a heavy reading cost, the total spend on phase two can exceed a rebuild within three to five years. That calculation is worth doing — but on due diligence data, not on a feeling.

A practical test for a reasonable quote

Judge a second-phase quote not by the total, but by three things: does it explicitly break out code comprehension and regression hours; does it give module-level prices with acceptance boundaries; does it describe the deployment and rollback plan.

All three present means the vendor actually opened your system and the number has a basis. None present — just a lump sum — means the figure should be renegotiated regardless of whether it looks high or low. Our own practice is to write all three into the quote sheet. Clients do not need to read code; they only need to understand that "these eight days are for reading your existing system".

Adding features to a live system is building on someone else's foundation. The condition of that foundation determines the cost, so before arguing about price, let someone inspect the foundation properly. If you are currently scoping a rebuild or extension of an existing system, assemble the six documents above and we can return a module-level quote with a breakdown of hours.