Nobody argues about the build quote. The argument comes eleven months later, when a payment screen stops working on a Saturday and the person who wrote the code is on leave.
Maintenance decides whether custom software stays an asset or becomes a liability, and it is priced on one thing: how fast someone has to answer. ZenWeb maintains web applications for Malaysian SMEs, and the quotes that go wrong are the ones where nobody agreed what "support" meant.
This page prices the plan, not the build. The video below covers what a service level agreement actually commits a supplier to.
What Is a Service Level Agreement (SLA)? | SLA Explained
Source video: The Knowledge Academy on YouTube
1. What Web App Maintenance Cost Looks Like in Malaysia
Quick Answer: Web app maintenance cost tracks the size of the application, not the size of the company. A small internal tool sits at RM250 to RM550 a month. A customer portal runs RM650 to RM1,350. A business system with several live integrations lands between RM1,500 and RM3,200 a month.
Read the table below as a ladder of moving parts. Every screen, login role and connection to another system can break when a browser or a payment provider changes underneath it. That is what the retainer buys. Each band sits inside ZenWeb's web development pricing as its own plan.
| Application type | Maintenance per year | Monthly retainer |
|---|---|---|
| Internal tool or single-form app | RM3,000 – RM6,500 | RM250 – RM550 |
| Customer portal with logins | RM8,000 – RM16,000 | RM650 – RM1,350 |
| Booking or ordering platform | RM11,000 – RM22,000 | RM900 – RM1,850 |
| Business system with live integrations | RM18,000 – RM38,000 | RM1,500 – RM3,200 |
| Marketplace or multi-tenant platform | RM28,000 – RM65,000 | RM2,300 – RM5,400 |
Source: ZenWeb client sample, web application support plans quoted and delivered for Malaysian SMEs, 2024–2026. Licence.
These are application figures, not website figures. Keeping a brochure site healthy is cheaper, as website maintenance cost in Malaysia and what a website costs show. Still sizing the build? See the custom web application price guide or what a web portal costs.
Key takeaway: Maintenance is priced on moving parts, not on turnover. Count your integrations and user roles before you judge whether a quote is fair.
Not sure which band your application sits in?
Send us the login roles and the list of systems it talks to, and we will place it on this ladder.
See how ZenWeb supports web applications →2. The 15% to 20% Rule: How the Retainer Number Is Built
Quick Answer: Take the original build price, take 15% to 20% of it, and divide by twelve. A RM90,000 application therefore costs about RM1,125 to RM1,500 a month to maintain. The percentage is a starting point that gets adjusted up or down by four things, not a final answer.
The rule works because maintenance effort scales with how much software exists, and the build price is the cheapest proxy for that. It stops being useful the moment your application is unusual: very simple, very integrated, or built by someone who left no documentation behind.
- Push the percentage down when the app is small, has one user type, talks to nothing else, and came with written handover notes.
- Push it up for every live integration. A payment gateway or accounting system changes on its own schedule, not yours.
- Push it up sharply for undocumented or inherited code. Somebody has to learn it before they can safely change it, and that reading time is billable.
- Push it up when the app handles money or personal data, because patching stops being optional and testing gets stricter.
Integration count is the driver people underestimate most; system integration project budgets shows why upkeep on a connection runs 10% to 20% of its build cost. First versions differ again — in MVP development cost in Malaysia, the early months are mostly change, not repair.
A retainer is not a subscription for software you already own. It is a standing arrangement for attention, the same distinction drawn in retainer versus one-off project pricing and one-time versus monthly website payment.
Key takeaway: Start at 15% of the build for a clean, simple app and work upward. Integrations and undocumented code are the two adjustments that move the number most.
3. Support Tiers: What a Faster Response Actually Costs
Quick Answer: Response time is the single biggest price lever in any maintenance quote. Moving from next-business-day to a four-hour SLA adds roughly 40% to the retainer. Round-the-clock cover with a one-hour response can more than double it, because it needs an on-call rota rather than one available developer.
You are not buying repair speed. You are buying a contractual promise that somebody picks up the phone within a stated window, which means the supplier holds capacity in reserve. Narrower window, longer cover, more reserve. The figures below are for the RM60,000 to RM120,000 application band.
| Tier | First response | Cover | Uplift | Monthly |
|---|---|---|---|---|
| Standard | Next business day | Mon–Fri, 9am–6pm | Baseline | RM900 – RM1,300 |
| Business | 4 working hours | Mon–Sat, 9am–9pm | +35% to +45% | RM1,250 – RM1,850 |
| Priority | 2 hours | Daily, 8am–10pm | +70% to +85% | RM1,600 – RM2,400 |
| Critical, 24×7 | 1 hour, any time | 24×7 on-call rota | +140% to +180% | RM2,300 – RM3,600 |
Source: ZenWeb client sample, support tiers quoted on Malaysian web application retainers, 2024–2026. Licence.
Choose the tier from your revenue clock, not from anxiety. If the app only takes orders during office hours, a weekend promise buys a risk you do not carry. If it takes payments at 11pm on a Sunday, standard cover is the expensive option. Who answers matters too: developer rates in Malaysia and how to vet one is the check to run first.
Key takeaway: Buy the response time your revenue actually needs. A four-hour SLA on a nine-to-five business is a 40% uplift protecting nothing.
4. Uptime Promises: What 99.5% and 99.9% Really Mean
Quick Answer: Uptime percentages are easier to read as minutes. Across a 30-day month, 99.5% allows about three and a half hours of downtime, 99.9% allows 43 minutes, and 99.99% allows four minutes. Two extra decimal places is a different hosting architecture, not a better promise.
Convert the number before you agree to it. The arithmetic changes how the promise reads:
- 99.0% — 7 hours 12 minutes of downtime a month.
- 99.5% — 3 hours 36 minutes.
- 99.9% — 43 minutes.
- 99.99% — 4 minutes, which needs redundant servers and automatic failover.
Then read who is actually promising it. Most application uptime is really your hosting provider's uptime; a maintenance supplier can only promise how fast they respond once something goes down. Check that split in the contract, because it decides who owes you what. Hosting downtime and how to stop it and what web hosting actually is cover it, and moving host without downtime is the fix when hosting is the weak link.
Watch the exclusions too. Scheduled maintenance windows usually sit outside the calculation, which is fair, but only if they are agreed in advance. Slow is also not the same as down. An app that loads in fourteen seconds is technically up and commercially useless, which is why page speed and what it costs you belongs here.
Key takeaway: Translate every uptime figure into minutes per month, then ask who owns it — the host or the maintainer. Unclear ownership is the real risk, not the decimal place.
Got a support contract in front of you?
We will read the response times, the exclusions and the uptime clause and tell you what is missing before you sign.
Compare it against ZenWeb's support plans →5. What the Plan Includes, and What It Quietly Excludes
Quick Answer: A maintenance plan covers keeping what exists working — monitoring, patching, backups, bug fixes and small changes. It rarely covers new features, third-party licence fees, cloud bills, redesigns, data migration, or rescuing an integration after the other party changes their API. Those are quoted separately.
Monitoring is the part clients undervalue, because it is the only line that prevents work rather than performing it. Uptime checks, error alerts and backup verification turn a Saturday outage into a Saturday notification. A plan without them is a repair service, not maintenance.
Normally included:
- Uptime and error monitoring, alerting a named person.
- Security patching of framework, libraries and server, plus certificate renewal.
- Automated backups, with at least one tested restore a year.
- Bug fixes on functionality that already worked at handover.
- A small monthly allowance of change hours, often two to six.
Normally excluded, and this is where invoices surprise people:
- New features and new screens. Anything the app could not do before is a project.
- Third-party costs. Cloud hosting, SMS and WhatsApp message fees, map and email API charges, paid licences.
- Changes forced by someone else. When a payment gateway updates its API, reconnecting is usually billable.
- Data work. Bulk imports, cleanups and migrations are scoped separately.
- Content and design refreshes, plus anything caused by a system the supplier does not control.
Get the excluded list in writing at quote stage. The hidden costs of custom software maps those third-party bills, and PDPA security rules for web systems covers the duties you cannot skip. Behind the included list sit a backup and restore plan, security practice, SSL and HTTPS, and what website maintenance includes.
Key takeaway: The exclusions list tells you more about a maintenance quote than the price does. A plan with no written exclusions has not been thought through.
6. Where a Retainer Month Actually Goes
Quick Answer: Roughly a quarter to a third of retainer hours go on incidents, about a third on preventive work, a quarter on small enhancements, and the rest on reporting and admin. Bigger applications spend more on incidents and less on prevention, which is the wrong way round.
The split is the argument for two budgets, not one. Incident hours are demand you cannot schedule; enhancement hours are work you choose. Share one pot and incidents always win, so after a year the app has been kept alive without being improved.
| Type of work | Internal tool | Customer portal | Business system |
|---|---|---|---|
| Incident fixes and bug reports | 24% | 28% | 31% |
| Preventive: patching, backups, monitoring | 38% | 33% | 29% |
| Enhancements and small changes | 26% | 28% | 27% |
| Reporting, access admin, coordination | 12% | 11% | 13% |
Source: ZenWeb client sample, logged retainer hours on Malaysian web application support plans, 2024–2026. Licence.
The fix is two contract lines instead of one. Keep the SLA retainer for incidents, prevention and admin, then hold a separate enhancement budget, often a quarter to a third of the retainer again, that carries forward when unused. Small improvements stop competing with a broken checkout. The same logic sits behind fixed price versus hourly quoting, and when incidents land, the usual suspects appear in fixing a 500 internal server error.
Key takeaway: Budget incidents and enhancements separately. One pot means the urgent work eats the improvement work every single month.
Application running, but never improving?
That is usually a budget structure problem, not a supplier problem.
Ask ZenWeb to split your support and enhancement plan →7. What Maintenance Costs in Years One to Five
Quick Answer: Maintenance is cheapest in year one, when the warranty still covers early bugs, and rises every year after that. On a RM90,000 application it typically starts near RM10,800 and reaches about RM24,300 by year five — roughly 12% of the build price climbing to 27%.
The rise is not a supplier squeezing you. Software ages against a moving world. Browsers change, libraries lose support, the business asks for more, and each year's changes add to the surface that has to be tested. Plan the five-year figure, not the first invoice.
| Year | Maintenance spend | Share of build | Main driver |
|---|---|---|---|
| Year 1 | RM10,800 | 12% | Warranty absorbs early bugs |
| Year 2 | RM15,300 | 17% | First real usage load |
| Year 3 | RM17,100 | 19% | Library and framework upgrades |
| Year 4 | RM19,800 | 22% | Integration partners change APIs |
| Year 5 | RM24,300 | 27% | Accumulated change, rebuild question |
Source: ZenWeb client sample, multi-year support engagements on Malaysian custom web applications, 2024–2026. Licence.
Year five is the decision year. Once annual maintenance passes a quarter of the build price and the app still cannot do what the business needs, replacing it competes on cost with keeping it. Two things soften the total. Hosting and third-party fees are separate and often trimmable, as domain and hosting prices in Malaysia shows. Maintenance is also a deductible expense — check custom software tax deduction and capital allowance before you file.
Key takeaway: Budget a rising line, not a flat one. Assume maintenance roughly doubles between year one and year five, and revisit the rebuild question when it passes a quarter of the build price.
8. How to Compare Two Maintenance Quotes
Quick Answer: Two maintenance quotes only become comparable once you normalise five things. Response promise, cover hours, included change hours, the exclusions list, and who holds the code and server access. Price is the last column, not the first.
Cheap plans are cheap because they promise a slower response and include fewer hours. That is a legitimate product, as long as you chose it knowingly. Run the five steps below on both documents first.
How to compare two web app maintenance quotes in five steps
Do this with both quotes side by side. It takes about half an hour and usually changes which one looks cheaper.
- Normalise the response promise. Write down first response time and cover hours for each. If one says four hours and the other says next business day, they are not competing on the same product.
- Count the included change hours. Two hours a month against six hours a month is a real difference in value; convert the gap into money at the supplier's hourly rate.
- Read the exclusions list first. A short exclusions list usually means a vague contract, not a generous one. Ask directly what happens when a payment gateway changes its API.
- Check who holds the keys. Repository, server, domain and database access should be in your company's name, with the supplier invited in. This is the clause that decides how expensive leaving will be.
- Ask for the exit terms. Notice period, handover deliverables, and whether documentation and credentials come with you. Then compare monthly price.
Step four costs the most when skipped. Who owns your website, domain and files and contract lock-ins and exit terms give the wording to insist on. Switching web developers without breaking your system is what good exit terms protect you from, and what to check before you approve a build applies the same discipline earlier.
Key takeaway: Compare the promise before the price. Response time, change hours, exclusions and access ownership decide the real cost of a plan.
9. Budgeting Maintenance Before You Sign
Quick Answer: Build the number from four inputs. Take 15% to 20% of the build price, add the uplift for the response tier your revenue needs, add a separate enhancement budget, then add the third-party bills the plan excludes. Assume the total rises each year.
A worked example, on a RM90,000 customer portal. Base retainer at 17% is about RM1,275 a month. A four-hour business tier adds roughly 40%, taking it to RM1,785. Add RM500 of enhancement budget and around RM350 of hosting and message fees, and the honest figure is close to RM2,600 a month, not the RM1,275 the percentage rule alone suggested.
ZenWeb quotes maintenance against the response time a business genuinely needs, and separates the enhancement budget from day one. Start from our web development pricing, or the custom web application cost guide if the build is still being sized.
Want a maintenance figure you can put in next year's budget?
Book a free 30-minute session. Tell us what the application does, what it connects to and when your revenue clock runs. You get a support tier, a retainer range and the excluded costs on one page.
Get my support plan priced →
10. Frequently Asked Questions
1. How much does web app maintenance cost in Malaysia?
Between RM250 and RM5,400 a month, depending on the size of the application. A small internal tool sits at the bottom of that range, a customer portal runs RM650 to RM1,350, and a business system with several live integrations lands between RM1,500 and RM3,200.
2. Is 15% to 20% of the build price a reliable rule?
It is a good starting point for a clean, well-documented application. Push it up for every live integration, for undocumented or inherited code, and for anything handling payments or personal data. Push it down for a small single-purpose tool that talks to nothing else.
3. How much does a four-hour SLA add to the price?
About 35% to 45% over a standard next-business-day plan, because the supplier has to hold capacity in reserve. A one-hour response with 24×7 cover needs an on-call rota and typically adds 140% to 180%.
4. What is usually excluded from a maintenance plan?
New features, cloud hosting and third-party message or API fees, data migrations, design refreshes, and reconnection work after an integration partner changes its API. Ask for the exclusions list in writing before you sign anything.
5. Does maintenance cost stay flat year after year?
No. It typically starts near 12% of the build price in year one while the warranty absorbs early bugs, then climbs to around 27% by year five as libraries age and changes accumulate. Budget a rising line rather than a fixed one.
