What does website maintenance include?

Bug fixing, CMS support, plugin and platform updates, security and backup checks, form testing, speed monitoring, tracking review, content and landing-page edits, image optimisation, technical support, a regular health check and emergency fixes. What applies to a particular site is agreed when the engagement is set up.

What is website maintenance, in plain terms?

Keeping a finished thing working in an environment that will not hold still. The counter-intuitive part is that nobody has to touch your site for it to break — the code can be identical to the day it launched and the site can still have stopped doing its job.

What is the difference between maintenance and a retainer?

One question separates them: did this used to work? If it did, it is maintenance. If nobody has ever done it before, it is new work and belongs in a retainer or a project. Businesses running both usually find the boundary sorts itself out on that test alone.

What is the difference between maintenance and new development?

The same test, applied to a request rather than a fault. Restoring something is maintenance; changing what the site is meant to do is development. The grey area is real, and it gets agreed before work starts rather than argued about in an invoice.

Can Branditify maintain a website it did not build?

Usually — most maintenance work is on sites somebody else built. What decides it is not who wrote it but whether it can be worked on safely: is there anywhere to test a change, and can access actually be handed over. A first look answers both before anything is agreed.

Do updates get installed automatically?

No, and auto-update is the most common cause of the calls that start with “nobody touched anything”. Security fixes move quickly; anything that could reach a flow you depend on waits until it has been tried somewhere that is not your live site.

Are updates tested before they go live?

The ones that matter, yes — applied away from the live site and run against the flows they could affect, then verified on the real thing afterwards. How much testing each update is worth depends on the platform and on what the site does.

Does maintenance include security?

It includes security checks and applying relevant platform and plugin updates, and reviewing whether known issues apply to your site. It is upkeep rather than a security audit: no penetration testing, no monitoring centre, and no guarantee — anyone offering one of those on a maintenance page is overselling it.

Does maintenance include backups?

It includes checking that a recent backup exists and can actually be restored from — deliberately a different claim from running your backup system. Plenty of sites have a backup nobody has ever restored, which is a file rather than a safety net, and the distinction only ever surfaces on the worst possible day.

What happens if a third-party provider changes something?

That is one of the most common causes of a live site quietly breaking, and it is squarely maintenance work: find where the chain broke, identify what changed, apply the fix and verify against the real flow rather than against a page loading.

Can maintenance include new features?

Small improvements often fit. Anything that changes what the site is meant to do — a new step in a process, a new language, a redesigned page — is better scoped on its own, either as project work or through an ongoing retainer.

When is a rebuild better than maintenance?

The symptom to watch for is fixes that keep breaking other things. One or two is normal; a pattern of it means the structure is working against you and the monthly fee is buying time rather than progress. That is the point at which we would say so.

What access does Branditify need?

Enough to fix a thing and then prove it is fixed — the second half is what people underestimate. Verifying a form actually delivers needs more than the CMS login. Whatever cannot be granted gets named as outside our responsibility rather than quietly assumed.

Who owns the site and the accounts?

You do, throughout. The practical test is whether you could hand the site to somebody else tomorrow without asking us for anything — which is why a record of what changed is kept, and why accounts sit in your name rather than ours.

How quickly do issues get fixed?

Reproducibility decides it more than anything else — an issue that happens every time is usually an afternoon, and one that happens sometimes can take days to even see. No response-time figure is published here, because a truthful one would be a range wide enough to be meaningless.

What determines the size of a maintenance engagement?

The condition of what is already there, more than its size. A tidy build with somewhere to test changes is cheap to look after at almost any scale; a fragile one is expensive at any scale, because every change has to be approached carefully.

What happens when maintenance starts?

A first pass that almost always finds something nobody knew about. That initial list is usually the most valuable thing in the first month, and it is worth budgeting for the fixes it produces rather than treating the engagement as steady-state from day one.

Website maintenance & support

Nothing was down. The enquiries still stopped.

Branditify maintains live websites — the fixes, updates and compatibility work that keep the things your business actually depends on working, while plugins, providers, browsers and requirements keep changing around them.

See what a check covers

Meridian ToolsLive site · monthly check

Live

Pages loadEvery page returns, on the current browsers.Healthy
SpeedNo slower than last month.Healthy
Certificate and headersValid, renewing, nothing expiring soon.Healthy
A backup existsPresent, recent, and restorable — checked rather than assumed.Healthy
CMS and pluginsTwo updates available. One touches the checkout.Watch
Analytics still recordingTags firing, goals still attached to the right events.Healthy
Enquiry form reaches the teamSubmitting. Saving. Not arriving.Healthy
Search ConsoleNo new coverage or indexing errors.Healthy

