I was given 72 hours.
The designer who built most of the Motley Fool Wealth Management site was leaving the company. There was little to no documentation. What existed was in his head — the template logic, the workflow configurations, the reasons behind the forms and page structures, the HubDB databases and how they connected. I had three days to sit with him and absorb everything I could. When he walked out the door, that was it.
This is not an unusual situation. Maybe the timeline is more dramatic than most, but the underlying reality is common: you inherit a system you didn't build, with decisions you didn't make, serving goals that may have shifted since it was created. And you're expected to make it better without breaking what's already working.
That's the inheritance tax. And most of the real design work I've done has started by paying it.
What the inheritance looks like
The Wealth Management site's primary job was straightforward: get potential clients to book a meeting with a financial advisor. That goal ran through everything — the site flow, the marketing campaigns, the landing pages, the report downloads, the email newsletters, the weekly blog posts, the social content. Every touchpoint was a path toward that conversion.
But the system underneath was HubSpot, and HubSpot is its own world. Workflows that trigger email sequences. Forms that route leads based on criteria. HubDB micro-databases that power dynamic content. A Design Manager where every template, component, and page is built in code. None of it was broken exactly — but none of it was documented, and the person who understood the architecture was gone.
The instinct in that situation is to want to tear it down and rebuild. Start clean. Design the system you would have designed if you'd been there from the beginning. But that instinct is almost always wrong. The site was generating leads. The workflows were running. The forms were converting. Rebuilding would mean months of work to get back to where things already were — plus the risk of losing whatever was quietly working in ways you didn't yet understand.
Going deep
So I went the other direction. Instead of replacing HubSpot, I learned HubSpot. Not surface-level — deep. How the workflows actually processed leads. How the templates were structured in code. What the HubDB tables were doing and where they were fragile. How the Design Manager organized components and what could be safely extended versus what was load-bearing and shouldn't be touched.
That investment took time. It wasn't glamorous work. But it meant I could start making targeted improvements with confidence — expanding out an FAQ, integrating new calendars into the booking flow, routing to custom landing pages with video message from your new advisor — without risking the parts that were already doing their job.
The multiplier
Here's where the investment paid off in a way I didn't fully anticipate. The Motley Fool's regulated business wasn't just Wealth Management. Motley Fool Asset Management and Motley Fool Ventures were also built on HubSpot. Same platform. Different sites, different business goals, different compliance requirements — but the same underlying architecture.
The expertise I'd built going deep on one site became a superpower across three lines of business. I understood what HubSpot could do, how to push it, where its limits were, and how to build within them effectively. Problems that would have taken weeks to diagnose on an unfamiliar platform took hours. Improvements that required deep knowledge of the template system, the workflow engine, or the database layer were things I could execute confidently because I'd already mapped the terrain.
That's not something you get from fighting the platform or replacing it. It's something you get from mastering it.
Constraints are the material
The design industry loves to talk about thinking outside the box. But most of the valuable work I've done has been becoming proficient inside the box — inside the CMS, inside the compliance requirements, inside the platform limitations, inside the organizational realities.
That's not a compromise. It's where the work actually lives.
The designers who deliver real improvements in complex organizations are the ones who treat constraints as design inputs, not obstacles. Who learn the platform instead of resenting it. Who make targeted, strategic changes instead of proposing idealized redesigns that never ship.
I have no nostalgia for blank canvases. The work I'm proudest of is the work that shipped inside messy, inherited, constrained environments — and made things measurably better for the people using them and the businesses running them.
The views expressed here are my own. The work referenced was performed as part of a team within Motley Fool's regulated business lines — any wins were shared, and the 72-hour knowledge transfer was exactly as stressful as it sounds.
Portions of this content were outlined and proofread with the assistance of AI tools.