“We Need a React App” and Other Interesting Questions

Somewhere in the last few years, a curious thing happened. Business owners who’d never written a line of code in their lives started arriving at conversations already knowing they needed a “React app” or a “headless setup” or a “single-page application.” The terms had entered the water supply. The technology had become the assumed starting point, before anyone had asked what the thing actually needed to do.

It’s worth understanding where a lot of that came from, because choosing the right technology shapes decisions that cost real money for years afterwards.

The default that isn’t really a default

Ask an AI tool how to build almost anything today and there’s a good chance it’ll reach for a JavaScript framework. Spin up a React app, add a headless content system, wire it all together. It’s fast, it’s confident, and it produces something that looks impressively modern within minutes.

Here’s the thing worth knowing: that’s partly a reflection of what these tools are good at, not necessarily what your project needs. Generating framework code is squarely in their wheelhouse, so it’s frequently what they offer first, regardless of whether it’s the right fit. It’s a little like asking someone who only owns a hammer what your problem needs. The answer is reliably going to involve nails.

None of this makes the technology bad. React, headless architecture, and the broader JavaScript ecosystem are genuinely excellent for the right jobs. The issue is the assumption that they’re the right job for every job, and the quiet way that assumption has become the industry’s default starting position without much scrutiny.

What gets lost when you start with the answer

When the technology is decided before the problem is understood, you can end up paying for complexity you’ll never benefit from.

A modern JavaScript build can be the perfect choice for a highly interactive application: a dashboard, a tool people use for hours, something with a lot of moving parts updating in real time. It can also be wildly over-engineered for a business that mainly needs to publish content, rank well in search, load quickly, and be easy for a non-technical team to update. For that business, a simpler approach can be faster to build, cheaper to run, and far less demanding to maintain.

The cost of starting with the answer isn’t always visible at launch. It shows up later: in hosting that’s more complex than it needed to be, in a site that’s harder to update than the team was promised, in the developer time required to maintain a sophisticated setup that was never warranted by the actual requirement. You can absolutely pay premium rates for a solution to a problem you didn’t have.

What comes before choosing the right technology

The right technical decision falls out of something that has nothing to do with technology: understanding how the business actually works.

What is this thing for? Who uses it, and how often? Does the content change daily or twice a year? Does it need to do clever, interactive things, or does it need to be fast, findable, and simple to run? How will it grow? What does the team maintaining it actually know how to do? Until those questions have answers, choosing a technology is guesswork dressed up as expertise.

This is exactly the gap that consultation fills and that a quick technical answer skips straight past. An experienced partner’s value isn’t knowing how to build a React app. Plenty of tools can produce one. The value is in knowing the full range of options and matching the right one to your situation. Sometimes that genuinely is headless. Sometimes it’s a lighter JavaScript approach. Sometimes it’s a static site that’s almost free to host and nearly impossible to break. And sometimes, for plenty of perfectly good businesses, it’s still WordPress or a similar platform that the team already understands and can run themselves without calling anyone.

Modern doesn’t mean complicated

There’s a quiet assumption underneath all this that newer and more complex equals better. In software, it often doesn’t. The best technical decision is the one that fits the problem, the budget, the people who’ll maintain it, and where the business is heading. Sometimes that’s genuinely cutting-edge. Sometimes the most modern thing you can do is choose the simple, proven option that does exactly what’s needed and nothing you’ll be billed for later.

So if you’ve arrived at a project already certain you need a particular technology, it’s worth holding that certainty loosely. Not because it’s wrong, it might be exactly right, but because the certainty is worth earning through a proper look at the problem rather than inheriting it from whatever the tools reached for first.

The conversation worth having isn’t “which technology do we use.” It’s “what are we actually trying to do, and who’s it for.” Get that clear, and the right technology tends to choose itself. That’s the conversation we like to start with, every time.

Simon Paul is a Business Solutions and Technology Specialist at Code Brewery who’s spent 25+ years matching the right technology to the right problem, which isn’t always the fashionable one. He’s a firm believer that the best technical decision is the one you don’t have to pay for twice. Reach out to Simon to talk through what genuinely fits your next project.