Website costs after launch: operating budget, account owners and support scope

Paying for development finishes the creation project, not the operation of a website. Domains expire, services need paying, content changes and errors need noticing and fixing. The main risk is often missing ownership rather than one tariff: an invoice reaches a former employee, a backup is untested or access remains with a contractor. Before launch, collect an expense and account register. It helps plan spending, transfer work and distinguish included support from tasks requiring another estimate.

1. Estimate the first year, not one month

Separate annual, monthly, usage-based and one-off costs. A planning formula combines yearly payments, monthly payments for the period, actual consumption and agreed changes. Record currency, taxes shown in invoices, payment dates and renewal terms. Do not multiply a first-month promotional tariff by a whole year without checking. Use current proposals from your providers and your expected workload instead of a supposed market average. Show assumptions that could alter the total, and keep development separate from the budget required to operate it.

2. Confirm who owns the accounts

The owner should control billing and recovery while the contractor receives the access needed for work. Avoid making a departing employee’s personal email the only login route. Test an alternative recovery method and keep secrets in an agreed secure place. When changing contractors, confirm handover and operation before revoking unnecessary permissions. If a licence cannot be transferred, discover that restriction before purchase rather than after a team change. Account ownership is a practical part of acceptance, not just an item on an invoice.

3. Separate infrastructure and licences

Hosting, storage, database, email, CDN and monitoring can be separate charges or one plan. Check what exceeding a limit causes: extra fees, suspension or a restricted function. Record licence dates and the effect of not renewing paid modules. HTTPS also requires certificate management: automatic renewal depends on working configuration and monitoring. An infrastructure invoice is not an application-maintenance agreement. The server supplier may not maintain your forms or integrations, so name the person responsible for investigating failures beyond server availability.

4. Distinguish warranty from changes

A warranty defect is a departure from accepted scope. A new promotion, page, language or delivery rule usually changes that scope. Define included tasks, estimate approval, working hours and incident response. “Everything included” without a list does not help agree work. Assign an author and approver for regular content; a technician should not guess new commercial terms. Test changes in a safe environment and publish through an agreed process. Keep a record of decisions so the business can distinguish a correction from a new request.

5. Budget for the ability to recover

A backup is useful when the team can restore the site and required data. Define what is copied, where it is held, who has access and how much data loss the business could tolerate. Set frequency according to changes and consequences rather than a universal rule for every site. Restore into a separate environment and record the result. WordPress needs files and its database; another architecture needs its developer to define the backup set. A copy on the same damaged server does not address every failure.

6. Run a short operating review

1. Review upcoming payments, domain dates and licences.
2. Check enquiry forms, notifications and the chosen payment workflow.
3. Inspect errors, availability and tariff-limit use.
4. Confirm backups and current recovery instructions.
5. Remove unnecessary access and check the incident contact.
6. Agree the queue of content and functional changes.

Review frequency follows the site’s criticality and pace of change. Reporting needs observations and actions: what failed, who fixes it and which costs change. A green server status does not replace a real enquiry test. Agree support at https://samsa.agency/en/services/website-support ; estimate substantial redevelopment separately through https://samsa.agency/en/services/web-development.

7. Record exclusions and the next budget

Clarify whether translation, design, new integrations, ads, paid placements and work outside agreed hours are included. Do not combine support, content production and marketing into one undefined line. Set a change allowance from approved tasks and their value rather than an invented mandatory percentage. Before renewing, check which services are actually used. Remove an unnecessary tool only after checking dependencies, data export and termination conditions. Savings should not interrupt a functioning site or make its data impossible to retrieve.

Official sources checked on 14 October 2026: Let’s Encrypt certificate information — https://letsencrypt.org/docs/faq/ ; WordPress backup contents — https://developer.wordpress.org/advanced-administration/security/backup/ . The expense examples are categories for your own register, not current service tariffs or a universal website architecture.