building block on a Rubic cube type structure coming together

The WordPress Reality Check

Choosing WordPress was the easy part. Here's everything that actually went into building it - the stack, the mistakes, and the plugin that cost me two days.

The WordPress Reality Check

I thought choosing WordPress was the hard part. Building the site was the real education.

Stack decisions, a broken cookie banner, a plugin disaster that cost me two days – everything that actually went into primusmedia.online.

The Process Playbook
Intermediate
Web Dev, Design, Behind The Scenes
By the time I’d landed on WordPress, I thought the hard part was behind me. I wasn’t wrong that WordPress was the right call – I just had no idea how much of the actual system I still had to learn. What follows is that process, in order: the stack, the mistakes, the plugin that nearly took the whole site down.
The walls I hit
The stack decision
Never liked Elementor’s control feel. Wanted native Gutenberg. Landed on Blocksy + Greenshift.
Pick the editor first, the theme second.
Example: choose Gutenberg vs. a page-builder’s own logic before picking a specific theme.
The template that didn’t click
Bought a template for functionality. It didn’t fit. Ended up hand-building every page myself.
Use templates as reference, not foundation. Example: when it didn’t fit, I stopped forcing it and hand-built every page instead.
Learning by building, not reading
Custom post types, ACF fields, security, and design – learned through building the actual Projects/Playbook structure, not through tutorials first
Build the real thing first, read docs second. Example: CPTs and ACF fields clicked once I was building the real structure, not before.
Features that only looked like they worked
The theme’s subscriber section and cookie banner both looked functional and did nothing – needed a real mail plugin and a real GDPR-compliance plugin behind each one.
Test every “included” feature before you trust it. Example: both looked complete and did nothing until a real plugin sat behind each one.
The tracking that actually mattered
None of the rest of the build matters if you can’t see where a lead came from. Pixel tracking went in before the site even felt “finished.”
Build measurement before the site feels done. Example: getting tracking live early is also how the speed crash below got caught.
The speed crash
Every added feature cost load time, until performance had to become its own project.
Budget time for performance, don’t wait for it to break. Example: every feature chipped away at load time until it had to become its own project.
The blog plugin call
Free options didn’t hold up. The paid plugin was the only one that worked for the workflow.
Test free options first, but don’t marry them. Example: free plugins didn’t hold up; the paid one actually worked for the workflow.
The translation plugin disaster
Free translation plugin → broke the site → two-day-old backup restore to undo it. The most expensive “free” decision of the whole build.
Pay for anything that touches content integrity. Example: the free plugin broke the site badly enough to need a two-day-old backup restore.
The logo, redone
The AI-generated logo export turned out to be a broken raster file – not production-ready. Rebuilt the mark myself in Illustrator.
If it’s not right, it doesn’t ship. Example: the export was broken, so I rebuilt the mark myself instead of shipping it broken.
The build, in order
Attempt 1 – Foundation: stack and environment
I’d never liked how Elementor handled control – the way it locks you into its own editing logic instead of working with what’s already there. I wanted Gutenberg, native, no fighting the editor. That’s what put me on Blocksy + Greenshift.
I built the early version in Local by Flywheel – a local, offline WordPress environment – so I could experiment without anything being publicly live. Once the foundation held, I migrated everything to Hostinger and kept building directly on the live server from there.
Attempt 2 – The template that didn’t click
I bought a premium template first, thinking it would give me the functionality I needed out of the box. It didn’t fit the way I actually worked.
So I stopped trying to make it fit – and started building every page myself.
The lesson that kept repeating
The theme promised features it didn’t have. The subscriber section looked complete – it did nothing, until I added a real mail plugin behind it. The cookie banner displayed fine and complied with nothing, until I added a real consent plugin too.
Pixel tracking was the piece that actually mattered: built it, linked it, made it work – because none of the rest matters if you can’t see where a lead came from.

Then the speed crash hit. Every feature I’d added chipped away at load time until it fell off a cliff, and performance had to become its own project. After the pass: 1.2s Largest Contentful Paint, 0.02 Cumulative Layout Shift – the numbers this site runs on now.