Everything is fine

Everything on this site is working. One thing on it is not, and nothing about the site being up would tell you which.

Behind that one line

Customer fills the formTypes their name, their number and what they need.
The site accepts itFields validate. The thank-you message appears.
The enquiry is savedWritten to the database with a timestamp. Still there today.
The team gets notifiedThe email provider rejects it. Nothing is shown to anyone.
Somebody repliesNever happens, because nobody knew there was anything to reply to.

Before changing anything

Did the form submit?Yes. The browser shows the success state.
Was the enquiry saved?Yes. Eleven of them, over six days.
Was a notification attempted?Yes, every time.
Did the provider accept it?No. Rejected, with a reason nobody was reading.
What changed, and when?The provider began requiring a verified sender domain. Six days ago.

The fix

Verify the sending domain, update the sender address, and re-send the eleven that were waiting.

Then submit the form as a customer would and confirm a real message arrives — because the only proof a form works is a message somebody received.

A live site, and a monthly check.

Illustrative live website · sample data

After launch

The site is finished. Everything around it is not.

Nobody touched the code. It stopped working anyway.

Website maintenance is the ongoing work needed to keep an existing site healthy as content, plugins, dependencies, browsers, devices, third-party providers and business requirements change around it. What a specific engagement covers depends on what that particular site relies on.

Browsers and devices: Update on their own schedule, and occasionally change how something renders or behaves.
The CMS and its plugins: Release updates. Some are security fixes; some change behaviour you were relying on.
Third-party providers: Email, payments, maps, chat, analytics — each one can change what it requires without asking you.
Dependencies: The packages the site was built on keep moving, and old versions eventually stop being supported.
Your own content: Pages get edited, images get uploaded at the wrong size, links point at things that moved.
What the business needs: The form that was fine last year now feeds a process that did not exist then.

None of this is anybody doing anything wrong. It is what happens to a live thing sitting in an environment that keeps moving, and it is the entire reason maintenance exists as a service.

Does every website need maintenance?

No. A small brochure site on a managed platform that nobody edits can go a long way on very little. It becomes worth paying for when the site does a job — takes enquiries, sells something, books something — because that is the point at which a quiet failure costs more than the upkeep.

The chain

One button. Five things behind it.

Select a link to see what it was doing.

A visitor sees one button. Behind it, several separate things have to work in order — the page, the validation, the record being saved, the notification being sent, and somebody actually receiving it. A site can pass every availability check while one link in that chain is failing, because most checks look at whether pages load rather than whether the job completes.

Customer fills the formHealthy

Types their name, their number and what they need.

The site accepts itHealthy

Fields validate. The thank-you message appears.

The enquiry is savedHealthy

Written to the database with a timestamp. Still there today.

The team gets notifiedAction needed

The email provider rejects it. Nothing is shown to anyone.

Somebody repliesAction needed

Never happens, because nobody knew there was anything to reply to.

HealthyChecked, working as expected.
WatchWorking, but something has changed that will need attention.
Action neededNot doing its job. This is the one that costs something.
FixingCause identified, change being made.
VerifyingChange applied, being tested against the real flow.

Four of the five links worked flawlessly for six days. The one that failed was the only one with a person on the other end of it.

There is no health percentage on this page and no uptime figure. A number like that would have read as healthy for the whole six days, which is precisely the problem it is being used to hide.

Diagnosis

Find out what happened before changing anything.

Five questions, in order, none of them a guess.

The first job is to establish where the chain actually broke rather than to start changing things. That means reproducing the problem, checking each step in order, and identifying what changed and when — because a fix applied to the wrong step tends to create a second problem alongside the first.

Did the form submit?Yes. The browser shows the success state.
Was the enquiry saved?Yes. Eleven of them, over six days.
Was a notification attempted?Yes, every time.
Did the provider accept it?No. Rejected, with a reason nobody was reading.
What changed, and when?The provider began requiring a verified sender domain. Six days ago.

The fix

Verify the sending domain, update the sender address, and re-send the eleven that were waiting.

Then submit the form as a customer would and confirm a real message arrives — because the only proof a form works is a message somebody received.

The temptation with a broken form is to rebuild the form. The form was fine. Rebuilding it would have taken a day and changed nothing.

The consequence

Six days. Eleven enquiries. Zero alerts.

Every automated check was green throughout.

A website can be completely available and still not be doing its job. Availability monitoring answers whether a page loaded; it does not answer whether the enquiry reached anybody, whether the payment confirmation sent, or whether the booking created a record. Those are the things a business notices last and misses most.

What was green the whole time

