HubSpot CMS and Next.js for B2B SaaS Marketing Sites

Start with the job HubSpot already does

Do not start with the framework.

Start with the systems HubSpot owns today. In many SaaS teams, HubSpot handles:

• contact records
• lead source data
• forms
• routing and notifications
• email workflows
• lists and segmentation
• campaign tracking
• sales handoff context
• reporting views

Those jobs matter more than the logo on the CMS. If the website sends incomplete or messy data into HubSpot, the front end failed the business even if the pages look cleaner.

A custom site should protect the parts HubSpot already does well. The build should make the buyer experience stronger without cutting the sales and marketing team off from the data they need.

When HubSpot alone may be enough

A full custom front end is not the right answer for every team.

HubSpot may be enough when the site needs standard marketing pages, simple blog operations, basic landing pages, and fast campaign publishing by a team that already works inside HubSpot every day.

That route can reduce moving parts. One system owns content, forms, contacts, and campaigns. Editors do not have to learn a separate CMS. The team can ship common updates without touching code.

The tradeoff appears when the site needs more control than the platform wants to give.

Watch for these limits:

• page designs start fighting the template system
• editors need structured content relationships, not one-off modules
• the team wants cleaner component rules than the page builder allows
• product, use-case, comparison, and resource pages need shared data
• performance suffers from scripts and page weight
• developers need stronger version control and deployment rules
• the public site needs a brand system that cannot survive in loose templates

If those problems show up before the rebuild starts, do not force the whole site into HubSpot for convenience. Convenience at the start can become maintenance debt after launch.

When a HubSpot and Next.js setup makes sense

A HubSpot and Next.js setup makes sense when HubSpot should remain the business system, but the public site needs custom development.

That can mean the team wants:

• custom design patterns with controlled components
• faster, cleaner public pages
• structured content for products, use cases, comparisons, resources, and authors
• stronger engineering workflow around version control and deployments
• flexible integration with analytics, forms, consent, search, or personalization
• a buyer path that cannot be built from generic page sections

In this model, Next.js does not win because it is trendy. It wins only if it gives the team a better way to build and maintain the public website.

HubSpot still has a job. It can receive form submissions, store contacts, trigger workflows, support sales follow-up, and help marketing understand campaign context. The custom front end handles the site experience and sends clean data into HubSpot.

That separation works when the team defines the contract between the systems.

Define the system boundaries before design

Many website problems start when teams design pages before they define ownership.

Write down which system owns each job:

The fuzzy rows need decisions. Blog content, resources, landing pages, preview, and redirects can create scope creep if nobody names the owner.

For a Virdis-style build, this step happens before visual design gets too far. The site architecture should tell design and development what the system must support.

Decide where content should live

The CMS decision matters as much as the front end decision.

Some teams keep core marketing pages in a headless CMS and use HubSpot for forms, CRM, and automation. Some keep landing pages in HubSpot and build the main site elsewhere. Some use HubSpot for blog content because the team already has workflows there.

Pick the model that matches how the team works after launch.

Ask:

1. Who updates product pages?
2. Who publishes comparison pages?
3. Who owns the blog?
4. Who edits landing pages during campaigns?
5. Who approves SEO fields?
6. Who controls redirects?
7. Who can publish production changes?
8. What content needs preview before it goes live?

The worst answer is split ownership with no rules. Marketing changes a landing page in HubSpot. Developers change a shared CTA in code. Someone updates a form field. Sales loses a routing value. Nobody knows which change broke the handoff.

A good content model gives the team speed with guardrails. Editors should control the right fields. Developers should protect layout, data shape, SEO requirements, and conversion behavior.

Plan forms as a business handoff, not a widget

Forms are where many HubSpot and custom-site builds fail.

A form can look correct and still lose the data sales needs. The development plan should define every submission path before implementation.

For each form, document:

• the HubSpot form or endpoint
• visible fields
• hidden fields
• required fields
• source, medium, campaign, landing page, and page path values
• consent language
• spam protection
• thank-you state
• notification owner
• workflow trigger
• error state
• test submissions

Do not test only the happy path. Test a demo request from paid search, organic search, a direct visit, and a returning visitor with existing cookies. Confirm the HubSpot contact record shows enough context for sales to act.

If attribution matters, define it before launch QA. Retrofitting hidden fields after launch turns simple tracking into detective work.

Treat analytics as part of the integration

HubSpot tells part of the story. Website analytics tells another part.

A custom front end needs an event plan that covers the actions that matter:

• demo form starts and completions
• contact form submissions
• pricing or cost-guide clicks
• high-intent CTA clicks
• booking flow starts
• resource downloads
• integration page visits
• comparison page engagement

