Your Website Does Not Have a $60K Problem

Key takeaways:

• A headless CMS and custom API integrations will not fix a mobile experience problem or broken search. Matching the solution to the actual problem saves tens of thousands of dollars.
• Enterprise agencies routinely pitch enterprise solutions to mid-market businesses because that is what enterprise agencies know how to build, not because it is what the client needs.
• The best technology your business can adopt is the technology your existing team can actually operate. Complexity has a cost that extends well beyond the implementation invoice.

When a $60K Proposal Is Really a $14K Fix

A few months back I had a discovery call with an education provider based near Orchard Road. Twenty staff. One marketing coordinator. A decent reputation built over years of word-of-mouth in Singapore’s competitive tuition and enrichment market.

They came to me because another agency had handed them a proposal. The number at the bottom was $60,000. The scope included a headless CMS, custom API integrations, a content delivery network, and a six-month implementation timeline. It read like a brief written for a regional media company, not a 20-person education business with one person managing all their marketing.

Before I looked at a single page of their existing website, I asked them one question. What is the actual problem you are trying to solve?

The answer had nothing to do with content delivery networks. Admissions enquiries had dropped 30% over the year. Parents were landing on the site from mobile and could not find programme information. The search function was broken in a way that had probably been broken for months without anyone noticing.

That is not a transformation problem. That is a fixable website problem. We scoped it at $14,000. Proper mobile experience, working search, cleaned-up programme pages with clear calls to action. Nothing exotic. Nothing that requires a six-month timeline or a dedicated technical team to maintain after launch.

The delta between $14,000 and $60,000 was not value. It was complexity the client did not need and could not sustain.

Why Do Agencies Keep Pitching the Wrong Solution?

Enterprise agencies pitch enterprise solutions because enterprise solutions are what they know how to sell and build. This is not malicious. It is structural. If your agency has a team of developers who specialise in headless architecture and API integration, that is what your proposals are going to feature. The hammer finds nails everywhere it looks.

I have been building websites since 1998, and I have watched this pattern repeat across every technology cycle. In the early 2000s it was Flash intros and custom-built CMS platforms. Around 2010 it was mobile apps for businesses that did not need apps. By 2015 it was “omnichannel digital experiences” for companies that could barely manage a single channel. The tools change. The overselling does not.

The other force at work is the way enterprise pitches are structured to appear credible. A $60K proposal with technical architecture diagrams looks more serious than a $14K proposal that says “your mobile experience is broken and your search is broken, let us fix those two things.” Simplicity reads as underconfidence in a pitch document. Complexity reads as expertise. Clients who have not been through enough of these processes often cannot tell the difference.

What Does a Headless CMS Actually Solve?

A headless CMS separates the content layer of your website from the presentation layer, which means your content can be delivered to multiple front-end environments — a website, a mobile app, a digital display — without duplicating the content management work. It is genuinely useful architecture for specific situations.

Those situations include businesses managing content across multiple platforms and channels simultaneously, organisations with large development teams who need flexibility in how the front-end is built, and companies with enough content volume and distribution complexity that the overhead of maintaining a headless setup is justified by the efficiency gains.

A 20-person education provider in Singapore with one marketing coordinator does not fit any of those categories. Their content lives in one place. They need one person to be able to update programme descriptions, term dates, and pricing without filing a support ticket. A headless CMS does not give them that. It gives them a more complicated editorial workflow and a dependency on technical support every time something breaks.

The content delivery network in that proposal had the same mismatch problem. CDNs reduce latency by serving assets from servers geographically closer to the end user. For a global media platform or an e-commerce business with high traffic volume across multiple regions, the performance gains are meaningful. For a Singapore education provider whose audience is almost entirely Singapore-based parents browsing on mobile, the problem was never geographic latency. The problem was that the mobile layout was broken and slow regardless of where the assets were being served from.

How Do You Figure Out What the Real Problem Is?

You look at the data before you write the brief. This sounds obvious. I have found it is not.

When my team at Chillybin does a discovery conversation with a new client, we spend time in their analytics before we discuss solutions. Where are people dropping off? Which pages have high bounce rates on mobile? What are people searching for that the site is not surfacing? What does the enquiry or conversion path actually look like from a first visit to a completed form?

For this education provider, that process took a few hours. The mobile experience was the source of the drop-off. Parents searching for specific programmes were hitting the broken search and leaving. The fix did not require architectural transformation. It required someone to actually look at what was happening.

A useful framework I have applied for years is the distinction between a presentation problem, a performance problem, and a technology problem. Presentation problems are about how content is structured, displayed, and navigated. Performance problems are about how fast and reliably the site operates. Technology problems are about whether the underlying platform can actually support what the business needs to do. Most mid-sized businesses with website problems have a presentation problem or a performance problem. Very few have a technology problem that justifies rearchitecting the entire system.

The education provider had a presentation problem on mobile and a performance problem with search. Neither of those required new infrastructure.

What Happens When You Implement a Solution Your Team Cannot Use?

The invoice gets paid, the project gets delivered, and then the site slowly degrades because no one on the team has the skills to maintain it. I have seen this happen more times than I can count, and it has a consistent shape.

The enterprise agency builds something technically impressive. The handover documentation is 40 pages long. The marketing coordinator who is supposed to manage the site attends a two-hour training session and comes away understanding about 20% of what they need to know. Six months later, the programme pages are out of date because updating them requires steps no one remembers. A year later, the client is back in the market for another agency because the site has drifted into a state of low-grade dysfunction.

The $14K solution I scoped for that education provider was built on a platform their one marketing coordinator could actually operate. Standard WordPress with a page builder they had used before. No custom API connections to maintain. No headless infrastructure to troubleshoot. When term dates change, they change them. When a new programme launches, they add a page. The site works because the team can manage it without outside help for routine updates.

Sustainability of the solution is a question that almost never appears in an enterprise pitch document, because sustainability is not exciting and does not justify a $60K budget. It should be one of the first questions a client asks.

Is Simpler Technology Actually Less Capable?

For most mid-sized businesses, simpler technology is not a compromise. It is the correct answer.

WordPress powers around 43% of websites on the internet as of this year. It is not dominant because it is the most technically sophisticated option. It is dominant because it is flexible enough to handle most real-world requirements, well-documented enough that any competent developer can work with it, and accessible enough that non-technical team members can manage content without ongoing agency support. Those are competitive advantages, not limitations.

I say this having used WordPress since 2003. I have built everything from simple brochure sites to large content platforms on WordPress over those 20 years. I have also built on other platforms. The pattern I keep returning to is that the best platform for any given client is the one that matches their team’s capabilities and their actual workflow requirements, not the one that demonstrates the agency’s technical range.

The education provider near Orchard Road did not need to demonstrate technical sophistication in their choice of CMS. They needed parents to find programme information on mobile and submit an enquiry. That is a solvable problem with straightforward tools, and solving it does not cost $60,000.

The gap between what a business needs and what it gets sold is often widest in the mid-market, where companies are large enough to have real budgets but not large enough to have technical leadership that can push back on proposals. If you are in that position, the most useful thing you can do before signing anything is get a second opinion from someone who has no financial interest in selling you a particular solution. Ask them to tell you what the actual problem is. Then ask whether the proposed solution is the simplest thing that solves it.

Usually it is not. Usually there is a $14K version sitting right next to the $60K one, and the only difference is that nobody thought to look for it.