HubSpot CMS builds shaped by HubL, not drag-and-drop.
The editor gets you a long way, then stops. Past that point a HubSpot site needs a child theme, real HubL templates, and modules your marketers can still edit without us.
Where the drag-and-drop editor runs out.
The call usually comes from a marketing team rather than a developer. Somebody wants the blog listing to filter by tag, the sidebar to follow the reader down a long post, and the subscription form to sit where it converts. The editor won't do any of it, and the theme underneath is a vendor default nobody owns.
That is a child theme job. We fork the theme so platform updates keep landing, then build the HubL templates and the custom modules those layouts need — each module with fields your marketers can see, so the next change doesn't route back through us.
Performance here is a template question more than a hosting one. CMS caching only helps what the templates let it help, so we care about how many modules a listing page instantiates, what each one queries, and which assets a single post genuinely needs.
Our blog looks like every other HubSpot blog.
Custom HubL templates for the listing and the single post, built from your design rather than a marketplace theme with your logo dropped into the header.
Marketing can't change anything without raising a ticket.
Every custom module ships with editable fields and sensible defaults, so copy, images and layout choices stay in the editor where marketing already works.
The sidebar and tag filters were built as a hack.
Sticky sidebar behavior, tag filtering and subscription forms belong in the template, not in a script bolted on after render. We move them back where they belong.
Pages got slower every time we added a module.
We count what a listing page instantiates and what each module asks the CMS for, then trim assets so CMS caching has something cheap to cache.
Scope, spelled out.
Custom child theme
A child theme forked from yours, so HubSpot platform updates keep arriving while your templates and styling stay untouched by them.
HubL templates and modules
Page, listing and system templates written in HubL, plus custom modules whose editable fields are designed for the person who edits them.
Blog listing and post
A blog listing layout and single-post layout built properly: pagination, related posts, author blocks, and a tag filter that works server-side.
Sticky sidebar and CTAs
Sticky sidebar behavior, in-post CTA slots and a contents list that hold their place through long posts and don't fight a short viewport.
Subscription forms
Subscription forms placed where they convert and wired to the right list, with the confirmation path tested rather than assumed to work.
CMS caching and assets
Module count per template reviewed, queries reduced, CSS and JS scoped per template, so CMS caching finally has cheap pages to work with.
Marketing-team handover
A walkthrough of every module and field with the people who will use them, plus written notes for the marketer who joins after they leave.
What actually happens, week by week.
Scaffold
A child theme forked from the one you run, so platform updates keep landing where they belong.
Modules
HubL modules built field-first, with the editor experience decided before any of the markup is.
Layouts
Blog listing and single-post templates assembled, with tag filtering and the forms wired in place.
Caching
Module count, queries and per-template assets trimmed until CMS caching has cheap pages to serve.
Handover
A live walkthrough with the marketing team, plus notes for whoever edits this a year from now.
The tools we actually use here.
HubSpot work is narrow and specific, so the list is short on purpose: HubL and the CMS on one side, ordinary front-end craft on the other. That is all a good child theme is.
Deliverables, outcomes and who this is for.
- Child theme, forked and versioned
- HubL templates and custom modules
- Blog listing and single-post layouts
- Tag filtering and subscription forms
- Module and field documentation
- Marketers edit without a developer
- A blog that reads like your brand
- Templates cheap enough to cache
- Platform updates stop breaking things
Marketing teams on HubSpot CMS who have outgrown the editor and want templates a developer wrote, not a theme they rented.
The HubSpot work we're allowed to name.
Arcadian: a custom child-theme blog
Arcadian (arcantenna.com) runs custom HubSpot child-theme blog templates we built: a blog listing layout and a single-post layout, with sticky-sidebar behavior, tag filtering and subscription forms. Not a marketplace theme restyled — templates written in HubL against their design, inside a child theme.
Why the sidebar was the hard part
Sticky behavior is easy to fake with a script and painful to live with once posts get long and viewports get short. Doing it in the template means the sidebar knows where the post ends, the tag filter knows what is in the listing, and nothing repositions itself after the reader has started reading.
Where HubSpot performance actually lives
CMS performance on HubSpot is a template question, not a hosting one: what a listing page instantiates, what each module asks for, and which assets a single post actually needs. HubSpot caches what you hand it, so the lever is the template rather than the cache. Handing it something cheaper is the whole job.
Questions we get on the first call.
Sometimes you shouldn't. If the brief is campaign strategy, lifecycle marketing or a full platform rollout, an agency with strategists on staff is the better buy. We are developers. If the brief is a child theme, HubL templates and modules a marketer can use, that is the part we do. It is also the part those agencies subcontract.
That is the test we build against. Every module exposes fields — text, image, choice, repeater — labeled for a marketer rather than a developer, with defaults that already look right before anyone touches them. If a change needs a developer after handover, the module was designed wrong. We treat that as our bug.
Hourly, or a small monthly retainer once the trickle is steady. This work tends to arrive as a stream of half-day jobs, and quoting each one separately costs both of us more in email than the change costs in code. So we would rather hold a block of hours for you. It is cheaper and faster.
That is exactly why we work in a child theme instead of editing the parent. Updates land on the parent, your overrides sit alongside them, and the blast radius of a platform change stays small. Nothing makes custom code immune. What this does is turn a broken site into a broken module we can find.
Yes, and it is the most common shape this work takes. The blog listing and single-post templates get replaced inside the existing child theme while every other page stays exactly as it was. Where shared CSS makes that harder than it sounds, you'll hear so first. Usually it doesn't.
More in Web & CMS.
Get HubSpot templates a developer wrote.
30 minutes with the developer who'd write the HubL. Bring the page your editors keep asking you to change, and we'll say what it takes.