Custom App Development: Where's the Line Between Charging Extra and Working for Free When Requirements Change Mid-Project?

When requirements change mid-development, the decision to charge extra or work for free comes down to one criterion: whether the change exceeds the confirmed functional boundaries and requires additional developer effort. Based on common project delivery practices in 2026, changes to features already specified in the prototype or requirements document, as well as bug fixes and ambiguity resolution, should be handled free of charge. Anything not previously documented, requiring new pages or new logic, should be billed as an additional item. Most disputes between clients and outsourcing teams arise because this line was not clearly defined before work began.

Why "Requirement Changes" Always Turn Into a Money Issue

Mobile app development is delivered in phases. Once the prototype is confirmed, UI design, API integration, and test cases are all aligned to the current version. A seemingly small change, such as adding a "coupon entry" on the checkout page, can involve front-end pages, back-end APIs, database fields, and analytics tracking. The development cost is far more than the few visible hours. Experience shows that for a small-to-medium app project with a budget of 100,000-300,000 RMB, rework caused by requirement misunderstandings often consumes 15%-30% of the total budget. That's why outsourcing teams are sensitive to changes, while clients often misjudge: "It's just a button—why charge extra?"

It should be clear that requirement changes themselves are not the problem. The real issue is the lack of defined responsibility and cost boundaries. If who decides, who confirms, and who bears the cost are agreed upon at the start, friction later is greatly reduced.

First Classify: Three Types of Changes Have Completely Different Billing Logic

To determine whether to charge, start by classifying the change. Based on common delivery practices, changes fall into three categories:

• New feature addition: Modules, pages, or APIs not in the prototype, such as adding third-party login when only registration existed. These clearly exceed the baseline and are quoted as additional items, with extra cost and delayed timeline.
• Logic adjustment to existing features: For example, changing a list to cards or adding a step to the registration flow. This requires code and test changes. Billed based on estimated effort, usually cheaper than new additions.
• Clarification and correction: The prototype was clear but the developer misunderstood; documentation ambiguity caused implementation deviations; API integration errors—these are the developer's responsibility and are fixed free of charge without extending the overall timeline.

Note: The boundary between the second and third categories can sometimes blur. The test is: "Would a normal person misinterpret the prototype?" If the prototype specified exact copy and navigation and the developer got it wrong, it's the developer's fault. If the prototype only showed wireframes without logic, the developer proceeded based on common sense, and the client later requests something different, that's a logic adjustment.

Three-Step Verification for Change Settlement

We recommend following these three steps when changes arise to avoid most disputes.

1. Step 1: Pull out the requirement baseline. Find the prototype, requirements document, and confirmed PRD. If there's no written record, use the last confirmed chat messages plus the prototype. This step determines "what exactly changed."
2. Step 2: Assess the impact scope. Determine if the change affects the database, back-end APIs, front-end pages, or test cases. Estimate by hours. Industry experience suggests a page-level new feature typically adds 3-10 working days. Changes limited to copy, colors, or minor tweaks that can be done within half a day and have no testing impact are usually not billed separately.
3. Step 3: Confirm a change order with both parties. In a group chat or supplementary agreement, clearly state: change content, estimated hours, cost, new schedule, and acceptance criteria. This prevents endless oral back-and-forth.

Why divide it this way? Because the common pitfall in requirement changes is "unclear description." Step 1 prevents "I thought you meant something else," Step 2 gives both sides a clear cost picture, and Step 3 solidifies the conclusion. In our team's project deliveries, every change order requires a mention of the client's project lead in the group chat for confirmation, with screenshots of the expected effect; otherwise, it doesn't enter the schedule. This ensures evidence in case of disputes, rather than relying on memory.

A common scenario: A client, two weeks into development, asks to change login from phone number to WeChat authorization. The UI and API are already built; forcing the change would invalidate the existing user system. We chose to break it into an independent task, keeping the original phone login, launching first, then iterating. The cost increased by about 15%-25%, avoiding a full rebuild. This corresponds exactly to Step 2—assessing impact scope. It's not that it can't be changed; it's about changing gradually and effectively.

Options Comparison: Paid Change, Free Change, or Cut the Requirement

Once the change is classified, the real decision comes. Compare the three options:

• Paid change: Suitable when the change is strongly tied to core business processes and brings clear commercial value. The cost is a higher budget and longer timeline. Experience shows that additional fees typically range from 10%-30% of the total contract value, with a 2-4 week schedule extension.
• Free change: Suitable for clarifications, corrections, or micro-adjustments with less than 1 working day of effort, e.g., button position, copy tweaks, or fixing a mistake. Free fixes maintain the relationship, but too many can affect delivery rhythm.
• Cut the requirement: If the change would impact existing architecture or cause severe delays, it's better to cut it. Especially for an MVP (Minimum Viable Product), cutting peripheral features to preserve the core path and iterating later carries lower risk.

The key comparison is: "Does this change make the product better" or "Must it be done now"? The former can wait for phase two; the latter requires evaluating extra fees. If it's an existing defect, fix it free. After weighing, most clients accept launching first and iterating later.

FAQ

How much extra does it cost to add a "Share to WeChat Moments" feature?

For a sharing feature, based on common 2026 practices, integrating the WeChat SDK, adding buttons, and analytics takes about 2-5 working days. The cost typically ranges from a few thousand RMB to 10,000-20,000 RMB, depending on whether the existing code already includes a sharing module.

If the feature is built but doesn't achieve the expected result, and I ask for adjustments, is that a change?

If the implementation differs from the prototype's UI and logic, it's the developer's rework and should be adjusted free of charge. If the prototype itself was vague and the two parties understood it differently, it counts as a change. You can negotiate one free adjustment or bill it as an additional item.

Our contract doesn't have a change clause. Can we still request extra payment?

Yes. As long as you can prove the change exceeds the original requirements document or prototype scope, the developer has the right to request additional budget and timeline. But oral agreements are easy to dispute. It's recommended to send a group chat message on the spot: "This is an addition, estimated X days and Y yuan, please confirm."

If requirement changes cause a delay in launch, whose fault is it?

If the change order confirmed a new schedule, that schedule is followed, and the delay is not the developer's fault. If the developer made changes without notifying the client and caused a delay, the responsibility lies with the developer. So always communicate the new schedule with each change.

Applicable Scenarios and Boundaries

The above change settlement method suits projects with well-defined requirements documents, confirmed prototypes, and a clear client contact person. For collaborations where requirements are extremely vague at the start, or even change every two days, using change orders can lead to frequent negotiations and slow progress. In such cases, it's better to create a complete prototype before development to front-load the cost of changes.

Also note: if your app is data-storage-oriented or highly compliant (e.g., involving payments or healthcare), any changes often involve qualification reviews, so change costs rise significantly. The flexible "launch first, iterate later" strategy is not recommended.

In summary, requirement changes themselves are not scary; what's scary is having no baseline and no change orders. As long as the baseline is clearly confirmed, costs and timelines can be negotiated.

Action suggestion: Before development begins, agree with the outsourcing team on a "Requirements Change and Fee Agreement" that states: "Anything beyond the prototype scope is considered an addition and billed per person-day." During development, archive every change via group chat and screenshots. Based on 2026 delivery practices, this is a relatively hassle-free approach. If your requirements are still in the verbal stage, don't rush into development—solidify the prototype first. This method does not apply to exploration-stage projects where requirements are unsettled and direction changes frequently; in that case, a weekly-billing agile collaboration is more suitable.