The site responded on every request
Every page returned normally
The certificate was valid
The form displayed its success message
Nothing appeared in any error report

What was actually happening

Eleven people filled the form and were told they would be contacted
Eleven records saved correctly and sat unread
Nobody on the team knew there was anything to open
The first anyone heard was a customer following up by phone

This is the argument for maintenance in one line: the site never went down, and the business still lost six days of enquiries. Checking that pages load is not the same as checking that the site does its job.

When the work is new rather than broken

Which kind of work

A fix restores. An improvement changes.

The distinction decides where the work belongs.

Maintenance keeps existing agreed behaviour working: something that used to happen has stopped, and it is restored. New development changes what the site is expected to do. Small improvements can sit inside an ongoing support arrangement; larger ones usually deserve their own scope, because they need deciding rather than just doing.

The enquiry notification stopped arrivingMaintenanceIt used to work. Restoring it is maintenance.
Add an approval step before the team is notifiedA changeNew behaviour that did not exist. That is a change, not a repair.
A page got slower after an image uploadMaintenanceExpected performance regressed. Maintenance.
Redesign the enquiry page to convert betterA changeA different outcome is wanted. Its own piece of work.
A plugin update broke the layout on mobileMaintenanceSomething that worked stopped. Maintenance.
Add a second language to the siteA changeA new capability, with its own scope and decisions.

The honest version of the line is that it is not always obvious, and it gets agreed rather than assumed. What matters is that both sides know which one a piece of work is before it starts.

Updates

An update is a change, and changes get tested.

Two updates were available. One of them touches the checkout.

Updates are applied deliberately rather than automatically. A security update usually goes on quickly; an update that touches something the business depends on is tested against that flow first, because installing everything the moment it appears is how a working site becomes a broken one on a Friday afternoon.

See what is availableAnd what it actually changes, rather than only the version number.
Sort itSecurity fix, behaviour change, or neither. They do not get treated the same.
Test the ones that matterApply it away from the live site and run the flows it could touch.
Apply itWith a way back, and not at a time that would be bad to be wrong.
Verify the real flowNot that the page loads. That the thing the page is for still works.

Which updates apply, and how much testing each is worth, depends on the platform and on what the site does. A content site and a store with a live checkout are not the same risk.

The monthly check

What else gets looked at.

Stated as what is actually done, rather than as a package.

A regular check covers the things that fail quietly: whether a backup exists and could be restored from, whether known security updates apply to this site, whether analytics is still recording, whether the forms still deliver, and whether the site has got slower. What is included is agreed per engagement rather than sold as a fixed tier.

Backups: We verify that a recent backup exists and can be restored from. That is a different claim from running your backup system, and the difference matters on the day you need one.
Security: Known updates for the platform and its plugins are reviewed for whether they apply here, then applied and verified. This is upkeep — not penetration testing, and not a guarantee anybody can honestly make.
Forms: Submitted as a customer would, and confirmed to arrive. The only reliable test of a form is a message somebody received.
Speed: Measured against the site’s own previous result, so a gradual slide shows up before somebody complains.
Tracking: Analytics and tag setup checked for whether it is still recording what it was set up to record, after site changes.
Content and images: Operational edits, page copy corrections and oversized images. New content strategy and production is a different service.

Frequency, and which of these apply, depends on the site and is set when the engagement is agreed. There is no published schedule here because there is no single one that would be true for every site.

Not the same thing

Maintenance or retainer? Same site, different job.

Plenty of businesses have both, and they do not overlap in practice.

Maintenance keeps existing behaviour working: something broke or is about to, and it gets restored. A retainer moves new and evolving work forward through a prioritised queue: new pages, new creative, new content, changes the business wants. One protects what exists, the other builds what comes next.

The same websiteMaintenanceRetainer

The enquiry form stopped notifying anyoneDiagnosed and restoredNot this — nothing new is being made

A campaign launches next monthNot this — nothing is brokenNew landing page, creative and copy

A plugin update broke the mobile layoutFixed and verifiedNot this

Add an approval step before notificationNot this — it is new behaviourScoped and built into the queue

The site has quietly got slowerMeasured, cause found, correctedNot this

The word that sits on both records is "website updates", and it means two different things. Here it means the site keeps working. There it means the site keeps changing.

Growth Retainers

The honest answer

Sometimes maintenance is the wrong recommendation.

Four possible answers after looking at what is actually there.

Maintenance makes sense while a site is fundamentally serviceable — the platform still supports what the business needs and the work is upkeep. A rebuild is the cleaner answer when the platform no longer supports the requirements, when the architecture blocks changes the business keeps asking for, or when the site is fragile enough that every fix risks something else.

