HubSpot theme and module development.
Modules an editor cannot break. Custom themes, custom modules, HubDB-driven pages and the serverless functions behind them. The work that decides whether your marketing team can use the site or has to ask permission.
Bought a theme. Now you are inside it.
Marketplace themes are built to demo well across every industry, which means a hundred options, a design that is nobody in particular, and a structure you cannot extend without fighting it. The customisation budget quietly exceeds what a custom build would have cost.
A hundred options. None of them yours.
Themes — the generic buildThe parts that decide whether it lasts.
Field design first
What an editor can change, what they cannot, and what the sensible default is. Get this right and the site stays coherent for years; get it wrong and it drifts in a quarter.
Drag-and-drop that still looks right
Sections and areas constrained so rearrangement stays on the design system. Total freedom in a page builder reliably produces pages nobody wants to show anyone.
HubDB and dynamic pages
Locations, products, team members, resources — anything that is a list rather than a page. One template, many pages, and a table a marketer can edit.
Serverless functions
Form processing, third-party lookups, gated calculators and anything else that needs to run server-side without standing up separate infrastructure.
React modules and islands
On the current developer projects platform, interactive components that still render as working server HTML when the JavaScript has not arrived.
Global content and theme settings
Header, footer, colours and typography as theme settings, so a rebrand is a settings change rather than a find and replace across forty templates.
Engineers, working the way engineers work.
Scope in writing
What is being built, what it will not do, and how we will both know it is finished. Fixed scope where the work is knowable, a sprint rate where it is not.
Build in the open
Version control, a preview environment and a running demo, so you are not waiting until the end to find out what you are getting.
Review against the portal
Tested inside your actual portal with your actual content, at phone, tablet and desktop widths, before anybody calls it done.
Ship and document
Deployed, with the source handed over and a page explaining how to change it. You own what we build.
Too many fields is the same as too few.
A module with forty options is as unusable as one with none, because nobody knows which combinations were designed and which merely render. The craft is deciding what is worth exposing, and defaults good enough that most editors never change them.
What people ask before they commit.
Custom theme or marketplace theme?
Marketplace if the site is simple and the brand is flexible. Custom once you have a design system, because the customisation cost of forcing a generic theme to match it usually exceeds building one.
Can you extend our existing theme?
Usually yes. We add modules, fix field design and improve performance without a rebuild. Sometimes the honest answer is that the foundation will not carry what you want, and we will say so.
What is HubDB actually for?
Structured content that should be a table rather than a set of pages: locations, integrations, team, product catalogues, resource libraries. One template renders them all and a marketer maintains the table.
Do you build with React or HubL?
Both, and the choice follows the work. HubL for content-driven pages that should be fast and simple. React modules on the developer projects platform where there is genuine interactivity.
How long does a module take?
A simple one is a day or two. A complex one with dynamic data and interactivity is one to two weeks. A full theme is six to twelve.
Where people go from here.
Build it so it lasts.
Tell us what you are running
What the system does today, where it breaks, and when it has to work. An engineer reads it — you get an answer inside one business day, not a sequence.