FAIRWINDS Website

Creating the new fairwinds.org was a true passion project of mine that I had started nearly day one of working at FAIRWINDS.

Our old site had been built on a relatively unknown PHP-based Content Management System (CMS) called ModX that, to be frank, was in pretty rough shape. There was no way to back up code, and it was difficult for anyone to understand how to use it (including me). The majority of the operation relied on institutional knowledge that was centralized in the mind of the other developer on staff.

I did not like our site, and I knew it could be better. Safer. Modern.

So I started on a project that I had code-named "Polaris" and spent the next 6 months or so trying to convince everyone from my boss to IT to the CEO of the company that there was a way for us to not only modernize our tech stack, but change how we sell online.

I needed to convince the company on two fronts:

In one corner, I was asking a very reserved company to take a massive risk on my plan for a technology stack. This wasn't just a question of purchasing a new CMS — this was moving them from physical servers hosted onsite (and in Tampa) on a stack they had used for decades to an edge network built on a Jamstack approach utilizing a programming language (REACT) that even I, myself, didn't yet know.

While all of that was great, I also knew I had to convince our executives who had no clue what any of that meant and probably couldn't care less about what GitHub and a headless CMS were. For them, I had to explain how the investment would ultimately lead to a multi-phased strategy — starting with a foundational overhaul of technology, sure, but ending with a site that will learn a user's interests and viewing habits to tailor itself to the user and lead to higher conversions.

I had decided to focus on a few guiding principles in my overall web strategy:

Be Safe, Flexible, and Future Forward

We needed to focus on technology that offered us a stronger foundation and wouldn't rely on institutional knowledge. A core belief I carried into the project is that the site needs to work smoothly even if I disappear off the face of the earth tomorrow. So, we would only use tools, frameworks, and programming languages that had a large community behind them. It couldn't just be shiny — it had to be safe and supported.

Keep it Simple, Stupid

The site had been stagnant and overgrown with metaphorical weeds. Pages would sometimes exist solely to provide a user with a single paragraph of text, forcing them to click through to the information they originally requested. We needed to streamline everything and be willing to cut out anything that didn't absolutely need to exist.

Put Our Users First...Always

People aren't interested in content that comes off as self-serving. From design to content, we must create something that is easy to understand and meets their needs before our own. We needed to focus more on financial education articles, for example, because people are more likely to visit your site to learn how to make better financial decisions than to find out what the APR is on our mortgage loans.

Convincing a multi-billion dollar company to take a massive risk was one thing — having to figure out how to do it (on my own) was another.

You see, while I knew this specific technology stack was the right move for us, I had no experience with most of it. My background was as a PHP developer, and while I had tried to learn REACT at my last job, I never really got my head around it.

In the end, this trial-by-fire led me to be a better developer and project manager. Unlike my past attempts, everything started to click, and I finally understood what all the hype was about. The site was faster, cleaner, and most of what I hoped for, and I finally felt I had caught up to others in my field.