For twelve years, the first question on every Digital1010 build has been the same: what does this site actually need to do?
The answer almost always pointed at WordPress.
Until this one.
Digital1010.com just relaunched as our first headless build. Next.js on the frontend, Sanity as the content layer, edge deployment. No WordPress admin. No MySQL on the public server. No PHP runtime. No 2am plugin patch.
That is a meaningful change for an agency that ran WordPress-first for twelve years. It deserves an explanation that is not marketing.
What twelve years of WordPress actually taught me
I have spent Saturdays I am not getting back debugging a plugin update that pushed itself into a client's checkout flow. I have lost a full week of agency velocity to a multisite migration that went sideways because a single theme dependency had been silently abandoned upstream. I have written more late-night Slacks starting with "the site is down" than any number I would want to admit.
That is the cost of running WordPress at scale. It is also the cost of being the agency clients trust to run WordPress at scale. We have done that for twelve years. We are still doing it today on dozens of client sites, we are still recommending WordPress for new builds where it is the right fit, and we have new WordPress projects in production this quarter. This is not the post where we walk away from WordPress. We are not.
What changed for our own site is not what WordPress can do. It is what we wanted to optimize for, on a marketing site we control end-to-end and update weekly.
Why we went headless for our own site
Three things weighted the decision for digital1010.com specifically. Each one is conditional, not categorical.
Attack surface. Our own site is publicly visible enough that we wanted to harden it as much as we reasonably could without ongoing operator drag. A headless architecture pulls the database and the runtime off the edge entirely, which collapses the surface area an attacker can reach through plugin or PHP exploits. For a marketing site we update weekly, that math worked. For a client site that depends on the WordPress plugin ecosystem for functionality — booking, e-commerce, gated content, complex forms — the same plugins that introduce risk are the ones doing the work. Ripping them out is not the answer; running them well is.
How discovery is changing. AI overviews and answer engines are pulling more attention away from the classic search-results page, and they reward content that is cleanly structured and easy to query at the API layer. We wanted our own site to be a clean reference implementation of how we think publishers should be set up for that shift. A modern WordPress site with proper schema, sound technical SEO, and a disciplined editor can be perfectly competitive here — and we still build them that way. Our site is a place we can move fast on tooling without negotiating a content team's workflow first.
Operational simplicity for our own team. Our marketing site does not need the things WordPress is genuinely great at: bulletproof editorial workflows, the largest plugin ecosystem on the web, a non-technical team running daily content updates. It needs to be fast, easy to deploy, and out of our way. A leaner stack lets the team that runs the site focus on the writing rather than the patching. For client sites where the editorial flexibility actually matters — a multi-author team, a non-technical admin who needs to add fields without a deploy, a publisher whose business is content velocity — WordPress is still the better choice, and we will keep building it that way.
How we choose stack now
For every new build, we start with the same question we have always started with: what does this site need to do for this client over the next three years?
The answer points at WordPress as often as it ever has. Plugin-driven e-commerce, content teams that need a robust editorial interface, sites that depend on a thousand-plugin ecosystem to do their actual work, organizations that need a non-technical admin able to make changes without a deploy. Those cases are common and they are real. We still build them. We still want to.
The cases where headless is the right call are the ones where the requirements lean toward speed of iteration, hardened security posture, or AI-era discovery more than they lean toward editorial flexibility. Headless is now a real second option on the table when the work fits it, instead of WordPress being the only thing we are comfortable building. That is the actual change.
Want the framework for your own build? We turned the same twelve-year decision tree into a two-minute assessment. Answer four to seven questions about what your site actually does, and you will get a personalized recommendation in your inbox, with the reasoning and the caveats specific to your answers.
Twelve years of WordPress made Digital1010 the agency it is. We are not walking away from that. We are walking toward a sharper version of the question we have always asked: what does this client actually need?
If you would rather just talk it through, send me the URL and a one-line note about what is holding you back. I will give you a straight read: whether to move, whether to stay, or what to fix where you already are.