Marketing
Our CMO had a clear SEO strategy. The website needed to support substantial content growth, fast page loads, and search-friendly architecture.
On Q Financial
How do you build for 10× the content without 10× the bloat?
When a former coworker became CMO at On Q Financial, he reached out about a complete website overhaul.
The goal was ambitious: build a modern website capable of supporting ten times the content while loading faster than competitors such as Better.com.
There were just a few conditions.
It had to run on WordPress. It had to preserve the existing functionality for finding mortgage agents nationwide. And it needed to support multiple people publishing several articles a day without turning content management into a full-time technical exercise.
So we needed a site that was bigger, faster, easier to manage, and compatible with legacy code.
Simple enough. What could possibly go wrong?
01 / Who?
Who needs this to work?
A website serves more people than the ones visiting it.
Before getting too far into development, I needed to account for the different teams and audiences relying on the new site.
Customers
Prospective borrowers needed a fast, intuitive experience, including an easy way to find a mortgage agent in their area.
Content Contributors
With multiple people publishing articles every day, content entry had to be straightforward and consistent. Authors needed to focus on writing, not navigating complicated page-building tools.
Design
I collaborated with an in-house designer whose background was in print rather than digital. His initial designs were conservative, so I encouraged him to focus on the experience he wanted to create rather than worrying about implementation constraints. I would work out how to build it.
Four different perspectives. One website that had to work for all of them.
02 / What?
What were we working with?
The project had three major technical challenges.
A platform we couldn't change.
WordPress was a requirement, but an off-the-shelf theme wasn't going to provide the level of control or performance we needed.
A legacy feature we couldn't lose.
The existing mortgage-agent search relied on unfamiliar, undocumented code that appeared to function somewhat like an API.
There wasn't a convenient technical reference explaining how it worked. I had to investigate the existing pages, identify which pieces of code controlled which data, and reconstruct the functionality within the new site.
A publishing process that needed to scale.
A tenfold increase in content would introduce operational problems if every article required special formatting, manual SEO configuration, or developer assistance.
We didn't just need to redesign pages.
We needed to build a system that could support the business's plans.
03 / Why?
Why carry along what we don't need?
Performance wasn't something we could address after development. It needed to influence how the site was built from the beginning.
- Why introduce a general-purpose theme filled with features we'd never use?
- Why make writers remember technical SEO requirements when the publishing system could handle them?
- Why constrain a designer's ideas based on implementation assumptions we hadn't tested?
- And why rebuild a working mortgage-agent system when we could preserve the functionality and create a better experience around it?
The challenge wasn't WordPress itself.
It was how we used it.
Every unnecessary dependency, manual task, or layer of complexity was something worth questioning.
04 / What if?
What if we built only what we needed?
I developed a custom WordPress theme with performance, maintainability, and content growth in mind.
The approach was straightforward: hand-code the functionality we needed and avoid unnecessary overhead.
Give the designer room to design.
I worked closely with our in-house designer, helping him realize he could explore what he wanted the digital experience to be, and to trust that I would make it work.
Rather than ask him to design around assumed technical limitations, I focused on making the approved designs work in the browser.
Make SEO part of the foundation.
To support the CMO's strategy, I incorporated dynamically generated Schema.org structured data into the theme.
I also made alternative text a required part of the image publishing workflow, helping content contributors maintain a more consistent approach to image descriptions.
The idea was to build useful practices into the system rather than rely entirely on contributors remembering them.
Make publishing routine.
I structured content entry around straightforward fields and repeatable templates so multiple contributors could publish regularly without needing to understand the underlying code.
Understand the legacy functionality before replacing anything.
The mortgage-agent search required a more investigative approach.
Without documentation—and working in a language I wasn't familiar with—I tested the existing implementation, traced how information flowed through it, and identified the code responsible for different parts of the experience.
Then I rebuilt the surrounding interface while preserving the functionality the business needed.
Sometimes the most useful development skill isn't knowing the answer.
It's knowing how to find it.
The outcome
Fast on day one. Built to last.
We launched a modern WordPress website designed to support substantial content growth without sacrificing performance.
Performance testing showed it loading faster than the competitors we evaluated.
As the CMO's SEO initiatives progressed, the site's Google search rankings climbed, supported by a platform built with content expansion and search visibility in mind.
The publishing experience allowed multiple contributors to add content while maintaining a consistent site structure.
We also preserved the nationwide mortgage-agent search despite its undocumented legacy implementation.
And perhaps the strongest testament to the foundation we created: six years later, the site's underlying design and structure remained largely unchanged, apart from ongoing content updates.
The goal wasn't simply to launch a faster website. It was to build one the business could keep using as it grew.