Setup
Implementation checklist
Every step between buying the theme and publishing the first page, in the order they have to happen.
Download Now
Downloads
The paperwork for a build.
Checklists, references and worksheets for putting a site together on HubSpot CMS with this theme. They are the working documents from real builds, not summaries written afterwards.
Start here
If you are opening the theme this week.
Reference
Theme settings reference
Every setting in the panel, what it changes on the page, and which preset already sets it for you.
Download Now arrow_forward
Planning
Page planning worksheet
Decide which templates and sections a site needs before you open the page editor.
Download Now arrow_forwardNo resources match
Nothing here matches that search and filter together. Clear one of them to see more.
1
Before the portal is touched
The planning worksheet, and the migration checklist if something already exists.
2
Setting the theme up
The implementation checklist, then the settings reference open beside the panel.
3
While pages are built
The module field reference, so a look is found in a field rather than written in CSS.
4
Before it goes live
The launch checklist, run on the pages that carry traffic rather than on a sample.
Before the portal
Read the checklist before you open the portal.
The implementation checklist and the migration checklist are the two that change what you do first. The reference sheets are the ones you keep open while you work.
Library
Everything, filterable.
Filter by stage to find the one you need now.
search
6 files
checklist
checklist
Checklist
Free
Setup
Implementation checklist
From an empty portal to a published page, in order.
Download Now arrow_forward
menu
menu
Free
Reference
Theme settings reference
Every setting, and the part of the page it moves.
Download Now arrow_forward
menu
menu
Gated
lock
Reference
Module field reference
Every module and the fields that drive it.
Download Now arrow_forward
checklist
checklist
Checklist
Gated
lock
Migration
Migration checklist
Moving a live site onto the theme without losing pages.
Download Now arrow_forward
checklist
checklist
Checklist
Free
Launch
Launch QA checklist
What to check on a page before it is published.
Download Now arrow_forward
menu
menu
Gated
lock
Planning
Page planning worksheet
Decide the pages and sections before opening the editor.
Download Now arrow_forwardNothing matches
Nothing here matches that search and that category together. Clear one of them to see more.
The steps a first build goes through, written so you can stop halfway and pick it up the next morning without guessing where you were.
- Uploading and activating the theme on a portal that allows it
- Choosing a preset before any page is created
- The pages worth building first, and the ones that can wait
- What to check before anybody else is given access
The settings panel written out group by group, with the thing on the page each control changes, so you stop hunting for the one that moves the header.
Inside
- Design tokens: spacing, rhythm, shadows, radius, motion
- Brand colours and the on-dark and on-light helpers
- Typography, buttons, forms, cards and layout
- Which preset already sets each value for you
One page per module: the layout, style and content groups, what each field accepts, and what it looks like when it is left empty.
- Field names as they appear when a module is overridden in a template
- Which groups have to be nested for an override to take
- The fields that quietly change the heading level a module emits
Written for the case where the site already exists and cannot go dark. The order is chosen so that anything you get wrong is still reversible.
- What to inventory before the first template is swapped
- Templates, then pages, then navigation — and why not the other way round
- Redirects, and the ones people forget until search traffic drops
- What to check on the pages that carry traffic before the switch
The checks run on a page before it goes live, ordered so the ones that break a launch come first and the cosmetic ones come last.
- Heading order, alt text, focus and the skip link
- Forms tested with a real submission, not a preview
- Every page type opened at mobile width, including the system pages
- Search, error and preference pages, which are where the theme usually shows a seam
A sheet you fill in with the client in the room: what pages exist, which template each one uses, and which sections carry the content.
- A row per page, mapped to the template that will build it
- A column for the one thing each page has to do
- Space for the content that does not exist yet, which is usually the reason a build stalls
A checklist that survives contact with your process is one you have rewritten. None of these are a standard to be complied with; they are a starting list so you are not writing one from an empty file at eleven at night.
If you hand one to a client, rebrand it first. Nothing in these files asks for attribution and nothing in them has to say where it came from.
The settings and field references track what is in the theme, so they change when the theme does. The date on each file is the last time it was checked against a real build, and the release notes say what moved.
There is no form in front of a download on this page. If you want to be told when one changes, the band at the bottom does that and nothing else.
No. The implementation and launch checklists apply to any HubSpot CMS build. The settings and field references only make sense next to this theme, because they list its own field names.
Yes, including with your own branding on it and our name taken off. If it helps a handover go better, it has done its job.
Rewrite it first so it says what you do rather than what we do. Reposting a file unchanged helps nobody, including you.
The references that name fields and settings are updated with the release that moved them, and the release notes say which. The process checklists change far less often, because a build runs the same way whatever the field is called.
Write to us with the file and the line. A reference that is wrong is worse than no reference, so these get fixed ahead of most other things.
Newsletter
Told when the files change.
A release can make a checklist wrong. This is how you find out.
One email when a file changes Sent when something is added or rewritten, which is not every month.
- description New checklists and references as they are written
- edit_note A note when a release makes an old one wrong
- block No sequence, no product announcements
Unsubscribe from any of them. The address is not used for anything else.