ACT III · Build
Why I Build in Next.js Instead of WordPress for Most Client Projects
Not a religious framework war. A specific set of trade-offs I keep landing on the same side of.
WordPress powers a huge share of the web, and for plenty of use cases it's a genuinely reasonable choice. TFLYX.com itself is built in Next.js — App Router, TypeScript, Tailwind — and most client builds follow the same path. Here's the honest reasoning, not a framework tribalism take.
What I'm actually optimising for
- ■Speed — a Next.js site, built cleanly, tends to load faster out of the box than a plugin-heavy WordPress install, and speed is directly tied to the trust and conversion research covered elsewhere in this archive
- ■Design freedom — motion, custom layouts and interaction design are more natural to build in React/Next.js than to force through a WordPress theme and page builder stack
- ■Security surface — WordPress's popularity makes it a bigger, more consistent target; fewer plugins and a smaller attack surface generally means less to keep patched and monitor
- ■Long-term maintainability — a codebase I fully understand and control end to end, versus inheriting a theme and plugin stack built by several unrelated third parties
Where WordPress genuinely still makes sense
A content-heavy site run by a non-technical team who need to publish frequently, with an existing WordPress-fluent workflow, is a legitimate case for sticking with it — the ecosystem of plugins and the editorial experience are mature and battle-tested. If a business already has WordPress infrastructure working well, ripping it out for the sake of a different framework isn't automatically the right call.
The trade-off I'm accepting
A custom Next.js build generally costs more upfront than a templated WordPress site, and content editing requires a CMS layer to be built in rather than arriving out of the box. I accept that trade-off because the sites I build tend to prioritise performance, custom design and long-term technical health over the fastest, cheapest possible launch — which is exactly the kind of site most SME businesses actually need once they're past the earliest, most price-sensitive stage.
Next.js, GSAP, WebGL, and a custom motion system — one person, no template, no agency.
Why every TFLYX package still includes a CMS
The Business tier and above include a CMS specifically so this technical choice doesn't cost clients editorial control. "Custom-built" doesn't mean "you need a developer to change a sentence" — it means the underlying code is faster and more maintainable, while the day-to-day editing experience stays accessible.
Want a site built on modern, fast foundations?
Custom-built, properly maintained, and still editable by you — not locked behind a developer.
More from ACT III · Build
What a Website Maintenance Plan Actually Covers (And Why "Set and Forget" Is a Myth)
A website isn't a purchase you complete once. Here's what actually needs ongoing attention, and why.
Building CounterMate: Designing Software for Retail Counters, Not Boardrooms
The second blade of the SME toolkit — still in development, and being designed for a very different user than most business software assumes.
What Happens After You Book a Website Package — A Behind-the-Scenes Walkthrough
No mystery, no black box. Here's the actual process from booking to launch.