KeepIt is doing its job. Regular checks, updates applied deliberately, and nothing else.
FixSpecific things are broken or degraded. They get repaired, and then it is a Keep.
RefactorThe site is worth keeping but one part of it fights every change. That part gets rebuilt, not the site.
RebuildThe platform or the structure no longer supports what the business needs. Maintenance would be paying to defer the decision.What a rebuild looks like

We would rather say a site needs rebuilding than take a maintenance fee for keeping something alive that is holding the business back. That recommendation costs us the engagement, which is roughly the point of it being worth anything.

Inherited sites

Can you maintain a site you did not build?

Usually. It depends on what is actually there, which is what the first look is for.

Yes, in most cases — Branditify maintains sites on WordPress, Webflow, Shopify, Next.js and Sanity, whoever originally built them. What is confirmed first is what the site runs on, what access exists, what condition it is in and what it depends on, because agreeing to maintain something nobody has looked inside is not a service, it is a hope.

Look at what is thereThe platform, the code or the build, the plugins, and the parts that are doing real work.
Establish accessHosting, CMS, repository if there is one, the provider accounts the site depends on, and the domain.
Take a baselineWhat works today, so that later there is something to compare against.
Write down what is wrongIncluding the things nobody had noticed, which is usually where the enquiry form turns up.
Agree what gets maintainedWhat is covered, what needs fixing first, and anything we would not take responsibility for as it stands.

What access is needed: Enough to do the work and verify it: the CMS or admin, hosting and deployment, the repository where one exists, and the third-party accounts the site relies on. Where access cannot be given, that part of the site is named as outside what we can be responsible for rather than quietly assumed.
Who owns what: The site, its content, its accounts and its data remain yours throughout, including anything written during the engagement. Access is for doing the work, and a record of what changed is kept so that it stays possible for somebody else to pick it up.

What this does not cover

This is website maintenance. Custom software and mobile apps built by Branditify are supported through the engagement that built them rather than here, and a system somebody else built is a conversation before it is a service. If that is what you need, the build pages are the better starting point.

Custom Software App Development

Reporting an issue

Five things turn a message into a fix.

“The checkout is broken” is a start, not a report.

The single biggest factor in how quickly something gets fixed is whether it can be reproduced. A description of what was done, what happened, and what was expected instead usually turns a day of guessing into an afternoon of fixing.

What usually arrivesThe checkout is broken.

WhereThe page it happened on, ideally the URL.
What you didThe steps, in order, including the ones that seem irrelevant.
What happenedWhat appeared on screen, including any message, word for word.
What you expectedSometimes the behaviour is correct and the expectation moved.
When and where fromRoughly when, and on what device or browser if it is only some of them.

How quickly any of this is resolved depends on how severe it is, whether it reproduces, how complex the system is, whether a third-party provider is involved and how quickly access and answers come back. No response-time figure is published here, because a truthful one would have to cover all of that.

Scope

What makes one site more work than another.

Agreed after looking. No packages on this page, because there are none in the offer.

Maintenance scope follows what the site is built on, how much it does, how many third-party services it depends on, what condition the code and content are in, how many critical flows have to keep working, and how much of the site can safely be tested before changes go live.

What it runs onA managed platform and a custom build need different work and different care.
What the site doesA brochure site and a store taking payments carry different consequences when something slips.
How many providersEvery integration is another thing that can change its requirements without warning.
Condition of what existsA tidy build is maintained. A fragile one has to be stabilised before it can be.
Critical flowsHow many journeys genuinely must not break, and how they get tested.
Where it can be testedA site with somewhere safe to try a change is cheaper to look after than one without.
Access and documentationClean handover shortens everything. Missing access is the most common cause of delay.

What we need from you to start: What the site is, what it runs on if you know, what is going wrong, which providers it depends on, and whatever access and documentation already exists.
What happens when it starts: A first look at the site, a baseline of what works today, a written list of what is wrong including the things nobody had noticed, and agreement on what is covered from then on.
If the site should not be maintained as it stands: We say so, and say what we would do instead. Taking a monthly fee to keep something alive that is holding the business back is not a service worth selling.

Background

Selected websites & systems work.

The kind of sites this work looks after, shown as delivery projects with what was actually built.

These are build projects, listed as delivered. What they establish is the kind of site being looked after — the platforms, the flows and the level of build that maintenance applies to.

All work Every project, with what was delivered on each Premium Websites When the answer is a rebuild rather than upkeep Growth Retainers When the work is new rather than broken

Questions

What businesses ask before handing a site over.

