The case for boring technology on a client's marketing site

It's genuinely tempting, as a technically curious team, to build every single client project on whatever specific framework happens to be generating the most excitement and buzz that particular quarter. We've mostly, deliberately resisted that temptation for actual client marketing sites over the years, and that discipline has saved more than one client from unknowingly inheriting a codebase built on a tool that quietly lost meaningful community support just two years after their site originally launched.

Most marketing sites fundamentally need to be reasonably fast, genuinely easy to update over time, and realistically maintainable by whoever eventually inherits the codebase next, none of which actually requires using the very newest framework release available. Well-established, actively and reliably maintained tools like Next.js and Tailwind CSS hit all three of those requirements comfortably, without betting a client's important long-term digital asset on something still fundamentally unproven in production.

A client's next developer, whether that's someone hired in-house or brought on at a completely different agency down the road, needs to be realistically findable and reasonably competent quickly when the time comes. A widely used, thoroughly well-documented technology stack has a considerably deeper available hiring pool than a niche or genuinely bleeding-edge framework does, which matters enormously the day a client eventually wants to switch vendors or bring development capability in-house.

We experiment freely and constantly with newer tools on our own internal projects and other genuinely lower-stakes work. A client's primary marketing site or core product though, the actual thing their real business measurably depends on day to day, gets the boring, well-proven choice instead, because the real cost of being wrong there is considerably higher than the modest cost of simply missing out on a trendier technical option for a while.

Before recommending any newer tool for client work, we run it on at least one lower-stakes internal project first, watching specifically for how actively it's maintained, how responsive the maintainers are to real issues, and how the surrounding ecosystem is actually growing over time. Only tools that clear this internal bar for a sustained period earn a place in our default client recommendations.

Our own internal tooling, project management systems, internal dashboards, gets rebuilt and experimented with far more freely than any client-facing product ever would, precisely because the cost of being wrong there is contained entirely within our own team. That contained-risk environment is exactly where we build the real experience that eventually informs which newer tools are mature enough to recommend for client work down the line.

One client came to us wanting to rebuild a site originally built three years earlier on a framework that had, by the time they reached out, been effectively abandoned by its small maintaining team, with no security patches and a shrinking community of developers still willing to work in it. The rebuild cost considerably more than the client's original build had, purely because so little of value could actually be carried forward, and finding a developer even willing to touch the old codebase long enough to migrate it away had become genuinely difficult.

We use this real example directly in conversations with founders tempted by a newer, more exciting framework for their own upcoming project, not to argue that new technology is inherently bad, but to make the real, concrete cost of guessing wrong tangible rather than abstract and easy to dismiss in the moment.

Some clients, particularly technical founders and CTOs, genuinely want to use the newest available tooling themselves, and pushing back too hard against that instinct can read as overly conservative or out of touch with where the industry is actually heading. We frame the conversation around risk allocation rather than a blanket no: which parts of this system are load-bearing for the business and need long-term stability, and which parts are lower-stakes enough to reasonably serve as a genuine testbed for something newer and less proven.

This framing usually lands well with technically sophisticated clients specifically, since it respects their own genuine technical judgment while still steering the business-critical core of the system toward the more conservative, better-supported choice where it actually matters most to the business's long-term stability.

Even a genuinely well-established, currently boring technology choice eventually starts to show its age, and waiting too long to notice that shift can leave a client on an increasingly outdated foundation without anyone actively flagging the change. We watch for a specific set of signals across our whole client base: declining commit activity and community engagement on the underlying project, a shrinking available hiring pool for that specific stack, and newer tools clearly, consistently outperforming it on the metrics that actually matter for that use case.

Catching this shift early, while the technology is still perfectly functional but visibly starting to decline in relative relevance, gives a client time to plan a deliberate, well-timed migration on their own schedule, rather than being forced into a rushed, reactive one once the underlying technology has genuinely become a real liability.

Occasionally a client's competitors are genuinely shipping features enabled by newer technology that a conservative stack can't easily match, and defaulting reflexively to boring technology in that specific situation would be its own kind of mistake, trading real competitive relevance for a stability the business may not actually be able to afford to prioritize right now. We weigh this explicitly rather than applying the boring-technology default rigidly and universally in every single case.

The underlying question stays consistent even when the answer sometimes changes: what's the real cost of being wrong in either direction for this specific client, at this specific moment in their business's life, given their specific competitive situation right now.