Dubai · Website Care
Website support plans in Dubai — a named engineer and a monthly report.
Every month: updates staged and shipped, a restore actually performed, monitoring reviewed, and your list of small changes worked through. You end it holding a report that names what changed and what we would do next — and a runbook another developer could pick the site up from.
- Updates staged before they ship
- Retained hours every month
- Cancel with 30 days
What's included
Six things a support plan does every month.
Each one leaves evidence behind — a staging URL, a restore date, a line in an hours log, a report you can forward to someone else.
The update window
Core, plugins, themes and dependencies go to staging first. A person walks the pages that take bookings or money, then it ships, with the previous version kept ready to go back to. Anything held back is listed with the reason rather than left quietly unapplied.
Backups, and a restore that has been run
Copies kept somewhere other than the web server, and restored on a schedule so the procedure is already known on the day it matters. The report carries the date of the last one, because the only backup worth anything is one somebody has already restored from.
Monitoring that reaches a person
Uptime, error rate, certificate expiry and licence renewal dates — plus a standing check that form submissions still arrive where they are meant to. Alerts route to the engineer who knows your site, so the first thing you usually hear is what has already been done.
A block of retained hours
Engineering time each month for the changes that are too small to quote and too many to ignore: a new page, a form field, a price update, replacing a plugin that has been abandoned upstream. Logged per request, so the report can show where the block went.
A named engineer
One person who knows the site, and a second who has read the runbook, so cover does not mean starting from scratch. Incidents leave the normal queue and you get the write-up afterwards, rather than a status page to keep refreshing.
The monthly report
A page or two written by the engineer who did the work: what was updated, what was held and why, the last verified restore, where your hours went, and one recommendation. Written to be read by whoever signs the invoice, not by a developer.
Who it's for
Three situations a plan is written for.
A plan is for a site that works and needs keeping. Where one is already failing, the stabilising is scoped as its own piece of work first — we would rather quote that honestly than start a monthly cycle on top of it.
A site we built, six months on
The build went well and the handover was complete. Since then nothing has been touched: dependencies have moved on, a certificate renewal is due, and the three changes marketing asked for are still sitting in a message thread. Nothing is wrong yet, and the plan exists so that stays true.
Nobody has deployed a change since launch week.
A marketing team with no developer
You own the site commercially but not technically. Every change — a page for next month's campaign, a new team photo, the form field finance asked for — has to be routed to somebody, and the routing reliably takes longer than the work itself.
Your last three website changes waited on somebody's spare time.
A business whose site takes the orders
Bookings, enquiries or checkout run through the site, so an hour of downtime has a number attached to it. What that buys is not somebody to fix it afterwards: it is a response target written down, monitoring that reaches a person, and a restore tested before the day you need it.
You cannot say who would be called first if the site went down at 9pm.
How it works
Five steps, and the plan gets resized at the end.
Each step produces something written down — a scope, a runbook, a report — so you can tell whether the arrangement is doing anything.
01
Size the plan
What the site runs on, how often it changes, what an hour of downtime costs you, and who on your side the engineer will actually talk to. That settles the hours, the response target and the tier before a number is quoted. On a site we did not build, the audit comes first and is the one step we will not skip.
02
Write the runbook
Before the first month begins: where the site is hosted, what it depends on, how a change reaches production, where backups land, who holds each account, and what to do in the first ten minutes of an outage. It exists so the plan does not depend on one person's memory — including ours.
03
The baseline month
Monitoring configured and pointed at a person. One restore performed end to end. Updates brought level. The small-change backlog you have been carrying cleared with the first block of hours. It ends with the first report, which is usually the longest one you will get.
04
The monthly rhythm
Same engineer, same order, every month. Your requests are worked inside that cycle rather than queued behind an unrelated project, and anything that turns out to be larger than it looked comes back with a quote before it starts — not after it has quietly eaten the month's hours.
05
Review and resize
Every few months the plan is read against what actually happened: hours used, incidents raised, updates held back, and whether the tier still matches the site. If the honest answer is a smaller plan, we say so. A retainer that has outgrown its usefulness is how care work earns its reputation in this market.
Stack
Boring technology, chosen so the next developer recognises it.
Nothing here is exotic. That is the point: an unusual stack is a lock-in mechanism dressed up as innovation.
- CMS & commerce
- WordPressShopifySanityPayloadWooCommerce
- Infrastructure
- VercelAWSCloudflareGitHub ActionsSentry
Deliverables
What a plan puts in your hands.
All of it lives in your accounts, and all of it is written so somebody else could take the site over from it.
- A written runbook — where the site is hosted, what it depends on, how a change reaches production, and what to do in the first ten minutes of an outage
- An account and renewal inventory: every login, whose name it is in, and the date it next renews
- A staging environment where updates are checked before they reach the live site
- A restore that has actually been performed, with the date it was last verified
- Monitoring configured against your site — uptime, errors, certificate expiry and form delivery — alerting a named engineer
- A monthly report naming what changed, what was held back, and what we would do next
- An itemised hours log, by request rather than as a monthly total
- Written response targets by severity, set out in the plan document rather than agreed verbally
The runbook is the real test. If we disappeared in month three, it should be enough for another developer to keep the site running without ringing us — which is why it is written before the first month rather than promised for later.
Pricing
What a support plan costs.
AED 1,500
per month
That is the Launch care tier — updates, backups and monitoring on a small business site. A plan carrying a real block of retained hours and monthly reporting is AED 6,500. A site that needs a dedicated squad and SLA-backed response is AED 15,000. Prices exclude 5% VAT, and plans are billed monthly rather than as a twelve-month contract.
What changes the priceWhat that covers
- Core, plugin and dependency updates, staged before they ship
- Offsite backups, with a restore performed on a schedule
- Uptime, error, certificate and licence monitoring
- Retained hours each month, logged per request
- A named engineer, and a written response target
- A monthly report of what changed and what we would do next
Clinics and healthcare
The booking form is the front door, and one that fails silently costs appointments nobody knows were lost. Consultant lists, insurer panels and clinic hours change more often than the owners expect, and because patient details pass through the site, an update that breaks a form is a data problem as well as a lost enquiry.
Restaurants and F&B
Menus, prices and opening hours move weekly, then move again for Ramadan and the summer. Most of those edits are made by somebody whose actual job is not the website, so the plan is judged on something narrow: whether a small change can be made safely on a Friday evening and undone by Saturday morning.
A support plan is the retained, month-to-month end of our website maintenance service and it is the one concerned with what happens to the site each month, rather than where it lives or how quickly it loads. If the site is slow today rather than simply unattended, the speed page is the closer fit — and if nobody is certain where it is even hosted, start there instead.
Questions
Asked before a plan is signed.
From AED 1,500 a month for a small business site — updates, backups and monitoring. A plan carrying a real block of retained hours and monthly reporting is AED 6,500, and a site needing a dedicated squad and SLA-backed response is AED 15,000. All exclude 5% VAT. What moves you between them is how often the site changes and what downtime costs you, not page count.
A monthly plan. AMC stands for annual maintenance contract — the term itself denotes a twelve-month agreement, usually paid in instalments; ours runs month to month at the same monthly figure, with no annual commitment attached to the price. When you compare quotes, the number to read is not the headline: it is how many hours are included, what counts as chargeable extra, and whether the response target is written down or implied.
They are a block of engineering time each month for the work that is too small to quote — a new page, a form field, a price change, replacing a plugin that has been abandoned upstream. Time is logged against each request rather than reported as a monthly total, so you can see where it went. If the block goes unused month after month, the plan is the wrong size and we will say so.
WordPress and WooCommerce, Shopify, headless builds on Sanity or Payload, and custom Next.js or React sites — the same stack we build on, which is the honest boundary. What matters more than the platform is whether there is version control and a repeatable way to deploy. Where a site can only be edited through a closed dashboard, a plan can watch and update it, but it cannot change much safely.
No — the two are priced separately, because plenty of clients want one without the other. A plan on hosting we run is a shorter arrangement: we already know where the backups land, how staging works, and who to call when the server itself is the problem. On hosting you keep, we tell you up front where your provider limits what the plan can promise.
Yes, and the additional work is checking rather than translating. Every update is verified in both language trees, because a theme or plugin release that looks correct in English can break right-to-left layout — mirrored navigation, form alignment, or an Arabic typeface quietly falling back to something never designed for it. Writing the Arabic copy itself is content production and is quoted separately.
What changed, what it used in hours, and what we would do next. Specifically: which updates were applied and which were held back with the reason, the date of the last verified restore, uptime and any errors worth a sentence, renewal dates coming up, and an itemised list of where your retained hours went. It runs to a page or two and is written by the engineer who did the work.
Not as a substitute for a plan. There are three ways to work with us — a fixed-scope project, a dedicated squad, or a care plan — and none is open-ended break-fix. The reasoning is practical rather than commercial: fixing a site nobody has been maintaining means learning it under pressure, on the day it is down, which is the most expensive hour to start from.
Ready to build something that lasts?
Tell us what you need. You will get a scoped response with an indicative price — from an engineer, not a salesperson.