How to Allocate Your Budget for a New Business Website
A new business website's budget splits into eight cost categories, not one number: domain and hosting, platform ownership, design and content, accessibility, performance, security, analytics, and ongoing maintenance. Skipping a category doesn't remove its cost. It defers the cost to whoever discovers the gap later, usually a customer, an auditor, or a search engine.
Why a category framework beats a single number
Most budgeting advice for a new website starts with a dollar figure and works backward. That approach breaks the moment the business's actual requirements, a regulated product, an accessibility obligation, a multi-region audience, don't match whatever generic figure the advice assumed.
A category framework works the other way. It names every cost center a website genuinely has, lets a business decide how much each one deserves based on its own risk and priorities, and makes the trade-offs visible instead of hidden inside one lump budget line.
Category one: domain and hosting ownership
A domain name is a lease, not a purchase. ICANN's own registration process documentation describes registrars as intermediaries who accept registration requests on behalf of registry operators, and registrants as the ones who must keep contact information current for as long as the domain is held (ICANN — The Domain Name Registration Process). Budget for renewal every year the business exists, not as a one-time cost.
Hosting is a recurring decision, not a one-time purchase either. Whether a business chooses a fully managed platform or a hosting provider it manages itself changes what other categories, security patching, uptime monitoring, cost.
TLS is now a baseline cost, not an upgrade
Let's Encrypt's automated certificate issuance made TLS effectively free and largely maintenance-free through the ACME protocol, which lets a server prove domain control and receive a browser-trusted certificate without manual renewal (Let's Encrypt — How It Works). There's no longer a good reason to budget HTTPS as a premium line item; budget instead for confirming the hosting or platform choice actually automates renewal.
Data portability belongs in this category, not as an afterthought
A platform choice made purely on today's launch cost can quietly become a switching-cost problem later. WordPress's own export tooling, for instance, is documented as a core feature specifically because content portability was a deliberate design goal of the platform, not every CMS treats it the same way.
Budgeting a few extra hours to confirm how a platform exports its own content, before committing to it, is cheap insurance against a much larger migration bill years later.
Category two: platform and CMS ownership model
The platform decision determines who owns security patching for the life of the site. Self-hosted WordPress requires the site owner or their host to apply core and plugin updates on their own schedule, per WordPress.org's own documentation on site requirements (WordPress.org — Requirements). A fully hosted platform bundles that patching into the subscription instead.
Neither model is free. Self-hosting trades a subscription fee for an ongoing maintenance obligation; a hosted platform trades ownership and customization ceiling for a predictable recurring cost. Budget for whichever trade-off matches the team's actual capacity to do maintenance work, not the one that looks cheapest on day one.
Category three: design, content, and accessibility together
Design and accessibility aren't separate budget lines that compete with each other. The Web Content Accessibility Guidelines define specific, testable success criteria, color contrast ratios, keyboard operability, text alternatives for non-text content, that a design has to satisfy regardless of how it looks (W3C — WCAG 2.2).
Building to those criteria from the first design pass costs far less than retrofitting an inaccessible site after launch. Budget accessibility review as part of the design phase, not as a post-launch remediation project.
Accessibility retrofitted after launch costs more than accessibility designed in from the start, because retrofitting means re-touching components, color systems, and markup that were never built to satisfy WCAG's success criteria in the first place.
Category four: performance as a budget line, not an afterthought
Google's Core Web Vitals define the specific metrics, loading, interactivity, visual stability, that measure whether a site performs well for real users, and they factor into how Google evaluates page experience (web.dev — Web Vitals). A slow site isn't a cosmetic problem; it's a measurable one with a defined set of thresholds.
Budget performance work as its own line: image optimization, font loading strategy, and script weight all cost design or development time up front, and all show up later as Core Web Vitals scores a business can actually measure against.
Category five: security posture from day one
The OWASP Top Ten catalogs the most critical categories of web application security risk and functions as the standard reference point developers and reviewers use to evaluate a site's security posture (OWASP — Top Ten). It applies to a five-page brochure site handling a contact form just as much as it applies to a full storefront.
Budget security review proportional to what the site actually handles: a static content site needs less scrutiny than one processing customer data or payments, but neither needs zero.
What "proportional" actually means in practice
A contact form still needs input validation and protection against automated spam submission, categories the OWASP Top Ten covers under injection and security misconfiguration risks. A site that stores customer accounts or processes payments directly needs a much deeper review, covering authentication, session handling, and access control on top of the basics.
Budget the review to match which of those two profiles the site actually is, and revisit the review scope any time a new feature, a login area, a payment form, a file upload, changes which profile applies.
Category six: analytics and measurement setup
A website without measurement is a business decision made blind. Setting up Google Analytics 4 involves creating a property, configuring a data stream, and installing the resulting tag, a process Google documents directly rather than leaving to third-party guesswork (Google Analytics Help — Set up Analytics for a website and/or app).
Budget this as setup time plus a recurring review habit, not a one-time installation task. A dashboard nobody looks at after month one isn't worth the setup cost.
Category seven: ongoing maintenance and backups
WordPress.org's own advanced administration documentation recommends backing up both the database and the site's files, with backup frequency scaled to how often content changes, weekly for low-activity sites, daily for high-activity ones (WordPress.org — Backups). The same principle applies regardless of platform: backup frequency should track content change frequency, not a fixed calendar habit picked without reference to the site's actual activity.
Budget maintenance as a recurring line whether the platform automates it or not. A hosted platform that runs backups automatically still deserves a periodic check that the backups actually restore.
Category eight: contingency, without a manufactured percentage
Every one of the seven categories above can run over its estimate: a design revision cycle takes longer than planned, an accessibility audit surfaces more fixes than expected, a security review flags something that needs remediation before launch. A contingency reserve exists to absorb exactly that kind of overrun.
Rather than picking an arbitrary percentage figure with no source behind it, size the contingency against the categories carrying the most uncertainty for the specific project, usually accessibility remediation and security review, since both depend on what an audit finds rather than what was scoped upfront.
How the weighting shifts for a storefront versus a brochure site
The eight categories are the same regardless of what the site sells, but a commerce site and a five-page brochure site should not weight them the same way. A storefront processing payments needs a heavier security and performance budget than a brochure site describing services, because the failure cost of each category is different in each case.
Where a storefront should over-invest
Security review and performance both deserve a larger share of a commerce budget, since a slow checkout directly costs revenue and a security gap directly risks customer payment data, not just reputation. Accessibility carries the same weight either way, WCAG's success criteria don't scale down for a smaller site.
Where a brochure site can reasonably spend less
A brochure site with no accounts, no payments, and no user-submitted content beyond a contact form can budget a lighter security review and a simpler analytics setup, page views and form submissions instead of full event tracking and conversion funnels. The domain, hosting, accessibility, and maintenance categories still apply in full; they don't shrink just because the site is simpler.
Comparing where the risk sits across ownership models
| Category | Fully hosted platform | Self-hosted / custom stack |
|---|---|---|
| Security patching | Bundled into subscription, automatic | Owner's responsibility, needs a schedule |
| Customization ceiling | Bounded by the platform's extension points | No platform-imposed ceiling |
| Accessibility ownership | Shared with platform's base components | Fully on the design and dev team |
| Backup responsibility | Often automated by the platform | Must be configured and periodically tested |
A sequencing checklist before finalizing a budget
- Decide the platform ownership model first, since it determines who's responsible for four of the eight categories.
- Fold accessibility into the design budget, not into a separate post-launch line.
- Set a performance target using Core Web Vitals thresholds before design starts, not after launch.
- Scope security review proportional to what the site actually handles, contact form only versus payment processing.
- Size contingency against the categories with the most audit-dependent uncertainty, not a flat percentage.
The categories that get skipped in a rushed budget, accessibility, security review, backup verification, are exactly the ones that cost the most to fix after the site is live and something has already gone wrong.
FAQ
Should accessibility be a separate line item from design?
No. WCAG's success criteria apply to color, layout, and markup decisions made during design itself. Separating the two invites a retrofit instead of a design that satisfies them from the start.
Does choosing a fully hosted platform eliminate the security budget line?
It eliminates patching work, since the platform handles that automatically, but it doesn't eliminate the need to review what the site itself does with customer data, forms, and any third-party scripts added later.
How often should backups actually run?
Scale frequency to how often content changes. A rarely updated brochure site needs less frequent backups than a site with daily content or transaction activity.
Is a fixed contingency percentage a reasonable default?
Only as a rough placeholder. A better approach sizes contingency against the categories most likely to surface unplanned work, typically accessibility remediation and security findings.
Does a free TLS certificate mean security is fully solved?
No. TLS covers transport encryption between browser and server. It says nothing about application-level risks like the ones OWASP's Top Ten catalogs, injection, broken access control, and misconfiguration.