A software build project ends with a handover, but the software itself does not stop needing attention the day it launches. Servers need patching, dependencies age, and every business process the system supports keeps evolving — which is exactly what an Annual Maintenance Contract (AMC) is supposed to cover. The problem is that "maintenance included" means something different to every vendor, and the gap between those definitions is where support relationships quietly go wrong.
This guide breaks down what a software AMC in Bangladesh should actually include, what reasonably gets billed as separate work, typical SLA response times by severity, and the specific red flags worth checking before signing — whether the AMC is with the original developer or a new vendor taking over an existing system.
Signing this from another country? One clause does more damage than any other when the two parties are in different timezones, and it is the one everybody skims. An SLA that promises a “four business hour” response has not actually promised anything until the contract says whose business hours and in which timezone. Four business hours from a Dhaka desk, for a fault you report at 5pm in London, is the following afternoon. Fix it by writing the timezone into the SLA explicitly, agreeing the overlap window in which acknowledgement is guaranteed, and defining separately what happens to a critical outage raised outside it. The cost benchmarks below still apply — they describe the Bangladesh market you are buying in — but response times are the part you should renegotiate rather than accept as standard.
The core question: is this a keep-the-lights-on support agreement, or is it quietly being sold as an unlimited development retainer neither side has actually priced that way?
What a Software AMC Should Include
A properly scoped AMC, as touched on in our ERP pricing guide, typically runs 15–20% of the original project cost per year and covers a defined, bounded set of responsibilities — not an open-ended promise to "handle anything that comes up."
Hosting & Server Management
Keeping the server, database, and hosting environment running, patched, and backed up — including monitoring for downtime and applying operating-system security updates.
Bug Fixes
Correcting defects in functionality that was already built and delivered — something not working as originally specified, not a request for it to work differently.
Security Patches
Applying updates to frameworks, libraries, and dependencies as vulnerabilities are disclosed, rather than leaving a system running on years-old, unpatched components.
A Defined SLA
A written response-time commitment tied to issue severity — not a vague promise to "get to it soon" that has no way to be held to account.
Reasonable SLA Response Times by Severity
| Severity | Response Time | Example |
|---|---|---|
| Critical (system down, data loss risk) | 2–4 hours | Payment processing failing, database inaccessible, security breach |
| High (major feature broken) | Same business day | Inventory sync failing, reports generating incorrect data |
| Medium (minor feature issue) | 1–3 business days | A filter not working correctly, a report layout glitch |
| Low (cosmetic, non-blocking) | Next scheduled release | A typo, a spacing inconsistency, a minor UI polish request |
Response time is when a human acknowledges and starts investigating — not when the issue is fully resolved. A contract that only commits to response time, with no separate resolution-time target, still leaves genuine ambiguity worth clarifying before signing.
What Usually Gets Billed Separately
An AMC keeps an existing system running — it is not a substitute for a development budget. New features, workflow changes, and functionality the original system was never built to do are normally scoped and quoted separately, the same way any new development work would be.
The genuinely disputable middle ground is third-party API changes — when bKash, Nagad, or a courier partner (see our courier API integration guide) changes their API and something breaks as a direct result. Some vendors treat that as a covered bug fix since the business didn't change anything; others bill it as new work since the third party is what changed. Get this written into the contract explicitly — it is one of the most common sources of AMC disputes.
What to Check Before Signing
A Written SLA, Not a Verbal Promise
Response times by severity should be in the contract itself, not something the vendor "always tries to" honor informally.
Source Code and Infrastructure Access
Confirm the business — not just the vendor — has admin access to hosting, domain, and a copy of the source code, independent of whether the AMC is renewed.
What Counts as a "Major Version Upgrade"
Framework or database major-version upgrades are commonly excluded from a standard AMC — confirm whether that applies before assuming everything technical is covered.
An Exit Clause
A defined handover process if the business wants to switch vendors — including how quickly access and documentation get transferred — protects against being effectively locked in.
Red Flags in an AMC
- A price well below the typical 15–20% range with no explanation of what is excluded to make it cheaper.
- No written response-time commitment by severity — just an assurance that support is "responsive."
- The vendor holds the only copy of source code or domain/hosting credentials, with no plan to share access.
- Vague language like "reasonable support" or "as needed" instead of a defined scope of what is and isn't covered.
Frequently Asked Questions
Most custom software and ERP AMCs run 15–20% of the original project cost per year, covering hosting, bug fixes, and security patches. A vendor quoting well below that range is usually excluding items — like security patching or a real SLA — that show up as extra charges later.
Bug fixes and keeping the existing system running are what an AMC covers. New features, workflow changes, and requests that add functionality beyond what was originally built are normally scoped and billed separately — an AMC is not an unlimited development retainer.
For a system-down or data-loss severity issue, 2–4 hours response time during business hours is a reasonable standard to ask for, with resolution time tracked separately from response time. Anything without a written response-time commitment by severity level should be treated as a red flag, not an oversight.
This varies and should be spelled out explicitly, since it is one of the most common disputes. When bKash, Nagad, or a courier partner changes their API and something breaks as a direct result, some vendors treat that as a covered bug fix and others treat it as new work — get this written into the contract before signing, not assumed.
This depends entirely on what was agreed at the original build — specifically whether source code and infrastructure access transfer to accounts the business controls. An AMC with a vendor who also holds the only copy of the source code creates a dependency that has nothing to do with the maintenance work itself.
A Clear AMC Protects Both Sides
A well-scoped AMC isn't just a cost line — it's the difference between a support relationship that both sides can rely on and one that turns into a dispute the first time something breaks. The specifics matter more than the headline percentage: what counts as a bug versus new work, what the actual response time is, and who controls access if the relationship ends.
Evaluating a support agreement, or need one? BengalTech Solutions writes clear, scoped AMC agreements for the custom software and ERP systems we build. Ask us to review your current AMC.