What does website maintenance include?: Bug fixing, CMS support, plugin and platform updates, security and backup checks, form testing, speed monitoring, tracking review, content and landing-page edits, image optimisation, technical support, a regular health check and emergency fixes. What applies to a particular site is agreed when the engagement is set up.
What is website maintenance, in plain terms?: Keeping a finished thing working in an environment that will not hold still. The counter-intuitive part is that nobody has to touch your site for it to break — the code can be identical to the day it launched and the site can still have stopped doing its job.
Does every website need maintenance?: No. The question to ask is what a week of silent failure would cost you. For a small brochure site nobody edits, the answer is close to nothing and the upkeep is hard to justify. For anything taking enquiries or payments, that week is the whole argument.
What is the difference between maintenance and a retainer?: One question separates them: did this used to work? If it did, it is maintenance. If nobody has ever done it before, it is new work and belongs in a retainer or a project. Businesses running both usually find the boundary sorts itself out on that test alone.
What is the difference between maintenance and new development?: The same test, applied to a request rather than a fault. Restoring something is maintenance; changing what the site is meant to do is development. The grey area is real, and it gets agreed before work starts rather than argued about in an invoice.
Can Branditify maintain a website it did not build?: Usually — most maintenance work is on sites somebody else built. What decides it is not who wrote it but whether it can be worked on safely: is there anywhere to test a change, and can access actually be handed over. A first look answers both before anything is agreed.
Do updates get installed automatically?: No, and auto-update is the most common cause of the calls that start with “nobody touched anything”. Security fixes move quickly; anything that could reach a flow you depend on waits until it has been tried somewhere that is not your live site.
Are updates tested before they go live?: The ones that matter, yes — applied away from the live site and run against the flows they could affect, then verified on the real thing afterwards. How much testing each update is worth depends on the platform and on what the site does.
Does maintenance include security?: It includes security checks and applying relevant platform and plugin updates, and reviewing whether known issues apply to your site. It is upkeep rather than a security audit: no penetration testing, no monitoring centre, and no guarantee — anyone offering one of those on a maintenance page is overselling it.
Does maintenance include backups?: It includes checking that a recent backup exists and can actually be restored from — deliberately a different claim from running your backup system. Plenty of sites have a backup nobody has ever restored, which is a file rather than a safety net, and the distinction only ever surfaces on the worst possible day.
What happens if a third-party provider changes something?: That is one of the most common causes of a live site quietly breaking, and it is squarely maintenance work: find where the chain broke, identify what changed, apply the fix and verify against the real flow rather than against a page loading.
Can maintenance include new features?: Small improvements often fit. Anything that changes what the site is meant to do — a new step in a process, a new language, a redesigned page — is better scoped on its own, either as project work or through an ongoing retainer.
When is a rebuild better than maintenance?: The symptom to watch for is fixes that keep breaking other things. One or two is normal; a pattern of it means the structure is working against you and the monthly fee is buying time rather than progress. That is the point at which we would say so.
What access does Branditify need?: Enough to fix a thing and then prove it is fixed — the second half is what people underestimate. Verifying a form actually delivers needs more than the CMS login. Whatever cannot be granted gets named as outside our responsibility rather than quietly assumed.
Who owns the site and the accounts?: You do, throughout. The practical test is whether you could hand the site to somebody else tomorrow without asking us for anything — which is why a record of what changed is kept, and why accounts sit in your name rather than ours.
How quickly do issues get fixed?: Reproducibility decides it more than anything else — an issue that happens every time is usually an afternoon, and one that happens sometimes can take days to even see. No response-time figure is published here, because a truthful one would be a range wide enough to be meaningless.
What determines the size of a maintenance engagement?: The condition of what is already there, more than its size. A tidy build with somewhere to test changes is cheap to look after at almost any scale; a fragile one is expensive at any scale, because every change has to be approached carefully.
What happens when maintenance starts?: A first pass that almost always finds something nobody knew about. That initial list is usually the most valuable thing in the first month, and it is worth budgeting for the fixes it produces rather than treating the engagement as steady-state from day one.

Start

Bring us the site your business already depends on.

Not a brief. Just the site, and whatever you already know about it.

What the site does: The job it does for the business — enquiries, sales, bookings, or something else
What it runs on: The platform if you know it. It is fine if you do not.
What is going wrong: Anything you have noticed, however small or intermittent
What it depends on: Email, payments, booking, chat, analytics — anything plugged into it
What access exists: Hosting, CMS, repository, provider accounts, and who currently holds them

Growth Retainers If the work is new rather than broken Premium Websites If the answer is a rebuild Ecommerce If the site is a store Selected work The kind of sites this looks after