Most software budgets in Pakistan stop at launch. The build is quoted, approved and delivered, and maintenance is treated as an optional extra to consider later. Later arrives as an emergency, usually at the worst possible time, and costs several times what a maintenance arrangement would have.
What maintenance actually covers
1. Security patching
Frameworks, libraries and server software publish security fixes continuously. A typical web application depends on dozens of packages, several of which will have a serious vulnerability disclosed in any given year.
This is not optional work. An unpatched application is compromised eventually, and the cost of that is not measured in development hours.
2. Platform changes you do not control
Browsers change. Android and iOS ship breaking changes annually and eventually stop accepting apps built against old SDKs. Payment gateways deprecate API versions. WhatsApp changes its business policies. None of this is caused by your software and all of it breaks your software.
3. Bugs that only appear at scale or over time
A report that was fast with 5,000 records is slow with 500,000. A date handling bug that only appears at a year boundary. A file storage assumption that fails when the disk fills. These are not build defects; they are the cost of software meeting reality.
4. Small changes the business needs
A new tax rate, an extra field on a form, a report with a different grouping, a new user role. Individually trivial, continuous in aggregate.
5. Monitoring and backups that someone verifies
Backups nobody has tested are not backups. Monitoring nobody watches is decoration. This is the least visible part of maintenance and the part that matters most on the day something goes wrong.
The real numbers
As an annual percentage of the original build cost:
- A simple website: 10 to 15 percent per year.
- A business web application: 15 to 20 percent.
- A mobile app: 15 to 25 percent. Higher because two operating systems both change annually.
- A system with several integrations: 20 to 30 percent. Every external dependency is a thing that can change without asking you.
In rupees, a 2,000,000 PKR application costs roughly 300,000 to 400,000 a year to keep healthy. That is the number to put in the budget at the start, not the number to be surprised by in year two.
What happens to systems nobody maintains
The decline is predictable and follows the same sequence:
- Months 1 to 6: nothing. This is why skipping maintenance feels safe.
- Months 6 to 12: small breakages. An integration stops working. A browser update breaks a layout.
- Year 2: the dependency versions are far enough behind that updating one requires updating several. What was a routine patch becomes a project.
- Year 3: the original developers are gone, nobody understands the code, and the honest quote to fix anything is a rewrite.
The rewrite costs more than five years of maintenance would have. This is the single most common expensive mistake we see in Pakistani businesses with custom software.
Support models compared
Retainer
A fixed monthly fee for an agreed number of hours, patching, monitoring and a response time. Predictable for both sides, and the only model where preventive work actually happens, because nobody has to seek approval for a security update.
Best for systems the business depends on daily.
Pay as you go
You call when something breaks and pay hourly. Cheaper on paper. In practice nobody patches anything, so you pay for the emergencies instead of preventing them. Also expect to queue, because a partner with retainer clients serves them first.
Acceptable for low stakes systems where a week of downtime is survivable.
In house
Viable once you have enough systems to occupy someone. Below that, you are paying a full salary for part time work, and the risk is concentrated in one person who will eventually resign.
What to agree before you need it
- Response times by severity. What counts as critical, and how fast someone starts work.
- What is included versus billable. Bug fixes included; new features quoted. Define the boundary in writing, because this is where every dispute happens.
- Who has access to what. You should hold the repository, hosting and domain accounts yourself. Always.
- Backup and restore, tested. Ask for a restore to be demonstrated once a year.
- An exit arrangement. If you change partner, what gets handed over and in what form.
How to reduce maintenance cost legitimately
- Fewer dependencies. Every library and plugin is a future update. Simpler systems cost less to keep.
- Fewer integrations. Only build the ones you actually use.
- Automated tests. They cost more up front and make every future change cheaper and safer. See our note on what automated testing involves.
- Documentation written during the build, not promised afterwards.
- Standard technology rather than unusual choices. Being able to hire someone who knows the stack is a maintenance feature.
Frequently asked questions
How much should I budget for software maintenance?
15 to 20 percent of the build cost per year for a typical business application, more if it has several integrations or a mobile app.
Can I skip maintenance for a year?
You can, and the bill arrives later with interest. Security patching in particular should never be deferred.
Is maintenance included in the build price?
Usually a 30 to 90 day bug fix period is. Ongoing maintenance is separate and should be quoted before launch, not after.
What if the original developers are unavailable?
Any competent team can take over a well structured, documented codebase in a repository you own. This is the practical reason to insist on owning the repository from day one.
Ezitech maintains systems it did not build as well as ones it did. Ask us to assess what you are running.
Related: What software actually costs in Pakistan — every Ezitech cost guide in one place.