Website Maintenance After Launch: What You Are Actually Paying For (2026 Guide for Business Owners)

The project ended, the site went live, the handover email was sent. Two months later a different email arrives with the subject "annual maintenance contract", and the owner asks a fair question: what exactly am I paying for? The site works, I have requested no changes, so why is there a recurring cost at all?

Most maintenance offers are written in vague language: "periodic follow-up, updates, technical support". That wording makes it impossible to compare two quotes, or to tell value from a subscription that buys nothing. This guide shows what happens behind the word "maintenance", what breaks when it is skipped, and which contract questions reveal a provider's quality.

It is written for owners and managers in Egypt and Saudi Arabia who own a company website, an online store or a web-based system — not for IT teams. At Jad Digital we have run maintenance contracts for years, and we also inherit sites built by other teams and left untouched for just as long. The contrast between those two is the source of most of what follows.

A website is not a painting on a wall. It is software running on moving layers: a server OS, a language, a framework, third-party libraries, a database, an encryption certificate, browsers that update every few weeks, and search engines that change their rules. You changed nothing; everything underneath you changes constantly.

So an unmaintained site does not collapse — it erodes. A page renders incorrectly in a new browser. A contact form quietly stops delivering messages. Speed degrades month by month. Then one day everything stops because an outdated library no longer works with the server. Good maintenance prevents that day; bad maintenance arrives after it.

These three words get mixed up constantly, and that confusion causes most disputes with providers.

Many weak contracts sell hosting under the name of maintenance. If the offer does not name recurring human tasks explicitly, you are buying server space and nothing more.

• Hosting is an operations service: disk space, a server, a network. Your host guarantees the machine is running, not that your site is working.
• Maintenance is recurring human work on your specific site: updates, backups, monitoring, bug fixes, security checks, small content edits.
• Development is building something that did not exist: a new page, a booking module, an integration, a redesign.

Three dates should be owned by a named person in your company: domain renewal, hosting renewal and SSL certificate renewal. If any lapses, the site goes down or every visitor sees a "not secure" warning — worse than downtime, because it damages trust and not just availability.

The patterns are consistent: a domain registered under a former employee's email so renewal notices go nowhere, an auto-renewing certificate that fails silently after a server change, or a domain registered to the agency rather than the company that owns it. A proper contract calendars these dates, chases them early, and documents where each service is managed and who holds the account.

Every provider says they have backups. The real question is not "do backups exist?" but: how often are they taken, how many copies are kept, do they include the database and the files, are they stored off the server, and when was a restore last actually attempted?

An untested backup is not a backup — it is an assumption. We regularly inherit sites where backups were written to the same disk that failed, or stopped months earlier because nobody reads failure reports. Ask for an explicit schedule, off-server storage, and one real restore test per year with a written result.

Any modern site is built on dozens of ready-made libraries. When a vulnerability is found in one, its maintainers publish a fixed version — and your older version becomes a publicly documented target. Automated scanners crawl the internet looking for exactly those versions. Your site does not need to be famous to be found.

This is the largest invisible part of maintenance: reading advisories, judging severity, updating on staging first, confirming nothing broke, then deploying. Skipped for two years, updating becomes a full upgrade project — usually costlier than every instalment that was "saved".

A typical small-business site is not breached by a targeted attack. It is caught by a wide automated sweep. The most common results:

Serious security maintenance means regular updates, an application firewall, login attempt limits, two-factor authentication on the admin panel, and periodic review of accounts and permissions — especially removing leavers.

• Hidden spam pages and links injected to exploit the site's standing in Google — after which the site is penalised in search results.
• The server used to send bulk spam, landing your email domain on blocklists so messages stop reaching customers.
• A contact form or checkout page modified to capture whatever visitors type.
• An admin panel with a weak password, no two-factor authentication and no limit on login attempts.

The revealing question: if your site goes down at two in the morning, who finds out first — you or a customer? A monitor that checks every few minutes and alerts instantly is the cheapest line item in any contract and the one that saves the most. Good monitoring does not only check the homepage; it checks critical paths too: a product page, checkout, the contact form, and whether emails are delivered.

A site is handed over fast and then gets heavier: marketing uploads images at full original size, tracking and ad scripts are added with every campaign, the database grows with old orders, plugins get installed and forgotten. Each is small; together they add seconds to load time.

Because it decays gradually, performance is worth measuring quarterly against the previous reading rather than once at handover. Pick three or four pages that represent your business — home, a service or product page, checkout or contact — and time them on mobile over an average connection. That comparison alone shows when a new script or oversized image undid careful work.

Speed is not a matter of taste. Slow loading lowers conversion and weakens ranking, because page experience signals are a published part of how Google evaluates pages. That is why our contracts include a recurring performance review, the core of our website performance and speed optimisation service: compressing and converting images, auditing third-party scripts, cleaning the database, and tuning caching and content delivery.

