Mini Program custom development: after the first free maintenance year, should I pay the second-year maintenance fee?

Should you pay the second-year maintenance fee? The answer is: check whether the contract clearly states "what's covered, response time, and what's not covered." If these three items are clear and your company has no dedicated technical staff, based on common experience in 2026, this money is usually worth spending. If the other party only says "contact us anytime if there's a problem," be careful—this money is likely just buying verbal comfort. The key to judging whether the maintenance fee is worthwhile is not the price, but whether the risk transfer is written into the contract.

1. What exactly does the maintenance fee buy? Don't rush to call it expensive

The maintenance fee is not a "service fee"; it's for handling three types of changes: compatibility adjustments due to WeChat platform rule updates, routine maintenance of servers and third-party APIs, and occasional bugs exposed only after users go live. Based on common experience in 2026, the annual maintenance fee is usually between 10% and 20% of the development cost, depending on feature complexity and response time.

Many clients treat "changing a button color" as maintenance, which is a misunderstanding. According to project delivery conventions, fixing faults is maintenance, while adding features is secondary development. Clarifying this boundary matters more than agonizing over the amount.

• What counts as maintenance: page style errors, login exceptions, payment callback failures, and adaptation after WeChat base library upgrades.
• What does not count as maintenance: adding new sections, redesigning pages, and integrating new APIs. These are secondary development and are usually billed separately.
• Judgment standard: if the developer has not proactively pushed platform update reminders within a year, the maintenance fee may just be a "nominal fee."

Counterexample: some developers count "patching" as maintenance, but after patching they don't update documentation, leaving the next person with no way to pick things up.

2. Why charge in the second year instead of a one-time buyout?

Source code can be delivered, but the runtime environment is dynamic. WeChat adjusts its base library, review rules, and payment APIs every year; servers and CDNs have leasing costs; and low-probability, high-impact data anomalies can occur during operations. These require ongoing monitoring by the developer. A "buyout" only buys you a snapshot of the current version, not future adaptations.

At project delivery sites, this conversation is common: the client asks, "Will you still fix issues for free later?" and the developer answers, "Small issues yes, but requirement changes are extra." This statement isn't written into the contract, so when a real fault occurs, both sides naturally argue. Therefore, at delivery, the "what the free period covers, what it doesn't, and response time limits" should be written into the appendix to provide a basis for second-year renewal.

It's not recommended to buy three years of maintenance in advance. Because Mini Program requirements and platform rules change quickly, a one-time package may seem cheaper, but service standards can be diluted, and switching developers midway is even more troublesome. Renewing annually and keeping options open is more in line with common practices in 2026. Many teams use the free maintenance period as a customer acquisition pitch, but they only do basic server monitoring and still charge per incident when problems occur.

3. The three-step verification method to judge whether the second-year maintenance fee is really worth it

Don't judge by the amount. Check the service contract in the following three steps, and only decide to sign after verification. This method comes from our experience in enterprise project delivery: every year, clients bring vague maintenance contracts and ask, "Are they charging us an IQ tax?" Actually, the contract itself isn't clear.

1. Check the service scope: Does it list specific items of "non-development maintenance"? For example, does bug fixing include emergency releases, and does data correction include rollback operations? If it only says "maintenance," ask for it to be detailed.
2. Check response time: Does it state "ordinary faults handled within X business days, major online faults responded within Y hours"? Maintenance without a response time is like a missing section in the file list. The longer the response time, the more the maintenance fee should be discounted.
3. Check the disclaimer boundary: Does it clearly state whether work caused by third-party API or WeChat platform rule changes is within the maintenance scope? This item is easy to overlook and often leads to additional quotes.

These three checkpoints correspond to "scope of work, speed of work, and how blame is shifted." Most disputes involving the second-year maintenance fee revolve around these three items. If all three are clearly written, the money buys certainty; if any one is missing, either ask for it to be added or cut the fee by a third and see how the other party reacts. If they refuse to revise the contract according to these three steps, you can basically conclude that the maintenance fee's value is limited.

