July 18, 2026 · by David Gilbert · 3 min read · Web & E-Commerce
I'll occasionally get a slightly surprised reaction from other developers when they find out some of the sites I build run on plain, hand-written HTML and CSS with barely a line of JavaScript in sight, no framework, no build step, nothing fashionable about it at all. In an industry that loves its frameworks, it can sound almost like a confession. I don't see it that way. For a lot of small business clients, it's exactly the right tool for the job.
What a Client Actually Needs, Most of the Time
Most small business websites need to load fast, look good on a phone, clearly say what the business does and how to contact them, and keep working reliably for years without constant babysitting. None of that requires a complex JavaScript framework. It requires good, clean structure, sensible design choices, and a hosting setup that isn't fighting against itself. Complexity that doesn't serve the actual goal is just risk wearing a fashionable outfit.
The Maintenance Conversation Nobody Has Upfront
A flashy framework-driven site often needs ongoing dependency updates, a build process, and genuine technical knowledge to maintain safely. That's completely fine if a client has a developer on retainer or genuinely needs the interactivity that justifies the complexity. It's a real problem when a small business owner is left, eighteen months later, with a site nobody locally can touch, a framework version that's gone stale, and a "simple text change" that's somehow become a half-day job because nobody's run the updates in a year.
What "Boring" Actually Buys You
A simply built site, in plain HTML and CSS, just keeps working. There's no build pipeline to break, no dependency to silently go out of date, no framework update that subtly changes behaviour three versions from now. It loads fast because there's barely anything to load. And critically, almost any web person, anywhere, in five or ten years' time, can open the files and understand exactly what's going on, because it's not hidden behind layers of tooling specific to whatever was fashionable the year it was built.
Where I Do Reach for More
I'm not dogmatic about this — when a project genuinely needs rich interactivity, a complex booking system, or something a framework handles far better than hand-rolled code would, I'll use the right tool for that job without hesitation. The point isn't "frameworks are bad." The point is matching the complexity of the build to the complexity of the actual problem, rather than defaulting to whatever's currently fashionable because it's fashionable.
The Quiet Professional Choice
There's a kind of unglamorous discipline in choosing the simpler build when it's genuinely the better fit, even though it won't impress anyone in a portfolio review the way a flashy animated framework-driven site might. I'd rather hand a client something that quietly works for the next decade than something that wins a design argument today and becomes a maintenance headache for someone, possibly them, possibly me, eighteen months from now.
If a web professional ever talks you out of unnecessary complexity rather than into it, that's usually a good sign, not a red flag. The flashiest-looking option in a demo isn't always the smartest long-term investment for an actual small business.