The team should define event names, triggers, parameters, and QA steps before development starts. HubSpot workflows, Google Analytics 4 events, tag manager rules, and CRM reporting should not disagree about what happened.

This is where a custom build can beat a loose template setup. The team can wire measurement into the component system. A CTA component can send consistent event data across page types. A form wrapper can standardize hidden fields. A resource card can track the same action wherever it appears.

That only works if analytics gets treated as a requirement, not a launch-week chore.

Protect performance from integration creep

HubSpot integrations can add scripts. Analytics tools add scripts. Chat, heatmaps, consent tools, enrichment, and ad pixels add more.

A custom front end gives the team more control, but it does not remove the need for discipline.

Set rules for:

• which scripts load on every page
• which scripts load only after consent
• which scripts load only on pages that need them
• how forms load on high-intent pages
• how third-party failures affect the page
• how the team tests page speed on real templates

A fast framework cannot save a site that loads every marketing script on every page. The build needs a tag and integration strategy, not only image optimization and clean code.

Build the preview and publishing workflow

Preview causes trouble when the CMS and front end live in different places.

Editors need to review draft content in the real page system before publishing. Developers need stable environments for staging and QA. Marketing needs confidence that a page can go live without a manual Slack thread every time.

Before development, define:

• draft preview behavior
• staging URLs
• publish permissions
• deployment triggers
• rollback process
• content freeze rules before launch
• who approves changes to forms and routing

This matters for SaaS teams with active campaigns. If marketing cannot preview a landing page with the real form and tracking behavior, the team will test in production. Production should not be the QA environment.

Watch the common failure points

HubSpot and Next.js projects fail in predictable places.

None of these problems require exotic engineering. They require decisions before the build starts.

Use this decision checklist

Choose a HubSpot and custom front end setup if most of these are true:

• HubSpot already runs CRM, forms, and automation.
• The public site needs stronger custom design and development than HubSpot templates can support.
• Marketing can work with a structured CMS or defined page model.
• The team needs cleaner component rules across product, use-case, resource, and comparison pages.
• Lead context and attribution matter to sales.
• The team has a clear owner for preview, publishing, redirects, and form QA.
• Performance and maintainability matter enough to justify the extra system boundary.

Keep more of the site in HubSpot if most of these are true:

• The team needs simple landing pages and standard content operations.
• Editors need one familiar tool more than custom page systems.
• The site has limited content relationships.
• The design system can live inside HubSpot templates without heavy workarounds.
• The team does not have the budget or ownership model for a custom integration.

Choose another CMS plus HubSpot if the site needs a deeper structured content model than HubSpot should own. Products, integrations, use cases, authors, resources, comparison data, and localization can justify a dedicated CMS while HubSpot remains the CRM and automation layer.

What to ask before hiring an agency

If you are considering a HubSpot and Next.js build, ask the agency these questions before you buy the work:

1. Which system will own each content type?
2. How will forms send source, campaign, and page data into HubSpot?
3. How will editors preview draft content?
4. What happens when HubSpot forms or scripts fail?
5. How will analytics events stay consistent across components?
6. Who owns redirects and launch QA?
7. How will the build protect performance while using marketing tools?
8. What can marketing update without a developer?
9. What should marketing never be able to break?
10. How will the team test the sales handoff before launch?

The answers will tell you whether the agency understands the business system or only the front end.

The practical recommendation

Use HubSpot where it supports the revenue process. Use custom design and development where the public website needs more control than HubSpot should provide.

That is the clean version of the decision.

A HubSpot and Next.js setup should not create two disconnected websites. It should create one buyer experience with a clear back-office handoff. Buyers get fast, useful pages. Marketing gets structured content control. Sales gets clean lead context. Developers get a maintainable system instead of a pile of exceptions.

If the project cannot define those handoffs before development, pause. The tool choice is ahead of the operating model.

Frequently asked questions

Should a B2B SaaS site use HubSpot CMS or Next.js?

Use HubSpot CMS when the team needs simple publishing inside one familiar marketing system. Use a custom front end such as Next.js when the site needs stronger page systems, custom design control, structured content, and tighter integration rules.

Can HubSpot forms work on a custom website?

Yes, but the team needs a clear form plan. Define fields, hidden values, consent, routing, workflows, error states, and test submissions before launch so HubSpot receives useful lead context.

Should HubSpot own the blog in a custom site build?

Base the decision on the editing workflow and content model. HubSpot can work for simple blog operations. A dedicated CMS may fit better when the site needs structured relationships between posts, authors, categories, products, resources, and comparison pages.

Is Next.js required for a HubSpot integration?

No. Next.js is one possible front end. The right choice depends on page complexity, content operations, performance needs, integrations, team ownership, and maintenance requirements.