4. Option comparison: outsourced maintenance, in-house technical staff, or no maintenance at all

Based on 2026 project delivery practices, there are three common approaches, each with its own applicability. Please don't assume "in-house is more professional" before understanding your needs—for many small and medium-sized enterprises, in-house costs far exceed outsourced maintenance.

• Outsourced maintenance: Several thousand to several tens of thousands per year (depending on feature volume), suitable for merchants without a technical team who value response speed. The advantage is peace of mind; the disadvantage is that long-term costs accumulate quickly.
• In-house technical staff: Monthly salary costs are often higher than the annual maintenance fee, plus you must manage hiring and turnover risks. Suitable for Mini Programs with high daily active users and critical business functions, and you need at least two technicians to avoid single-point dependency.
• No maintenance: Suitable for internal tools, event pages, and one-time demonstration scenarios. It saves money, but you must be mentally prepared to bear the risk of pages not loading and data anomalies going unfixed.

In comparison, a common misconception is: verbally claiming you've bought maintenance, but actually not even understanding the service scope. In this state, you've spent the money, but the risk is still on you. It's recommended to use "the actual number of repair calls in the past year" to estimate whether a yearly package is worthwhile for the next year: if you only called for repairs twice a year, pay-per-incident is more cost-effective than an annual package. When choosing outsourced maintenance, remember to confirm whether the developer has saved a backup of your source code; otherwise, if a major incident occurs, you might not even be able to recover.

5. Applicable scenarios and boundaries: when to pay, when not to

Cases where you should pay: The Mini Program has dynamic functions such as online payment, user registration, and data statistics, and you have no dedicated developer. In this case, the maintenance fee is a risk premium, and it's recommended to renew annually. Especially when the Mini Program serves as a customer service entry or handles transactions, the cost of cutting maintenance may far exceed the maintenance fee itself.

Cases where you don't need to pay: The Mini Program is just a digital business card for offline business, with no content updates for three months, and even the "Contact Us" page doesn't need changes; or you already have the source code and are planning a redesign. In these two scenarios, pay-per-incident or suspending renewal is more realistic.

Boundaries must be clear: If the developer says "If you don't pay the maintenance fee, the Mini Program will crash immediately," that's not factual. A Mini Program won't stop working right away; it will only gradually lose compatibility. You can directly refuse this kind of coercion to renew. There's also a category suitable for not renewing: the Mini Program has fulfilled its historical mission and is ready to be taken offline and migrated to a new platform; in that case, it's more cost-effective to focus on migration.

FAQ

What does the free maintenance period usually include?

It generally includes emergency bug fixes, platform adaptation updates, and basic stability monitoring, but usually does not include new features or page changes. Refer to the contract appendix for specifics.

How much does the second-year maintenance fee typically cost?

Based on 2026 experience, the typical range is 10%-20% of the development cost. For example, if development cost 50,000 yuan, annual maintenance might be between 5,000 and 10,000 yuan; simpler features or pay-per-incident plans will be lower.

Can the Mini Program still be used if I don't pay the maintenance fee?

In the short term, yes, but compatibility issues may arise after WeChat upgrades or server expiration; if the account is under the company's name, it won't affect independent operation, but no one will monitor anomalies for you.

How can I avoid hidden charges in the maintenance contract?

Require "requirement changes" and "fault fixes" to be listed separately, and specify the surcharge conditions for emergency response; also agree that after a certain number of free support calls, you'll be billed hourly, to avoid verbal additions.

Action guide: If you decide to renew, first ask the developer to provide the previous year's maintenance records, then check the new contract against the three steps above; if it's only for short-term demonstration, buying support services per incident is more flexible. Note that regardless of whether you renew, you should transfer the Mini Program account and server permissions back to your company's name to avoid being tied to the developer.