The Mini Program Is Halfway Through Development and the Client Wants to Add Features, and the Developer Wants More Money—Should You Pay?

Conclusion first: If a custom mini program developer asks for more money when you add features halfway through development, it does not necessarily mean the original quote was a trap. The key is whether the new features are outside the original contract list, whether there is a written change order, and whether the quote has been recalculated based on workload and risk. Following typical 2026 project delivery practices, a moderately complex feature change usually increases the cost by 10%–30% above the original contract amount. If it is only text changes, style adjustments, or bug fixes, you generally should not be charged extra. What you need to do is not to refuse outright but to verify the basis for the price increase by checking scope, impact, and pricing basis.

Why Is There Usually an Extra Charge for Adding Features Mid-Development?

The foundation of a custom mini program quote is “feature breakdown + workload estimation.” Adding new requirements in the middle or later stages of development is not just about writing more code: requirement documents, UI design, API fields, permission checks, exception handling, and test cases may all need to be modified accordingly. Even already-accepted modules may need regression testing, and rework is often more expensive than writing a new module from scratch. Based on delivery experience, charging separately for new features is standard industry practice, not a targeted price hike for you.

What you should genuinely watch out for is when “minor tweaks” are disguised as new requirements. For example, moving a button or replacing notification copy—these low-risk changes should normally be classified as experience fine-tuning before acceptance or absorbed during the maintenance period. If you encounter such changes being charged extra, that is when you should pull out the contract and check every clause.

First Identify: Which Changes Deserve Extra Payment and Which Do Not?

The standard is simple: Does the change correspond to an item in the “original contract feature list”? Features listed but not implemented properly are delivery defects and should not cost you extra; new features outside the list are out-of-scope changes and can be negotiated financially. Below are two common sets of examples:

• Should not cost extra: Fixing bugs in already-accepted features, correcting differences between the UI and the design mockups, adapting to new versions of the operating system, and replacing similar notification copy.
• Usually should cost extra: Adding new roles or permissions, adding a payment channel, overhauling data statistics reports, adjusting multi-platform synchronization logic, and changing the database structure.

The common thread in the first group is “delivering the previously promised result,” while the second group is “generating new workload.” Distinguishing between these two will filter out half the confusing charges.

Use the Three-Question Check—Scope, Impact, and Pricing Basis—to Verify Whether the Price Increase Is Reasonable

When you receive a price increase notice, do not argue based on gut feeling. Instead, ask three questions:

1. Ask about scope: Is the new feature in the original contract feature list? If yes, the developer has omitted a deliverable and should provide it for free; if no, it is an out-of-scope addition.
2. Ask about impact: Will the new feature affect underlying structures such as payment, permissions, login, or database tables? If so, the price should not be based on UI only; regression testing costs must also be included.
3. Ask about pricing basis: Has the developer issued a formal requirement change order specifying the workload and cost? If only verbal quotes exist, always demand a written change description first.

According to project delivery experience, if all three questions point to “yes,” the price increase is likely justified. If the answer to the first question is “it is in scope” but they still want to charge, bring out the previous confirmation records for verification. This rule will not make changes free, but it will bring both parties back to the same document to negotiate.

Experience Range for Change Costs and Timelines: Negotiate with a Solid Baseline

The additional amount is not arbitrary. Based on typical 2026 delivery practices, change costs and timelines usually fall within the following ranges:

• Text, color, spacing, and other UI tweaks: Generally no charge, or included in the maintenance period.
• Adding a single page or a simple form: The contract amount increases by 5%–15%, and the timeline is extended by 3–7 calendar days.
• Changes involving payment, membership, multi-role permissions, or similar functions: The contract amount increases by 20%–30%, and the timeline is extended by 2–4 weeks.
• How much can be deducted if features are removed? The typical range is 5%–10% of the contract amount, but it is not a simple subtraction based on the feature list, because requirements analysis and architecture costs have already been incurred.

In addition to the amount, the written change order should also note whether the discount in the original quote still applies. If the developer charges full price for new features while the original order was discounted, you have the right to demand the same discount.

Four Practical Habits to Manage Change Effectively

Requirement changes are common; what matters is having a record. You do not need to do the technical work, but it is advisable to cooperate with the following four steps:

• Step 1: Write the new features into a change description, listing each affected old module and the acceptance criteria.
• Step 2: Ask the developer to estimate time and cost, and provide a cost range. The typical range is an increase of 5%–30%; anything beyond that should be explained in detail.
• Step 3: For UI-level changes, first update the prototype or a clear mockup to avoid the result not matching what you wanted.
• Step 4: After both parties confirm, attach the change order to the contract as the basis for acceptance and settlement.