The blog plugin call went the same way – free options first, paid plugin because it was the only one that actually worked.
The disaster
I wanted to translate the site myself, so I picked a free translation plugin instead of a paid one. Biggest mistake of the whole build. It broke the site badly enough that I had to restore from a backup two days old just to get rid of it. There’s a reason the good ones are paid.
What happened next – learning the system for real
Once I was building instead of assembling, everything else followed: custom post types, ACF fields and how to link them together, security, design – all learned by actually building the Projects and Playbook structure and the service pages, not by reading about them first.
The result
primusmedia.online is live – built page by page, decision by decision, on infrastructure I actually own. Every wall above is part of why it works the way it does now.
“Redoing the logo myself instead of shipping a broken export is the Craftsman Standard in one image – if it’s not right, it doesn’t ship, even when I’m the only one who’d ever have known.”
The playbook – build it this way
The Craftsman Standard, in five parts.
01 – Foundation
Decide your foundation before your theme
Example: Gutenberg vs. a page-builder’s own logic is the real decision – the specific theme name is secondary.
02 – Structure
Use structure first, content second, and know why
Example: custom post types and ACF fields went in before a single real page was built.
03 – Precision
Set the goal for every “included” feature: proven, not assumed
Example: the subscriber button “worked” until someone actually tried to subscribe.
04 – Velocity
Launch and create to see what actually works
Example: pixel tracking went live before the site felt finished – that’s how the speed crash got found and fixed.
05 – Iterate
Test the free option once, on something you can afford to lose. The translation plugin taught me that the hard way – a two-day backup restore is a worse cost than the plugin license would ever have been. Iterate everywhere except the load-bearing pieces: mail, compliance, translation. Pay for those the first time.
Example: the translation plugin was the one free option that should have been paid from day one.
Recognize any of this from your own build – or don’t want to go through it yourself?
The comparison
Decision
What it solved
Why this choice
Dev environment

Local → Hostinger

Development environment
Built and tested locally first, then migrated and kept building live
Theme layer
Blocksy + Greenshift
Page building/theme layer
Native Gutenberg control, no fighting an external editor
Content structure
CPTs + ACF
Projects/Playbook structure
Needed real structured content, not just blog posts
Subscriber signup
Mail plugin
Subscriber functionality
Theme’s built-in button didn’t actually connect to anything
Legal compliance
GDPR/consent plugin
Legal compliance
Cookie banner displayed but didn’t check or comply
Lead tracking
Pixel tracking
Lead measurement
“The biggest and most needed thing”
Site speed
Performance pass
Site speed
Feature creep tanked load time; had to be actively managed
Content publishing
Paid blog plugin
Content publishing
Only option that actually worked for the workflow
Translation
(Avoided) free translation
Only option that actually worked for the workflow
So what does this mean for you?
FOUNDATION
If you’re just starting
Decide your editor and environment before you decide your theme. Build locally first, with nothing public, so the early mistakes stay private while you’re still finding your foundation.
MID-BUILD
If you’re mid-build
Test every “included” feature before you trust it. A subscriber button or a cookie banner that looks done isn’t done until you’ve actually used it yourself.
RECOVERY
If something already broke
Don’t cheap out on the fix. If a free plugin caused the damage, that’s the signal to pay for the replacement – the cleanup always costs more than the license would have.
[Experimental / in progress]
What we’re still testing
Performance is never really “done” – every new page or feature is a small tax on load time, so it’s something I keep actively watching rather than something I fixed once.
Frequently asked questions
How long did the actual build take?

A few months of daily work, overlapping with the WordPress-vs-AI decision itself – the two weren’t really separate processes.

Would you buy a premium template again?

Not the way I did the first time – expecting it to fit out of the box. If I use one again, it’s as a reference, not a foundation.

What’s the one plugin you’d never cheap out on again?

Translation, without question. Also GDPR/consent – that’s not a place to save money either.

This is what actually goes into a site built to last, not just launched fast – and I’d rather show you the real process than sell you a shortcut.
Not ready to talk yet? Get playbook 3 the day it drops – no spam, just the process.Not ready to talk yet? Get playbook 3 the day it drops – no spam, just the process.

Expert insights, delivered!

Stay informed with the latest updates and exclusive resources for high-growth teams. Reinforces professional authority and the "Trusted by teams" badge.