We just rebuilt brcg.co from scratch. Took a weekend.
That sentence should concern you if you're running a marketing agency. We're supposed to be the ones who know how to do things efficiently. And yet, our own website was a bottleneck.
The WordPress Problem Nobody Talks About
Our old WordPress site was fine. It worked. Pages loaded. Forms submitted. The basics were covered.
But here's what "fine" actually looked like:
Publishing anything took forever. Want to add a case study? That's a project. New blog post? Hope you remember how the theme handles featured images. Landing page for a campaign? Block off half a day and pray the plugins don't conflict.
Maintenance ate our budget. Plugin updates. Security patches. Theme compatibility issues. We were spending more per year keeping the site running than we would have spent rebuilding it from scratch.
The site didn't match how we work. We tell clients to move fast, iterate, test. Our own site was the opposite. Every change felt risky. Every update was a production.
Why Lovable.dev
We'd been watching the "vibe coding" movement for a while. Tools like Cursor, Bolt, Replit Agent. The promise: describe what you want, get working code.
Lovable.dev caught our attention because it's specifically built for full-stack web apps. Not just landing pages. Real applications with databases, auth, integrations.
We didn't make this decision lightly. We evaluated it against a traditional rebuild, against other no-code tools, against just living with WordPress.
Here's what tipped the scales:
Speed to first deploy. We had a working site in hours. Not a template. A real, custom site that matched our brand.
React + Supabase under the hood. This matters. When you need to extend beyond what the AI can generate, you're working with real code. Not proprietary garbage.
Cost structure makes sense. The math was simple: Lovable subscription + hosting is less than we were paying for WordPress maintenance, security, and the occasional emergency fix.
What Actually Changed
Let's talk results.
Content goes live in hours, not weeks. I wrote this blog post. It's going to be live today. With WordPress, that same post would have taken a week minimum. Theme formatting, image optimization, SEO plugin configuration, scheduling, QA.
The site reflects how we work now. Fast iteration. Clean design. No bloat. When a client asks "can you do X," we can show them our own site as proof we practice what we preach.
We spent less rebuilding everything than we did maintaining WordPress for a year. I'll say that again because it's worth sitting with. The full rebuild cost less than annual maintenance of the old site.
We control our own stack. No more waiting for plugin developers to fix bugs. No more theme updates breaking layouts. The code is ours.
The Harder Lesson
This isn't really about WordPress vs. Lovable. Both are valid tools for different situations.
This is about auditing your own stack.
We help clients do this constantly. Look at your tools. Ask hard questions. Is this still the right solution? Are you paying a "legacy tax" because switching feels hard?
And yet, we'd been running the same WordPress setup for three years. Not because it was optimal. Because it was there.
The rebuild forced us to question everything:
- Why are we using this plugin?
- Do we actually need this feature?
- What would we build if we started fresh today?
Half the features we had on the old site didn't make it to the new one. Not because we forgot them. Because we realized we didn't need them.
Should You Switch?
Maybe. Here's how to think about it:
Switch if:
- Publishing content feels like a project
- You're spending significant budget on maintenance
- Your site doesn't reflect your current capabilities
- You have technical resources who can work with React/TypeScript if needed
Stay if:
- WordPress genuinely works for your workflow
- You have a dev team that's optimized for WordPress
- Your site is complex with many integrations that would be painful to migrate
- "If it ain't broke" genuinely applies
The goal isn't to chase shiny tools. The goal is to remove friction from the things that matter.
For us, publishing content matters. Showing clients what modern looks like matters. Practicing what we preach matters.
WordPress was getting in the way of all three.
What We'd Do Differently
A few lessons from the trenches:
Plan your data migration early. We had blog posts, case studies, form submissions. Moving that data took longer than building the new site. Start there.
Don't try to recreate everything. We used the rebuild as an excuse to simplify. Fewer pages. Clearer navigation. Less cruft.
Document your integrations. What's connected to your current site? Analytics? CRM? Email? Make a list before you start.
Give yourself permission to ship imperfect. Our first deploy wasn't feature-complete. It was good enough. We've been iterating since.
The Point
The tools you picked three years ago might be slowing you down today.
That's not a criticism. That's just how technology works. What was optimal then isn't necessarily optimal now.
We audit client stacks constantly. We ask hard questions about whether their current tools serve their current goals.
This was us taking our own medicine.
If you're curious about making a similar move, happy to share more details. What worked, what didn't, what we'd do differently.
When's the last time you audited your own stack?
