Start with the kind of website you own
A small static website has different maintenance needs from an application with accounts, bookings and changing records. Both still depend on domains, hosting, contact routes and third-party services. List those dependencies before comparing support plans.
Ask what the business needs to keep working. A broken image is inconvenient; an unnoticed form-delivery failure may stop enquiries; an unavailable booking application can interrupt operations. Priorities and response arrangements should reflect those consequences.
| Area | Useful question |
|---|---|
| Updates | Which software is covered, and how are changes tested? |
| Backups | What is copied, how often, and has a restore been tested? |
| Monitoring | Does it check only that the site responds, or also key customer actions? |
| Forms and notifications | Who checks that submissions reach the intended destination? |
| Domains and licences | Who receives renewal notices and authorises payment? |
| Content changes | Are edits included, limited or quoted separately? |
| Incidents | Who can respond, during which hours, and what is the escalation route? |
A backup is useful only if it supports recovery
Ask what would happen if the running site or a database were lost. The answer needs to cover files, records and the configuration required to restore the service. Keep appropriate copies separate from the system they protect and control who can access them.
The acceptable gap between the latest backup and an incident depends on the site. A rarely edited brochure page and an active booking database have different needs. Agree a recovery approach rather than assuming a daily file copy is sufficient for every business.
Separate fixes, improvements and new development
A support agreement might cover faults but not a new feature. Content changes might be included up to an agreed allowance. Major upgrades, redesigns and changes forced by external systems may require separate work. Ask for those boundaries in ordinary language.
If a monthly cost seems high, identify what is actually being done and which dependencies generate work. If it seems unusually low, check what happens during an incident and who pays for recovery. There is no single useful maintenance price without the system and responsibilities being defined.
Review ownership as well as service
The business should know where the domain, hosting and important supplier accounts are held. Record authorised access and keep an exit arrangement so another supplier can take over. A lower monthly fee is not a saving if the business cannot retrieve its data or maintain the site later.
If your existing supplier is unavailable, the website handover checklist gives a sensible order for collecting access and protecting continuity. Avoid moving accounts until their relationships are understood.
Choose ongoing care or a development project
Digizu’s former pay-monthly website plans have been retired. The transition page directs ongoing website care enquiries to Sitewell. Discuss current scope and pricing there rather than relying on older advertised packages.
A substantial redesign, new booking workflow or custom tool is a development project for Digizu. Routine monitoring and optimisation are a different need. If the site is expensive to maintain because of a specific fault or outdated dependency, assess repair first; the redesign or rebuild guide helps frame that decision.
Clarify what your website needs
For a significant rebuild or application change, tell Digizu what is becoming difficult to maintain. For ongoing care, explore Sitewell’s current options using the link above.