Custom Mobile Development: How Big Is a Requirement Change? When Do You Get Charged?

In custom mobile development, does every requirement change come with a fee? Based on delivery practices in 2026, the true dividing line is not the number of changes, but whether they touch data structures, API protocols, or core business rules. Changes that only affect visual elements like text, spacing, or icons are often adjusted for free by most development teams. However, when changes involve database schemas, API fields, login states, or payment flows, redesign, coding, and regression testing are all required—so charging extra is common. Below is a “three-layer change classification method” to help you see the boundaries clearly, followed by commonly overlooked costs.

Three-Layer Change Classification: First Determine Which Layer the Change Falls Into

Classifying requirement changes into three layers by impact scope is a quick framework for deciding whether to charge. This framework applies directly to custom mobile development projects. The key is not how much work there is, but whether the change crosses system boundaries.

1. Visual Layer: Button text, layout spacing, colors, icon replacements. No changes to code logic; static resource replacement is sufficient. Common practice is free, or at most a charge within 0.5 person-days.
2. Logic Layer: Front-end interaction rules, page navigation order, form validation, state handling. Requires code changes and self-testing. Billed per person-day, with a typical range of 1 to 5 person-days.
3. Data Layer: Database table structures, API fields, third-party services (payment, mapping, push notifications). This has the widest impact, affecting frontend, backend, database, and testing—all requiring rework. The cost ceiling is highest.

Why these three layers? Because the visual layer is like “changing clothes,” the logic layer is like “changing movements,” and the data layer is like “moving the skeleton.” Once the skeleton moves, every supporting part must be rechecked, and the cost jumps. When assessing, first ask: will this change cause database fields or API response content to change? If the answer is “yes,” it essentially falls under the data layer.

For example, moving the login button from the top right to the bottom is a visual-layer change, but changing the login method from SMS verification code to WeChat authorization crosses into the data layer because the user table, session logic, and third-party callbacks all need modification. Under the same keyword “login,” the difficulty difference is severalfold.

Why Is the Change So Expensive? Where Are the Main Costs?

Clients often wonder, “It’s just one field—why does it take so many days?” In reality, development costs go beyond writing code, covering design updates, self-testing, integration testing, regression testing, and documentation updates. Based on the average quotes from mobile development teams in 2026, a data-layer change often takes 2 to 3 times more effort than a logic-layer change, because the client, server, database, and test cases all need to be updated in sync.

A common real-world scenario: the client requests switching the push service from a vendor-specific channel to a third-party aggregation platform in the mid-to-late development phase, assuming it’s just a SDK swap. But in reality, message records, tagging system, statistics reports, and backend configuration all need changes, leading to two extra weeks of work. At least three parts are easily overlooked:

• Regression Testing: When one part changes, surrounding functionality needs revalidation—this is the most commonly overlooked cost.
• Third-Party Dependencies: Involving payment, QR scanning, or push notifications requires waiting for third-party platform review, which is time-unpredictable.
• Documentation Sync: API documentation, operation manuals, and acceptance checklists all need updating, otherwise operations will hit pitfalls after launch.

So when evaluating change costs, don’t just look at the visible function—ask: what else will change along with it? A requirement change often carries a chain of related changes.

How to Verify the Developer’s Change Quote?

After receiving a change quote, don’t rush to sign. Based on common delivery processes in 2026, you should check at least three things:

1. Review the breakdown: Ask the developer to list hours for “design – coding – testing – integration” rather than a lump sum. Typical ranges: visual-layer changes within 0.5 person-days, logic-layer 1 to 5 person-days, data-layer 3 to 10 person-days.
2. Check the person-day rate: Quotes can vary severalfold between teams. For mature outsourcing teams in first-tier cities, common person-day rates range from 1,500 to 5,000 CNY. If the changed total exceeds 15% of the original project budget, reassess whether the requirement is absolutely necessary now.
3. Review the change order content: Confirm that it specifies the impact scope, completion time, acceptance criteria, and the regression scope for existing features after the change. Verbal promises of “just a quick fix” are the most common source of disputes at delivery.

What counts as qualified? If the change order includes these four items—“impact scope + work hours + cost + regression test scope”—you basically won’t face surprise charges. If not, ask to add them before confirming. Additionally, it’s recommended to include the “change process” in the original contract, such as “any requirement change must be confirmed in writing; no development will proceed without confirmation.”

Applicable Scenarios and Boundaries for Common Requirement Changes

Requirement changes can be cheap sometimes, but there are also scenarios where a full redo is needed. The best phases for changes are the prototype phase and early development phase, when the data model isn’t finalized and changes are low-cost. Poor phases are late testing and the night before launch, especially when changes involve user account systems, payment flows, or core business rules—forcing them in increases delay and failure risks.

Below, we list scenarios by “worth changing” and “not recommended to change”:

• Worth changing: Visual-layer adjustments (e.g., changing the style of home screen icons), logic-layer tweaks (e.g., form validation rules with clearer prompts), and data-layer changes still in the prototype stage (before database tables are built).
• Not recommended to change: Logic-layer changes during testing (which require updating test cases, screenshots, and operation manuals, costing more than double the development phase), replacing third-party services just before launch (review cycles uncontrollable), or turning a single-device app into a multi-device sync system (essentially a new project).

Boundary statement: If a requirement change alters core flows or the data model, and the project is already in the testing phase, it’s usually recommended to launch the current version first and reschedule the change for the next iteration, rather than forcing it in. This controls risk while also avoiding a chain reaction of new bugs.

Action tip for you: Before development starts, agree with the developer on the change process, such as “verbal changes are invalid; must be confirmed in writing; if the impact scope exceeds 3 pages or involves database tables, treat it as a formal change.” This reduces surprise charges and rework. If you’re unsure whether a change falls into the paid category, simply ask the developer: “Will this change touch database fields or API fields?” After their answer, you’ll have a basis for judgment.

FAQ

How much extra is reasonable for a requirement change?

Based on experience range, a logic-layer change uses the same person-day rate as the original contract. Data-layer changes typically increase by 30% to 50%. Visual-layer changes are often free or billed half a day.

Do verbal requirement changes count?

No. In project delivery practice, requirement changes without written records cannot be traced later in development or acceptance, and are likely to be treated as out-of-scope work.

Can I change UI text after submission for review?

Yes, but the app package needs to be resubmitted for review. When app store review is involved, text changes also require re-review. It’s recommended to batch changes before resubmitting to avoid multiple submissions.

Will writing detailed requirements before development avoid extra charges later?

Not completely, but it can significantly reduce them. The more detailed the requirements document, the fewer overlooked changes. However, business itself evolves; what truly matters is agreeing on the change process.