Many disputes arise from the client saying “let’s add member points first” in a group chat, the developer starting work without completing the change order, and then both sides feeling they lost when the final bill arrives. Any change without a process will leave at least one party dissatisfied, no matter the final amount.

In Which Cases Can You Confidently Refuse to Pay Extra?

As long as you are paying for custom development, the developer is responsible for making the functions in the requirement document run properly. Program errors, page crashes, compatibility issues—these are quality responsibilities and should be fixed and re-tested for free. In 2026, mini program platform policies and review rules may still change. If platform-side changes cause old features to stop working, that is an adaptation cost and should not be directly turned into your requirement change fee.

But do not treat “new business goals” as bugs. For example, if the original was display-only and later you want to add member stored value or store-level permissions, such requirements generate new data fields and access rules, so the developer charging by workload is reasonable. When privacy interfaces or sharing components are involved, compliance and review risks must also be handled, which often leads to higher costs—you should understand this before confirming the feature.

Delivery Scene: A Post-Mortem of a “Failed Negotiation” Over Adding a Requirement

A retail project was near completion when the client requested adding a “parameterized sharing poster” for channel tracking. The constraints were that the budget was nearly exhausted, UI assets had no scheduled slot, and the poster also needed to be dynamically generated and stored. Based on our typical range, we estimated a 20% cost increase and a one-week timeline extension, and asked for a change order first. But the client’s marketing team wanted to show results to their leadership and urged in the group chat, “just start building it and we’ll see.” The developer started without written confirmation. At acceptance, the client argued it was “an optimization” and refused to pay the change fee. The two sides were stuck for two weeks. Finally, they removed two useless decorative features to offset the cost, and simplified the poster display scope, to get acceptance through.

In hindsight, the developer’s mistake was not insisting on “no change order, no work,” and the client’s mistake was substituting verbal pressure for requirement confirmation. In subsequent projects, whenever there was a verbal request involving cost or timeline, I would reply: “Sure, but I will send you the change order first; once confirmed, I will arrange it immediately.” This phrase can stop most “do first, report later” troubles before development begins.

Applicability and Boundaries

This three-question method and change order process are suitable for custom projects that have a clear feature list and acceptance criteria, especially those with many pages and a payment backend. When changes have a broad impact, aligning documents first can significantly reduce rework and disputes.

It is less applicable to pure template-based mini programs, because the feature switches are controlled by the platform, and “adding features” usually means upgrading a plan, rather than traditional hourly pricing. Very low-budget, three-to-five-page display sites can also be handled more lightly—you do not need to apply the full process; verbal confirmation plus a screenshot may be enough. What you should be especially wary of is if your contract has no feature list at all. Then the issue is not first “should you pay extra,” but rather “the contract does not yet constitute an executable definition.” You should clarify the original scope first, and then discuss changes.

Frequently Asked Questions

If I voluntarily remove a feature halfway through development, can I ask for a price reduction?

The amount you can save from removing a feature is limited. The typical range is between 5% and 10% of the original contract amount, because requirements analysis, prototyping, and foundational architecture costs have already been incurred, and you cannot simply subtract items from the list.

The developer verbally agreed to add it for free, but after the work was done, they asked for payment. What should I do?

Without a written or saved chat record, it is difficult to prove a promise of free work. In the future, always use a written change order for any change, or at least ask the developer to reiterate in chat that “this is not chargeable” and keep a screenshot before allowing the work to begin.

How should the change fee clause be written in the contract so it can be verified later?

A common approach is: if a single change is estimated to exceed 5% of the contract amount or 2 calendar days of estimated work, a supplementary agreement must be signed first; the unit price for changes follows the discount in the original quote, and the developer will not start development until written confirmation is given. Write that sentence in, and you will have a basis later.

How long will a new feature delay the launch?

It usually delays. A simple feature takes 3–7 days; a core module takes 2–4 weeks, depending on whether the underlying structure is changed. The extension should be written in the change order—you should not rely on a verbal assumption of “more work without more time.”

When you encounter a “price increase” in the middle or later stages of development, do not get angry immediately, and do not blindly refuse. Run it through the “scope, impact, and pricing basis” check, then use a change order to clearly document the cost, timeline, and acceptance criteria. The money should be spent transparently. What truly makes a project budget spiral out of control is not any single price increase, but every change that is never put in writing.