The most common source of friction is the boundary: what is included in the retainer and what counts as extra work. The rule we use is simple:

Write that classification into the contract with examples. Specify how many edit hours per month are included and whether unused hours roll over. Leaving it vague turns every small request into a negotiation, and it is the most common reason maintenance relationships end badly.

• A bug: something that used to work as specified and has stopped or now behaves incorrectly. Fixing it is inside the contract.
• A content edit: changing text, an image or a price, or adding an article or product within the existing design. Normally covered by agreed monthly hours.
• A new feature: something that did not exist — a booking module, an extra language, an integration, a newly designed page. Extra work, quoted separately.

A neglected site loses ranking gradually even with no visible error. Internal links break after a page is deleted, pages start returning error codes unnoticed, articles go stale while a competitor updates theirs, the sitemap stops refreshing, and the robots file gets edited during an experiment and blocks the whole site from indexing — a mistake we have seen on real live sites more than once.

The costliest single mistake is deleting a page or changing its URL without a permanent redirect to the nearest replacement, which throws away years of accumulated ranking and external links. On bilingual sites there is another layer: both language versions must stay in step, point at each other with the right language tags, and appear in the sitemap.

So serious maintenance includes a periodic check of search console data: indexing and crawl errors, pages that disappeared, page experience metrics, and the integrity of conversion tracking. Tracking breaks silently more often than owners imagine: a deployment drops the measurement tag, and you keep spending on ads with no reliable data for months. If search fundamentals are still fuzzy for you, our plain-language guide on how your site appears in Google explains them for business owners.

A restaurant site built three years earlier and left untouched. As Ramadan approached — its highest-demand season — the menu page stopped rendering on certain phones after a browser update, and the reservation form had quietly stopped sending email weeks earlier. The loss is not the repair cost; it is a season of bookings that never arrived.

Nothing here needed more than a monthly form test and a check on a current phone. Silent faults are never found by accident, only by a written recurring checklist — which is why form and email-delivery testing is a fixed clause in our contracts.

Payment gateways and shipping companies update their APIs and retire old versions, announcing it by email to whatever address the developer registered. A store with no maintenance contract never reads that notice and finds out when customers report failed payments. The nastiest part is that the failure is partial: payment succeeds on some cards and fails on others, so the site looks healthy in a quick test while sales bleed.

A services company's site was compromised through an outdated plugin and its server used to send spam. The visible damage was not a defaced page — it was the company's domain landing on email blocklists. Quotes stopped reaching inboxes for weeks, and repairing the domain's reputation took far longer than cleaning the site. We cover more ways sites quietly lose sales in e-commerce mistakes that kill sales.

Maintenance is usually offered in three tiers. Compare them by scope, not by the number at the bottom, because two offers with the same tier name can contain completely different work.

For a brochure site whose content rarely changes. Typically: renewal tracking for domain, hosting and certificate; regular off-server backups; security updates for the platform and its libraries; uptime monitoring with alerts; and fixing reported faults within a defined response time. It usually excludes content edits and development.

Everything above, plus agreed monthly hours for small content and design changes, a recurring performance review, and a monthly report of what was done and what needs attention. The right level for most company sites that publish offers, articles and new service pages.

For stores and platforms the company's daily revenue depends on. It adds broader monitoring of critical paths, a shorter response time with out-of-hours coverage, a staging environment before any deployment, active tracking of payment, shipping and e-invoicing changes, and a monthly incremental development plan instead of scattered one-off projects.

What moves the cost up or down? Site size, pages and languages; store versus brochure site; the number of external integrations; the response time and holiday coverage you require; monthly edit hours; and whether the site was built to sound standards or needs constant firefighting. A well-built site is cheaper to maintain for its whole life — one of the factors in what determines website design cost in Egypt. An accurate figure requires auditing the existing site first, which is what the first consultation is for.

Ask for three things in writing: the response time (within how many working hours will someone reply?), the target resolution time per severity level (a fully down site is not a broken internal page), and the approved reporting channels and coverage hours. "We are always here for you" is not a service level agreement.

This is usually discovered at the worst moment — when you decide to change provider. Before signing, confirm the domain is registered under your company name and email, the hosting account is in your name with administrative access, the code sits in a repository you can reach, and credentials are documented on your side rather than in one person's head. Your site is a digital asset you own — the principle we set out in why a Facebook page is not enough.

Ask directly: if I end this contract, what do I receive and within how many days? A good answer includes a complete copy of the code, database and files, a documented list of every account, and a reasonable transition period. Anyone refusing to put an exit clause in writing is telling you something about the relationship on offer.

