Measure recurring maintenance before approving another repair
A useful WordPress maintenance budget starts with evidence from your own website: what failed, how long it took to investigate, what the repair cost, and whether the same problem returned. A cheaper individual fix is not always the cheaper operating plan, but the cost of a rebuild cannot be justified by frustration alone.
This guide focuses on estimating and controlling the next 90 days of maintenance. If you first need to choose between a rebuild and a cleanup, use our rebuild versus content cleanup guide, then return here to make the chosen work measurable.
1. Create an incident ledger with a defined owner
Record each failure in one place. Separate new improvements from actual defects so feature requests do not inflate the apparent cost of maintaining the existing website. Give every incident an owner and a short description of its impact on a visitor or the team.
- The date, affected page or workflow, and the symptom reported.
- Investigation time, implementation time, and the person responsible.
- Any external invoice or recurring tool charge directly connected to the repair.
- The cause found, the test performed, and whether the issue recurred.
For example, three reports of missing enquiry emails may represent one unresolved delivery problem rather than three unrelated tickets. Connect those incidents before commissioning three separate fixes. Do not estimate lost revenue unless you have reliable records to support the calculation.
2. Group the work by urgency and type
Use three maintenance buckets: restore an essential function, prevent a demonstrated repeat failure, and improve an existing experience. A broken checkout or contact form needs a different response from a cosmetic spacing change. State what continues to work while each item waits.
For each item, ask the implementer for a bounded scope, assumptions, a test plan and an estimate range. If the cause is still unknown, approve a diagnostic stage first. Avoid treating an uncertain investigation as a guaranteed fixed-price repair.
3. Compare costs on the same basis
For the 90-day window, list planned maintenance labour, known provider charges, regression testing and a contingency chosen for your setup. Keep new functionality separate. A practical comparison is:
90-day maintenance estimate = planned repair work + preventive work + testing and handover + relevant recurring charges + an explicit uncertainty allowance.
This is a planning structure, not a market price. The size of each component depends on the site, access available, integrations and support agreement. Record both the estimate and the actual result so the next planning cycle improves.
4. Define acceptance checks before work begins
A repair is complete when the affected visitor journey works and its result can be verified. For an enquiry form, check a valid submission, database storage, notification status and the confirmation shown to the visitor. For an online store, include the appropriate test-order and stock-handling scenarios agreed with the owner.
Test changes in a safe environment when available, confirm the restore route, and repeat the relevant checks after release. Document any limitation that remains instead of marking the whole website as tested from one successful page load.
5. Review the budget at 30, 60 and 90 days
Compare the incident ledger with the work completed. Look for repeated causes, unresolved investigations and time spent maintaining a workaround. Repeated effort is a reason to investigate the underlying structure; it does not automatically prove that a rebuild is necessary.
Finish the review with three decisions: what can close, what needs a separate project, and who owns ongoing monitoring. This creates a maintenance plan the business can evaluate without relying on vague promises about a faster or cleaner website.
Explore our WordPress implementation services or request a review of a recurring website problem.