A HubSpot website project rarely fails on design. It fails on sequencing — content arriving after templates are locked, modules built for one page instead of a system, and QA squeezed into the last two days before launch.
Hubstack runs every HubSpot CMS build through the same six stages, in the same order, for exactly that reason. The order is the deliverable: each stage removes a category of rework that would otherwise surface after launch, when it costs the most to fix.
What follows is the process we use on real engagements, including the checks we run before we hand a HubSpot portal back to a marketing team that has to live in it every week.
Stage 1 — Discovery that produces decisions, not documents
Discovery at Hubstack is scoped to answer questions the build depends on: which pages earn pipeline, which HubSpot forms and properties already exist, who edits the site week to week, and what the current site measurably does badly.
We pull the live URL inventory, the existing HubSpot portal setup and analytics together in one pass, so decisions about templates are grounded in traffic and conversion rather than preference.
The output is a one-page set of decisions — page types, template count, module inventory and owner of each content block. Anything that can't be decided here becomes an explicit assumption rather than a surprise in week four.
Stage 2 — Information architecture before visual design
We map the sitemap, navigation and internal linking model first, because HubSpot template structure follows the architecture. Deciding late that service pages need a child level means rebuilding templates, not moving a menu item.
Each page gets a defined job: capture, explain, prove or convert. That job determines which modules it needs, which keeps template count low and consistency high across the site.
Where a site has depth — services, case studies, a blog — we set the linking rules at this stage so every new page has an obvious parent and obvious siblings. It is also the cheapest moment to plan the technical SEO requirements into the structure.
Stage 3 — Module-first design in HubSpot's grain
We design a module library rather than a stack of page comps. Hero variants, proof blocks, feature grids, pricing tables, form sections and CTA bands are designed once, with defined content limits, then composed into pages.
Designing in HubSpot's grain means every module maps to real drag-and-drop fields with sensible defaults and constraints — so a marketer can build a new page next quarter without a developer, and without breaking the design system.
This is also where we decide what should never be editable. Unrestricted freedom in a HubSpot theme is how sites drift into inconsistency six months after launch.
Stage 4 — Build with performance budgets in place
Templates and modules are built against explicit budgets: image weight, font loading, script count and layout stability. Performance is a build constraint at Hubstack, not a post-launch cleanup task.
We keep HubL logic in the modules where it belongs, avoid duplicating markup across templates, and wire forms and CTAs directly to the CRM properties agreed in discovery so reporting works on day one.
Multilingual and campaign requirements are handled here too — parent-child language setups and reusable campaign templates cost far less when they are part of the original build than when they are retrofitted.
Stage 5 — QA against a documented baseline
Our QA pass is a diff, not an opinion. Every URL, title, meta description, canonical, redirect and schema block is checked against the baseline captured in discovery, then verified on the rendered page rather than in a settings screen.
We test every module in a live editor as a marketer would use it: swap content, remove blocks, change image ratios and lengthen headlines to confirm nothing collapses under real editing.
Cross-browser and mobile checks run on the modules, not just the demo pages, because the failures show up in combinations nobody designed for.
Stage 6 — Launch, then watch the right numbers
Launch day is a sequence: publish, verify redirects return single 301s to live pages, confirm indexing settings, submit the sitemap, then re-crawl to catch anything the cutover moved.
For the two weeks after launch we watch coverage, Core Web Vitals and form submissions rather than vanity traffic, because those three catch the majority of post-launch regressions early.
Then the site moves onto a maintenance rhythm — updates, small improvements and monitoring under HubSpot support and maintenance, so the build keeps its performance instead of decaying quietly.
Why the sequence matters more than the tooling
Every stage above exists because we have been called in to fix the version of a HubSpot site that skipped it. Pages designed before architecture. Modules built per-page. QA done on the homepage only.
The tooling inside HubSpot CMS is more than capable. Predictability comes from the order of operations around it, and that is what Hubstack standardises across every HubSpot engagement.
If you already have a site on another CMS, the same discipline applies — the sequence just starts with a HubSpot migration baseline instead of a blank portal.