Adding Features to an Old App: Outsourcer Says It Needs a Rewrite and Double the Cost — Is It Worth It?

Adding features to an old app, the outsourcer says major changes require a rewrite and double the cost — is it worth it? Conclusion: in most cases, a one-time rewrite is not necessary. Following 2026 project delivery practices, first conduct a technical audit, then decide whether to do incremental development, module refactoring, or a full rewrite. Hard-modifying messy code will cause continuous rework, while blindly rewriting risks losing existing user data and business momentum; a reliable quote should be based on code inspection, not guesswork.

Why adding features to an old app becomes a "rewrite vs. modify code" issue

Two to three years after an app launches, new requirements often involve existing basic modules such as login, payment, push notifications, and analytics. If the early code lacks layering and page logic is mixed with business logic, then every new feature may expand the test scope from a single page to the entire main flow.

According to 2026 project delivery practices, teams care about "will changing one button affect others?" When code coupling is high, the cost of adding features is much higher than expected. The temptation of rewriting is the ability to start over, but the cost of rewriting is not only in the development phase; it also includes data migration, user habit transitions, and operational coordination.

Here, "rewrite" can mean a full rewrite or a phased replacement. Many teams rewrite a single module while keeping other old modules; this approach reduces switching risk and gradually pays off technical debt.

• For an old app with high code coupling, adding a feature may trigger regressions across multiple modules, often making rework costs exceed directly rewriting a specific module.
• Rewriting is not starting from zero; existing data dictionaries, business processes, and UI control specifications can be reused, just need to be re-implemented under a new architecture.

Start with a technical inspection: The four-layer cross-check method

To determine whether an old app can be modified directly, you cannot just look at the requirements description. It is recommended to use the following "four-layer cross-check method" to check item by item, with each layer corresponding to specific acceptance criteria.

1. Architecture and code quality: Check whether it is modular, whether automated tests exist, and whether version control is in use. If the code lacks layering and logic is written directly into pages, incremental development poses high regression risk. Qualified code should at least separate network, business, and UI.
2. Coupling between new requirements and existing functionality: Is the new feature an independent module, or does it affect core transaction paths? Higher coupling means larger change volume and test scope. During requirements review, draw the change path; the more modules are affected, the more it leans toward partial refactoring.
3. Team and tech stack fit: Are there still people familiar with the original tech stack (native, cross-platform, etc.)? If no one can modify the original tech stack, or the outsourcer doesn't understand the existing code, the case for a rewrite becomes stronger.
4. Time window and data migration: Can the new feature be released in phases? Data migration is the most underestimated aspect during a rewrite. Migration scripts, validation logic, and rollback plans must all be tested in advance.

Why this division? Because these four layers correspond to key variables in cost, risk, manpower, and release path. After each layer check, ask the outsourcer to submit a written evaluation, not just a verbal quote.

Cost comparison between direct modification and rewrite (experience range)

Costs cannot be guessed; here are common experience ranges. Note: specific prices and timelines will vary based on requirement complexity, original code quality, and delivery standards, and do not constitute a quote commitment.

• Direct modification (incremental development): Suitable for cases where changes are contained and code is maintainable. Small features commonly quote 10,000–30,000 RMB, with a timeline of 1–2 weeks; medium features 30,000–80,000 RMB, 2–5 weeks; cross-module changes may require 80,000–150,000 RMB, 1–2 months.
• Rewrite: Can be done in phases; a single module replacement is about 50,000–150,000 RMB; a full rewrite commonly ranges from 200,000–600,000 RMB or higher, usually taking 3–6 months or more.
• Risk dimension: Direct modification carries higher online regression risk, but rewrite also involves data migration and business switch risks.

"Partial refactoring" is often more cost-effective than a full rewrite. Based on experience, first split out a core module for transformation; the cost is about one-third of a full rewrite, yet the risk can be controlled within an acceptable range. A common scenario: a client brings old code to discuss new features, and in the first meeting only mentions adding a points module, but during evaluation it turns out that changing existing APIs would affect the user center and customer service systems. Finally, a phased transformation approach is chosen: modify the underlying APIs first, then add the points module. The overall timeline was extended by three weeks compared to the original plan, but it avoided points mismatch issues after launch.

• If the budget is tight and the timeline is short, but the feature is a new independent module, prioritize direct modification.
• If the original architecture can no longer support the requirements, or multiple core modules need refactoring, consider a phased rewrite.

Common pitfalls and reminders at the delivery site

Non-functional requirements beyond functional ones are often overlooked, such as API response time, concurrency, and old version compatibility. These are not written into product prototypes, but they surface under load testing after launch.

• Only discussing features, not performance: If the new feature involves large volumes of data, direct modification may slow down startup. It is recommended to add performance baseline tests to the acceptance checklist.
• Outsourcer quotes without code audit: According to common practices in 2026, reputable teams will require a code review or on-site evaluation first, with costs billed separately or deducted from future fees. Be wary of those who quote a total price upfront.
• No one takes responsibility for data migration during rewrite: Rewriting is not just redrawing pages; existing user points, orders, favorites records all need migration. Migration scripts must be validated in advance, otherwise data may not reconcile after launch.
• Ignoring Android and iOS compatibility boundaries: WebView behaves differently on older system versions; new features may show a blank screen on old devices. Compatibility testing should cover mainstream older device models.

Applicable scenarios and boundaries

Direct modification is suitable for: small incremental features, modular original architecture, stable business mainline, and a team that can maintain the original tech stack. Rewriting is suitable for: original code with no documentation and severe coupling, outdated tech stack, major adjustment in business direction, or a foundation requiring long-term iteration.

The boundary is clear: if you just add an export button, change copy, or adjust styles, direct modification is enough — rewriting is not even relevant. Conversely, if the core process logic is so chaotic that no one can explain it, don't force modifications; rewriting may be a constraint.

FAQ

Is direct modification of an old app always more time-saving?

Not necessarily. It is indeed time-saving when the changes are small and the code is well-structured, but if the change affects multiple modules, testing and rework time may exceed rewriting the corresponding modules. Do a technical audit first, then decide.

If the outsourcer recommends a rewrite, does that always mean they want more money?

No, but you should ask for a code audit and specific reasons for the rewrite, such as the architecture being unable to support the requirements or the original tech stack no longer being maintained. If they just say "the changes are too big" without a detailed analysis, be cautious.

How is existing user data migrated after a rewrite?

The rewrite plan must include a data migration and validation plan. The common approach is offline migration plus gray validation. Migration scripts must be tested in advance, otherwise data may be lost or fail to reconcile.

For a small business that only has an app, is it necessary to redevelop it from scratch?

If the app's core flow is stable and you just add features, a rewrite is unnecessary. Consider modular replacement of parts, such as extracting and upgrading the payment module separately.

How can you tell if the original code can still be modified?

Look at three points: whether it is modular, whether automated tests exist, and the completeness of documentation and comments. If these three are lacking, the risk of modification is high; you can ask the outsourcer to do a small trial modification to verify the cost before evaluating.

Before acting, ask the outsourcer to provide a technical audit list, then decide based on quotes and timeline. Businesses suitable for small, fast iterations should prioritize incremental development; if the original code is no longer maintainable or the business direction changes significantly, consider a phased rewrite. The boundary is: the larger the change scope, the more you need to first solve the "can it be modified" question.