A B2B manufacturer's marketing team stopped filing HubSpot dev tickets

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

Family-owned for four decades, this industrial components manufacturer sells through distributors and direct to plant engineers; the printed catalog remains its most trusted document — sales carries it, engineers reference it, and the website is expected to agree with it. Marketing is one person plus agencies. The website runs on HubSpot because the CRM does, and the product pages were built once, years ago, by whoever was available, then left alone.

What it was costing

The marketing site ran on HubSpot, but every layout change was a developer task: modules were one-off, fields were undocumented, and the marketing team had stopped requesting improvements because the queue was months long.

What they could see

• Every layout change meant a dev ticket, and the queue ran months; even small fixes waited behind other work.
• The marketing team had stopped requesting improvements altogether — the request log filled with items closed without a build.
• Product specs on the website disagreed with the printed catalog, and sales heard about it from engineers first.
• When the one marketer took leave, nothing on the site could change at all.

The constraints we worked inside

• Product data had to stay consistent with a printed catalog the sales team also used.
• The CRM was mid-migration; content had to work with both the old and new property sets during the build.
• Only one in-house marketer owned the site — documentation had to assume zero continuity.

What had been tried before

The marketer rebuilt two key pages herself with HubSpot's stock template library.

Stock templates couldn't represent the catalog structure, sales said the pages looked off-brand, and she reverted them within a month.

Their IT contractor was paid to build custom modules for the product pages.

The modules worked but shipped undocumented and one-off; the next change needed the contractor again, so the queue just changed owners.

A shared document listed every module and field on the site.

Nothing enforced it, so the document described a version of the site that no longer existed by the second quarter.

What we proposed

We proposed staying on HubSpot and rebuilding the way pages get made: an agreed content schema first, then a documented module library that assembles product pages, application notes, and landing pages from safe, editable parts. The marketer composes; catalog consistency is kept by structure, because product data lives in HubDB tables that mirror the printed catalog's columns. Because the CRM was mid-migration, every form and smart-content rule would be wired against both property sets from the start — the site had to survive the cutover without lead routing breaking.

Just as important is what we ruled out, and why:

• Rebuilding the marketing site on a second CMS — A mid-CRM-migration plus a one-person marketing team could not operate two systems; the integration, not the platform, was the failure.
• Commissioning more custom one-off modules — Undocumented one-offs were the current problem; paying for more of them buys the same queue with a different name.
• Generating all pages dynamically from HubDB alone — Application notes and landing pages need editorial freedom that product pages don't; one dynamic pattern would flatten page types that behave differently.

How the work ran

Delivered by the experience pod — frontend engineer + automation specialist over 7 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

HubSpot CMS

The CRM already runs the company; keeping site and CRM on one platform leaves a one-person marketing team one system to learn rather than two.

HubL

Modules with documented editable fields end the one-off pattern; the marketer composes within boundaries instead of requesting rebuilt templates.

HubDB

Product spec tables mirror the printed catalog's columns, so site and catalog read from one structure and sales stops reconciling the two.

HubSpot CRM

Mid-migration, both property sets had to work; smart content and forms were mapped against old and new schemas so lead routing survived the cutover.

What went wrong

How we worked together

Cadence

A 30-minute call every Tuesday and written progress every Friday; the marketer reviewed module builds on staging between calls and logged requests in a shared board.

Client side

One in-house marketer owned the site and attended everything; a sales operations analyst answered catalog questions; the IT contractor joined for the CRM-bridge work.

Decisions

Page-type and field decisions were signed off in writing before build; mid-sprint calls went to the marketer, with sales escalation for anything touching catalog data.

They provided

The printed catalog as the spec source, dealer spreadsheets, both CRM property sets during migration, and a weekly hour of the marketer's time for editing trials.

What changed

The headline: monthly dev tickets for page builds, measured across the first quarter after handover — 12 → 0, read from Marketing's request log. A second check: product-page update turnaround at 5 days → same day.

The marketer proposes improvements again — the request log filled with small ideas because small ideas became cheap to ship. Product updates land the same week sales hears about them, and the printed catalog and the site agree, so sales stopped adding check-the-website disclaimers to every quote. The documentation assumed zero continuity and has since proven it: a temp covered the marketer's leave using the module docs alone, and nothing broke.

The result was read from Marketing's request log against the pre-engagement baseline over the stated window, with a guardrail check on product-page update turnaround. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• The module library with documented fields, each editable surface labeled in plain language.
• A content schema document covering page types, module fields, and naming rules.
• HubDB tables mirroring the printed catalog, with a refresh procedure the marketer runs.
• The CRM property-mapping bridge that works across both schemas, with a post-migration cleanup note.
• Zero-continuity documentation written for a marketer who has never seen the build.