%201.png?width=250&height=83&name=ACTsights%20Logo%20(500%20x%20100%20px)%201.png "ACTsights Logo")
I have 25 custom modules on my HubSpot site. I built most of them using a two-tool workflow: Claude designs the page or module, Gemini writes the HTML, CSS, and JS for the actual module build. That workflow is fast. I went from a blank HubSpot instance to a full custom theme in days.
Then I needed to build a resource library with 20 cards.
Each card has a name, description, type badge (Shield or Decision Engine), format, tag, access level, and a CTA. I already had a working AS Resource Card module — the fields were clean, the design matched the brand system. The problem was populating 20 of them.
I hated the idea of pasting each heading, description, and tag into each card one at a time. I wanted a bulk solution. I wanted it badly enough that I tried four different approaches before finding the right one.
Click here to see the final SOP and walkthrough video
Attempt 1: Claude Cowork
I started with the most ambitious approach. Claude's desktop agent — Cowork — can interact with files, browser tabs, and applications directly. My logic was simple: give it the content in a structured file, point it at the HubSpot page editor, let it populate 20 cards.
It wasn't able to navigate the editor along with my custom module reliably. The interaction between Cowork and HubSpot's page editor — with all its nested panels, drag targets, and modal fields — was too unpredictable. Worse, the retries burned through my usage allowance fast. I didn't learn much except that agentic AI tools and complex CMS editors aren't there yet.
Attempt 2: MCP and CLI
Next I went technical. The MCP (Model Context Protocol) interface with a command-line workflow let me interact with HubSpot's API more directly. This approach almost worked — the data was structured correctly, the API calls were forming — but the page template had a code error that made the entire page uneditable. I couldn't fix it from the page editor. Had to delete the page and start over.
There was no way to know about the error without trying it. That's the nature of working at the API level — you're learning by doing, and the cost of a bad call is higher than the cost of twenty manual pastes. But it was worth the experiment. Once that code error is fixed, this approach will be a fast way to update and add content going forward.
Attempt 3: Claude in Chrome
The browser agent tried to work directly in the HubSpot page editor, similar to Cowork but through Chrome. It understood the task. It found the right fields. Then it tried to create cards side-by-side in a row — all squished together instead of a few cards per row. Twenty resources crammed horizontally, impossible to read.
Almost. But "almost" with an unreadable layout isn't a resource library — it's a wall of text.
Attempt 4: Old School
I gave up on automation and started building the cards manually. Copy, paste, configure, repeat. The content was ready. The module worked. The problem was visual consistency — getting 20 cards to align to the same height when description lengths varied. Every card looked slightly different. The grid was ragged.
This is the moment most agency owners recognize. You've tried the clever solution three times. You've fallen back to the manual approach. And the manual approach is producing work you're not proud of.
Attempt 5: HubDB
I don't know what made me think of HubDB. I'd never tried to do anything with it before. It felt like fate — I stumbled onto it as a solution and immediately knew this was the right shape for the problem.
HubDB is HubSpot's database table layer. Instead of creating 20 module instances, you create one table with 20 rows and one module that loops through the table.
I already had the CSV ready — Claude had organized all the resource content with proper field names earlier in the process. That CSV became the import file. Here's what the build actually looked like:
Create the table and map the columns. In HubSpot, Marketing > Files and Templates > HubDB. New table. Import the CSV. Each column maps to a HubDB field: card_name, card_desc, card_type, card_format, card_tag, card_access, card_url. The names have to match the module code exactly — spelling, casing, underscores. If they don't match, the content won't populate and you'll spend time debugging instead of building. This took about five minutes.
Build the module. Gemini generated the HTML for what I called the AS HubDB Resource Gallery — a single module that loops through the table rows and renders one card per row. The code includes badge logic (Shield vs. Decision Engine based on card_type), access level badges (Free, Gated), format tags, and UTM-tracked CTA links. Smart Content logic gates certain resources behind enrollment status. The module build took less than five minutes.
The first refresh didn't work. The page loaded, the module rendered, the cards were blank. No content.
I screenshotted the empty page, dropped it into Gemini, and asked what was wrong. Thirty seconds later: the HubDB variable name in the table properties didn't match the variable name referenced in the module code. I opened the table properties, updated the variable, republished, refreshed. The 20 resource cards loaded.
The whole troubleshooting cycle was two minutes. That's the part that would have taken an hour five years ago.
Why the Failure Path Is the Real Story
The fifth attempt worked. But the first four taught me something more useful than a HubDB tutorial.
Agency owners — and I include myself in this — reach for the tool that matches our current skill level, not the tool that matches the problem. I started with the most powerful AI agents because I know how to prompt well. The problem didn't need a powerful agent. It needed a database and a loop.
Each failed attempt was faster and closer to working than the one before. Cowork couldn't navigate the editor. The CLI approach was fast but destructive. Chrome was fast and almost correct. Manual was correct but ugly. HubDB was fast, correct, and maintainable.
The pattern: the right solution wasn't the most sophisticated one. It was the most structural one.
What Changes After This
Adding a new resource to the library now takes two minutes. Open the HubDB table. Add a row. Fill the fields. Publish. The page updates automatically. The design stays consistent because there's only one module rendering every card.
No cloning modules. No alignment debugging. No asking the one person who knows how the page works.
For agencies managing growing content on HubSpot — resource libraries, product catalogs, case study collections, tool directories, partner pages — HubDB replaces the rebuild treadmill with a spreadsheet update. The first build takes an afternoon. Every update after that takes two minutes.
Where This Pattern Shows Up Next
The module-per-resource trap is one example of a system that worked at small scale and quietly broke at medium scale. Most agencies are carrying ten more like it — reports nobody reads, workflows that depend on one person's memory, approval chains that bottleneck through the founder.
The fix is always the same shape: stop scaling a manual process and build the structural solution that absorbs the growth.
That's what the resource library taught me. The HubDB build solved one page. The pattern solves the agency.