Maintenance and Support Contracts for Websites, Systems and Apps

The complaint we hear most from companies in Saudi Arabia and the Gulf is not about how the system was built, but about what came after: "It worked for two months, then it stopped and nobody answers." Software does not stand still. Browsers update, libraries reveal vulnerabilities, payment gateways and ZATCA change their requirements, and growing data slows queries down.

A maintenance contract turns those risks from expensive surprises into scheduled work at a known cost. More importantly, it names who is responsible, how long a response takes, and what happens if the system fails over the weekend.

Not every fault matters equally, and treating every ticket the same way means either slow handling of critical issues or overpaying for minor ones. So we classify every ticket on arrival by its impact on your business, and the contract states the target response and resolution time for each level.

A critical fault stops work or blocks sales: the system will not open, payments fail, invoices do not reach ZATCA. An important fault breaks part of the work but has a temporary workaround, such as a report that does not load or a notification that is not sent. A normal issue is cosmetic or an improvement that does not affect operations.

This classification protects both of us: you know when to expect a response to every ticket, and we know where to focus first. The monthly report lists every ticket with its level and actual response time, so you judge our commitment by the numbers, not by impressions.

We write the maintenance scope into the contract item by item so there is no argument later. The key distinction to understand before signing: maintenance means keeping what exists running efficiently and securely. Large new features are priced as a separate development project, or taken from the hours allowance if they are small.

The monthly price alone is not enough to compare offers. A cheap offer with no written response times can cost you more at the first real outage. Ask every vendor to answer the same questions so you compare like with like.

Yes, and it is a common case: a company paid a developer, contact was lost, and now there is a working system that nobody knows how it was built. We start with a paid, time-boxed technical audit: we review the code, the database, the server and the accounts, and make sure the domain, hosting and code are in your name, not the previous developer’s.

The audit ends with a written report: what works, what the urgent risks are, and what needs rewriting. You then decide clearly between a maintenance contract for the current system or a gradual modernisation plan, with no pressure from us to rebuild everything.

We begin with a short online meeting to understand the system and how much your business relies on it, then ask for read access to audit its current state. Within days you receive the audit report and a written maintenance offer with prices and scope.

After signing, we set up a WhatsApp group for tickets, switch on monitoring and backups in the first week, and send the first monthly report at the end of the month. You can stop the contract or change the plan as the contract allows, and everything stays yours.

The first mistake is starting maintenance after the outage instead of before it. When a system suddenly stops with no contract in place, you hunt for any developer available that day, who works under pressure on a system they do not know, and you pay several times what an organised monthly contract would have cost.

The second is postponing updates for years because "the system works". Every year of delay makes the next update bigger and riskier, until the system can only be updated by rewriting large parts of it. Small, regular updates are always cheaper than one big leap.

The third is missing documentation: nobody knows the passwords, where the backup is, or why a part was written the way it was. So with every maintenance contract we build and keep updated a short operations document that stays with your company, so any future vendor can take over the system without starting from scratch.