Not Every "Best Practice" Is Worth Your Time

Article spoiler:The web development industry produces a new must-have every few months. Most of them solve real problems, but not your p…We care about our clients, so we made a short takeaway from this article. Press to quickly get the point.

The web development industry produces a new must-have every few months. Most of them solve real problems, but not your problems. Our renovation framework separates structural work from trends. The three questions at the end are what we ask before we agree to build anything.

Picture a scenario we have seen play out more than once. A 15-person professional services firm, good reputation, and a steady client base. Someone in their network who is well-meaning and technically informed tells them their website is behind. The list arrives: headless CMS, AI chat assistant, cookie consent management platform, and full analytics overhaul. A previous agency priced it at €28,000.

We asked what problem they were actually trying to solve.

The site had not been updated in three years. It loaded in 7 seconds on mobile. And the contact form was broken. Submissions were going nowhere, silently, for four months. Not because anyone was careless. Because nobody had a reason to check.

It was not a slow quarter.

We fixed the form, optimized the images, updated the content, and addressed the load time. Total cost was a fraction of the original quote. The headless CMS, the AI assistant, and the analytics overhaul were all irrelevant to the real problem.

This is not a story about a bad agency. The recommendations were not wrong. They were current best practice. The issue was context.

The renovation framework and why it changes how you should read any proposal

When you renovate a space, a good architect separates three categories of work.

Structural: fix the wiring, or nothing else matters. Practical long-term investment: better insulation and quality flooring that lasts 20 years. These pay off regardless of your taste. And what the architect finds interesting right now: a statement wall, underfloor heating throughout, and a smart home system.

All three can look equally important in the proposal. Your job, and ideally the architect's job, is to separate them.

Web projects work the same way. A site that takes 6 seconds to load on mobile loses visitors before they read a single word. Google's own research puts the threshold at 3 seconds. Above it, 53% of users leave (Google/SOASTA, 2017). That is not a trend. It is infrastructure. True five years ago, true five years from now.

A CMS that lets your team update content without calling a developer. Useful if you publish regularly. Genuinely worthless if you update the site twice a year and have no plans to change it.

An AI chat widget on a 5-page brochure site. That is the statement wall.

Three technologies everyone overestimates right now

AI chat assistants appear on almost every agency proposal at the moment. There are good use cases. High-traffic e-commerce with complex product questions. Service businesses where variables are hard to explain in static text. But we have audited sites where the widget was installed on a small firm's brochure page. It answered questions already covered more clearly in the FAQ two scrolls below. Monthly subscription. Ongoing training required to prevent wrong answers. Confusing to visitors who do not understand why a robot is appearing in the corner.

Not bad technology. Wrong context.

Headless CMS architecture is real. The technical case is real. Better performance. Cleaner separation of content and presentation. We use it on the right projects. But a headless setup requires a developer every time something breaks. For a company whose marketing manager used to update content in WordPress without asking anyone, this is not a step forward. It is a dependency they did not have before.

Full analytics stack overhauls. Tag managers, custom event tracking, and multi-touch attribution models. We have helped teams install this when it fits the way they operate. A more sophisticated system does not create the habit of using it for teams that look at analytics twice a year and do not act on what they find. It creates a sophisticated system nobody uses. It also creates a maintenance overhead that someone has to own.

The pattern across all three is simple. Each tool solved a real problem. It just was not the problem for that business.

What we've never regretted recommending

Site speed. Always. Every 1-second improvement in load time increases conversions. Google's 3-second threshold on mobile is a floor, not a guideline. We prioritize this on every project, full stop.

Some form of content independence. The ability to update a phone number, a price, or a service you no longer offer without calling a developer. Not because you'll do it weekly. Because the moment you cannot do it at all, the site starts working against you.

Security hygiene. HTTPS. Updated dependencies. No exposed admin panels. Not exciting. Missing them is expensive.

Everything else depends on your traffic volume, your team's capacity to maintain what gets built, your actual publishing cadence, and who your users are.

The three questions we ask before recommending anything

These came out of too many projects where technically correct decisions created ongoing problems for companies without the resources to maintain them.

What breaks if we do not build this? If the answer is "nothing specific, it would just be better", that is a signal. Not a veto. A signal. Improvements with no clear cost to inaction get deprioritized in favor of things that do.

Who owns this after we leave? We have taken over projects where the previous team built something technically impressive. The client could not touch it. Could not update it. Could not explain it to a new developer without a two-day handover. That is not a deliverable. That is a liability.

Would you still want this if it cost twice as much and took twice as long? When the answer is genuinely yes, build it. When it's "well, at that price, maybe not", you have found the real threshold.

The best web solution for most SMEs is the one that does exactly what is needed. It can be maintained by any competent developer, even after the initial team is gone.

That is the goal.

---

If you are looking at a web proposal and you are not sure which line items you actually need, that's the right question to be asking before you sign anything. We do scoped assessments. No obligation to build with us afterward. We separate the structural work from everything else for your specific situation. Get in touch.