One last point on terms: keep the initial commitment reviewable after a short trial. The first three months reveal almost everything — real response speed, report quality, and whether the site is checked proactively or only after you report a fault. Agree on one named contact per side, because maintenance run through a group chat with no owner turns into lost requests.

• Who performs the maintenance: a consistent developer who knows my site, or whoever is available?
• Is there a monthly report showing what was done and what was found?
• Are updates tested on staging before going live?
• How do you handle an emergency outside working hours?
• What is explicitly not included? (This answer matters more than the inclusion list.)

An in-house employee suits companies with several systems and enough daily work to fill the role. The upside is instant response and deep knowledge of the business; the downside is that one person cannot cover every specialism — servers, security, front-end, SEO — and a resignation leaves a complete gap.

An agency or development company fits most small and medium businesses: a multi-disciplinary team, continuity that does not depend on one individual, and shared monitoring and backup tooling. The potential downside is slower response if you are a small client of a large provider — which is why the written response time matters.

A freelancer is practical for simple sites on a lighter budget, but the risk is obvious: a single point of failure, absence during travel or illness, and thin documentation. If you go this route, insist every account is in your name and the code lives in a repository you own. The criteria for choosing a technical partner apply here too; we detail them in our guide to choosing a web design company in Cairo and our pillar guide on choosing the best software company in Egypt.

An online store is not a brochure site with a buy button. It is a system handling money, customer data and third parties that keep changing. Its maintenance carries an extra layer:

One administrative item is always neglected: accounts and permissions. A store dashboard is used by an accountant, a stock controller, a content editor and perhaps a marketing agency, and each needs the least access that covers their job rather than a full admin account. Review quarterly who can reach what, remove leavers immediately, and ban shared logins, because they destroy any ability to know who did what when something goes wrong.

• Payment gateways: API changes from Paymob, Fawry, InstaPay, Mada, Tabby, Tamara and others, plus monitoring transaction failure rates rather than merely confirming the gateway exists.
• Shipping companies: tracking interfaces, delivery pricing and covered zones all change.
• E-invoicing: in Saudi Arabia the Zakat, Tax and Customs Authority's integration-phase requirements keep evolving, and in Egypt the Tax Authority's e-invoice and e-receipt systems do the same. Requirements shift, so always confirm the currently applicable details on the authority's own portal, and make tracking them an explicit clause if your system issues invoices.
• Inventory and pricing: any integration with an accounting system or ERP needs sync monitoring, because a silent failure means selling products you do not have.
• Seasonality: before major seasons — Ramadan, White Friday, seasonal sales — you want a load test, a performance review, and a freeze on unnecessary deployments during the season.

Maintenance preserves what exists; it cannot fix a structural decision made at build time. At some point a monthly fee on an ageing site is rent on an unsolved problem rather than investment in an asset. The signs:

The practical test: add up a year of maintenance and repeat repairs, and compare it with a one-off clean rebuild that can then be maintained for a fraction of the effort. If the two are close and the same causes keep recurring, rebuild rather than renew — and ask for the reasoning in writing.

• The platform or language version is no longer supported, so security updates are not published at all.
• Every small change breaks something else, turning simple edits into repeated mini-projects.
• The site works poorly on phones, and fixing that means rebuilding the front end, not adjusting it.
• Speed has hit a floor no image or caching work improves, because the problem is the architecture.
• What the business needs today — a second language, a store, an accounting integration, a content panel — cannot be added without expensive workarounds.
• Nobody can edit content without a developer, so the site freezes behind requests and waiting.

Monthly: confirm backups succeeded · apply security updates · review the uptime and incident report · test contact forms and email delivery · a quick scan of indexing errors.

Quarterly: measure the speed of key pages and fix regressions · review user accounts and permissions · check for broken links · verify conversion tracking still fires · review payment failure rates for stores.

Annually: perform a real restore test from a backup · review domain, hosting and certificate renewal dates · review platform and library versions and plan upgrades · review and refresh the core page content · review the contract itself: is the scope still right for the size of your business?

Keep this list in a shared document your company owns, not in the provider's head, with the date and the name of whoever last completed each item. Then bring it to the first meeting with any maintenance company and ask which lines their offer covers — that single question reduces comparing quotes to minutes.

Every contract starts with an audit of the existing site: platform and versions, known vulnerabilities, backup status, performance, and the health of indexing and tracking. The audit separates what must be fixed now from what can be scheduled, and only then do we agree the service level your business actually needs rather than selling the largest package.

After that the work is recurring and documented: updates tested on staging before deployment, off-server backups with restore testing, monitoring of critical paths rather than the homepage alone, performance reviews under our performance optimisation service, and a clear monthly report. When a site needs real development rather than maintenance, we say so and quote it separately under our web development services — maintaining a site that has outlived its architecture is recurring spend on a problem maintenance cannot solve. Ownership stays with you throughout: domain, hosting, code and database.