HubDB vs Static Pages on a Multi-Site Build

This decision gets made on instinct and it should be made on arithmetic, because the two options have completely different cost shapes.

In our own project data, a HubDB-driven build lands around 20 to 30 hours, once. Hand-building the equivalent static pages adds roughly 80 to 100 hours for each additional site. Those are not two prices for the same thing; they are a fixed cost and a recurring one, and the crossover arrives sooner than most agencies assume.

The shape of each cost

Static pages are cheap to start and linear forever. The first site costs what it costs. The second costs nearly the same again, because the work is the pages, and there are just as many of them. A structural change later, a new section, a schema block, a compliance line in the footer of every location page, is paid once per page per site.

HubDB is a table, a dynamic template and a routing setup. Most of the cost is the first build: designing the table, writing the template, handling the listing and detail views, and loading the content. The second site reuses the template. A structural change is made once and appears everywhere.

So the question is not "which is cheaper" but "how many times am I going to pay this."

Sites	Static (cumulative)	HubDB (cumulative)
1	baseline	20 to 30 hours
2	+80 to 100	roughly flat
3	+160 to 200	roughly flat

Those static figures are the additional hours per site from our delivery data, not a full site build. The point is the slope, not the intercept.

Where the crossover actually sits

Between the second and third site, in our experience, and often at the second once you count the first structural change.

That is earlier than the instinct in most agencies, which is to reach for HubDB only on genuinely large builds. The reason the instinct is wrong is that it prices the initial build and ignores the maintenance, and maintenance is where multi-site work actually consumes margin.

A worked example that comes up constantly: a client with several regional sites, each carrying location or service pages that differ only in their content. Built statically that is a few hundred pages, and every one of them is a thing somebody has to touch when the phone number format changes.

When static is still right

HubDB is not a default, and reaching for it on the wrong project is its own kind of expensive.

When the pages genuinely differ. The test is structural, not numerical. Twenty pages that share a shape are a HubDB table. Twenty pages that each need their own layout are twenty pages, and forcing them through a template produces a fight you lose slowly.

When there is one site and no roadmap for more. Pay the linear cost, keep the simplicity.

When the client's team edits pages directly and always will. HubDB moves editing from a page editor into a table, which is a real change in how the client works. Some teams take to it immediately. Some never do, and a system the client will not use is worse than a slower one they will.

When the content is genuinely bespoke marketing copy. Templated structures encourage thin, near-duplicate content, and that is a real risk on the SEO side rather than an imaginary one.

The second-year argument, which is the strongest one

The hours comparison above understates the case, because it prices the build and not the life.

Consider what happens when the client asks for a change that touches every page of a type: adding a schema block, a new call-to-action, a disclaimer, a field on the listing. On static pages that is the page count times a few minutes, per site, plus the QA. On HubDB it is one template edit and a republish.

We have watched an agency spend more on the third year of maintenance for a static multi-site build than the HubDB version would have cost to build outright. Nobody noticed, because the maintenance arrived as a series of small, individually reasonable tickets.

If you are pitching this internally or to a client, that is the argument that lands: the build cost is a rounding error next to the maintenance cost, and only one of the two options has a flat maintenance curve.

What the build actually contains

If you are quoting the 20 to 30 hours, know what is inside it, because clients ask:

• Table design. Columns, types, and the decision about which fields are structured versus rich text. Getting this wrong is the most expensive mistake available, because changing it later means touching every row.
• The dynamic template, including the listing view, the detail view and the empty state.
• Routing and URL structure. Decide this once and defend it, because the URLs are the part you cannot change cheaply after launch.
• Content load. Usually an import, which brings all the ordinary import rules with it: HubSpot creates or updates and never appends, so repeated rows overwrite rather than accumulate.
• QA across the row set, not just on one row. Templated output fails on the unusual rows: the one with no image, the one with an apostrophe in the name, the one with three lines of address.
• Editor documentation. Somebody has to know how to add a row after you leave.

That last item is the one most often cut and most often regretted.

The two failure modes, and how each one looks

Both choices fail in a characteristic way, and recognising the shape early is worth more than getting the decision right first time.

Static, failing. The symptom is ticket volume rather than any single incident. Small change requests arrive constantly and each one is individually reasonable: update the phone number on the location pages, add the new accreditation logo, change the enquiry form. Each is quoted at a couple of hours and each is honest. The margin leaks in aggregate, and because no single ticket looks wrong, nobody escalates. If you are looking for evidence, count the tickets against one page type over a quarter and multiply.

HubDB, failing. The symptom is the client not using it. Rows go stale because updating content means opening a table rather than a page, and the person who owns the content was never comfortable with that. Six months later somebody has started building one-off static pages alongside the HubDB set "just for this one," and now you maintain both. This failure is quieter and more expensive, because it produces two systems where you budgeted for one.

The tell for the second one is worth watching for at handover: if the client's content owner cannot add a row unaided while you are still on the call, they will not do it after you leave.

Migrating between them later

Sometimes the decision was made before you arrived and it was wrong. The direction of travel matters.

Static to HubDB is a rebuild, not a migration. Content has to be extracted from the pages into table rows, which is straightforward only if the pages were built consistently, and they never were. Budget for cleaning the content as well as moving it. URLs have to be preserved exactly or redirected, and this is where these projects go wrong: a rebuild that changes the URL structure and does not carry redirects will lose the rankings the client came to you with.

HubDB to static is unusual and usually a symptom. If a client wants out of HubDB, the reason is almost always the adoption failure above rather than a technical limit. Fix the training before you rebuild the architecture; the rebuild will not solve a workflow problem.

Either way, the sequence is the same: agree the URL map first, in writing, then move content, then redirect, then verify by requesting the old URLs rather than reading the redirect table.

Deciding it in ten minutes

Five questions, answered with the client in the room:

1. How many sites, over three years? Not today. The answer to this question alone decides most cases.
2. Do these pages share a structure, or only a purpose? Structure means HubDB. Purpose alone does not.
3. Who edits them, and how comfortable are they with a table?
4. How often does the structure change? A page type that changes twice a year is a HubDB argument on its own.
5. What is the URL structure, and is it settled? If it is not settled, settle it before building either option.

If questions one and two both point to HubDB, the rest is confirmation.

The bottom line

HubDB costs 20 to 30 hours once. Static pages cost 80 to 100 more per additional site, and keep costing on every structural change. The crossover sits between the second and third site, and earlier once maintenance is counted.

Choose static when pages genuinely differ in structure or when there is only ever one site. Choose HubDB when the shape repeats, and decide before the content exists, because reversing it is a rebuild rather than a migration.

If your agency sells multi-site or multi-location work and would rather not carry the build risk, our white-label web design team delivers these under partner brands, and the DNS cutover runbook covers getting them live once they are built.