Building This Site: A Behind-the-Scenes Look

Building a brand-new website is no small feat. You’re staring at a blank slate — endless possibilities, plenty of inspiration, and absolutely no desire to create just another forgettable site. You want something that stands out. Something great even.

And if you are actually developing the site yourself, the overwhelm multiplies. There are so many technology choices, and you don’t want to pour time into something that’s outdated the moment it launches. What if you pick the wrong stack and end up with a site that’s slow, hard to manage, or just doesn’t work the way you need? That’s the kind of regret that keeps developers up at night.

I get it. These are real concerns, and with so many options out there, decision paralysis is real.

So, I figured it might be helpful to share what I learned while planning and building the very site you’re on right now.

Purpose

Before you build anything, you need to get crystal clear on what you’re trying to achieve. And not in a vague, hand-wavy way—it should be something you can actually measure. Pretty much everything else you do comes from having a good understanding of this step.

Maybe it’s “generate 50 leads per month through the site’s web form” or “attract 1,000 visitors a month via organic search” or even “increase sales conversions by 25% from web traffic.” Whatever your goal, you need a way to track success. Otherwise, once the site is live, how will you know if it’s working? And if it’s not, how will you know what to tweak?

The best way to start? Write a simple, measurable purpose statement. Keep it short, keep it clear, and make sure you can track it.

Here is the purpose statement I came up with for my site:

Design

Design can make or break your project—think of it like your home's curb appeal. If it’s inviting, well-kept, and full of personality, people will want to step inside. But if the front yard is a tangled mess of overgrown weeds and questionable design choices, no one’s sticking around long enough to discover the potentially magical things beyond the door.

For me - this was the most daunting part of the project. That blank canvas I mentioned earlier was staring me down hard. I knew I wanted something that reflected my personality, and I knew I didn't want it to be boring or typical - but where to start?

Surprisingly, searching "not boring site design" returned search results for a familiar name, Jack McDade. I clicked over to his site and it was - exactly the kind of vibe I was looking for. His site was gorgeous, and his pitch was "don't create boring sites". Perfect. I had heard about Jack several years prior with the work he was doing on a new CMS called Statamic, and one of my colleagues at the time had a direct line to him, as we were considering using Statamic for a project we were working on. He had nothing but great things to say about the CMS and where it was going.

I had no idea where Statamic was at today but after digging into it, I could see not only was it alive and well, it was absolutely thriving. Even more fortunate for me - Jack had published a design course oriented towards developers called "Radical Design". I was one of those take my money moments, and I couldn't have asked for a better result.

The course was fantastic—it gave me a solid framework to channel my creativity, plus a starting point and some handy tips to keep me from getting stuck. (spoiler alert: we are our own worst enemies when it comes to progress!)

After taking the course - I started working out a design. The first few concepts were laughably bad but eventually I got something that I was really proud of, and felt like could even be great (?) I do recommend having someone you trust give you some critical (but loving) feedback when you feel like you're ready for that, but ultimately remember, it's your design and your purpose statement.

Technology

Now we come to the foundation of your website, the technology stack. Again, depending on your skillset, you can either find something more "off the shelf" or do a "deep dive" and build it yourself. There are CMSes that require very little technical knowledge and will take care of all the details for you, and there are options that require more of a "development" skillset but allow fine grained control over the implementation.

As someone with "full stack" development skills - I decided to go with the latter. If you're looking for more "off the shelf" page builders that are extensible for the majority of your needs, it's still hard to beat the Wordpress/WP Engine ecosystem.

Jack's design course aside (he is the creator of Statamic of course), I didn't have to go with Statamic as my CMS of choice. But honestly, I was curious, especially since we never actually ended up using it at that company I mentioned earlier (womp womp.) Statamic does require development skills to use, and they are upfront about that.

I decided to build a small prototype with a single page of my design to see how simple or difficult the whole setup was going to be. Needless to say, I was blown away by the simplicity of the entire thing. The defaults were so carefully considered and seamlessly incorporated into the framework, which was a huge time saver out of the gate.

As a longtime PHP developer, the fact that Statamic runs on Laravel made it feel like home — I could find my way around almost instantly.

Antlers, the default templating engine, was brand new to me but again, simple and a delight to use. Eliminating the custom controller and model layers and building that into a souped up version of the "blade" templating engine was a genius move and was well executed. The syntax took some time to learn and get used to, but it's all extremely well documented on the Statamic website. Even better - Github Copilot was also familiar with it and could help me out when I got in a bind (it didn't always get it right but tended to point me in the right direction).

The other new framework I used was TailwindCSS, which comes out of the box on Statamic. I decided to go ahead and learn it, being mostly a "Bootstrap" guy for many years. I was extremely pleased with the simplicity and sheer number of utility classes it supported, including the ability to easily override where needed, which was critical when trying to achieve my final design. Again Copilot could help me learn it and explain what classes to use in different situations - so far so good! And with that, I decided to go all in and start building things out.

I watched a few videos from Jack on how to set things up in the CMS itself and - I had all of my content types, globals, nav etc... mocked up and going in probably a day or two. It was the simplest part for sure.

I'll probably write a separate article on the infrastructure side of things: Laravel Forge was the deployment/server management tool I ended up choosing, and I went with Vultr for my hosting. Forge is an extremely impressive management tool and is well worth the spend (I was on the fence about the extra cost since I typically manage everything myself on the servers but I am really happy to have a customized management tool that knows and understands the Laravel app that running there, its a game changer!)

This was just what worked for me based on my experience, but as a general rule when looking to deliver a new project quickly, I offer the following tips:

1. Lean on your experience

   It’s tempting to try the latest frameworks and tools, but if speed is your priority, work with what you already know. If you absolutely must introduce something new, keep it small and manageable —don’t go full “let’s rewrite everything in XYZ” unless you have the time to burn.

2. Use AI to help bridge knowledge gaps

   As I said, even though I was already familiar with Laravel, there were new things for me to learn that I didn't want to get bogged down in. AI tools like ChatGPT and Github Copilot helped me cut hours of research and debugging time out of my development despite the fact that Antlers and Tailwind were new to me.

   The key here on this one is not skipping the learning process. Don’t just blindly implement something AI suggests — just like you wouldn’t mindlessly copy-paste from Stack Overflow (right?). AI can speed up your learning, but it shouldn’t replace it. Otherwise, you’ll end up with something you don’t understand and can’t manage. And that’s a huge problem waiting to happen.

3. Set Clear Boundaries for Yourself

   It's easy to get carried away adding features that “would be nice to have.” Instead, define the minimum you need to launch upfront and stick to it. Anything beyond that goes on the nice-to-have list for later. I also used a task tracking tool like "Notion" so as new ideas came up, I could dump them onto a task board and mark what was "critical" and what I was okay with coming back to later.

4. Don’t Let Perfection Get in the Way of Progress

   As I already mentioned, you'll always find ways to improve, but done is better than perfect (at least for v1). Ship something that works well, and then dedicate yourself to continuing to improve as you go.

Final Stack

My final application stack ended up using the below:

Local Development

• Platform Dev Environment: Laravel Herd

• IDE: Visual Studio Code

Stack

• Content Management System: Statamic

• App Framework: Laravel

• CMS Database & Content: "Flat File" YAML via Statamic

• Front End/Back End Frameworks: Antlers, Vanilla Javascript, TailwindCSS

• Version Control: Github

Infrastructure

• Server & Application Management: Laravel Forge

• Cloud Hosting Provider: Vultr

• Domain Name: Squarespace