03Case study · 2025Shipped

Buy a club,
ship the site.

One WordPress multisite that lets HGC launch a new golfpark's website in minutes, on-brand, with a chatbot trained on the whole group's content.

Project briefing
Client
Hollandsche Golf Club (HGC)
Year
2025
Role
Solo full-stack
Duration
~6 months
Status
● Shipped, in production
Visit hollandschegolfclub.nl ↗Visit hollandschegolfclub.nl ↗

HGC keeps acquiring new golfparks. Every time they did, the old playbook kicked in: brief an agency, spin up a fresh WordPress, redo the theme, configure plugins, train staff to update content. Months of work and a new codebase to maintain forever.

What they actually wanted was much simpler. Buy a club on Monday, have its website live by the end of the week, looking on-brand and sharing all the infrastructure of the other fifteen sites already in the group. No new codebase. No new agency. No new training.

We want to launch a new club's site the same way we'd add a row to a spreadsheet.

// The brief, paraphrased

I built it as a single WordPress Multisite. One codebase, one shared theme, one plugin stack. Each club is a subsite with its own brand layer: typography, palette, photography, a few editable content blocks. Everything underneath is the same.

Adding a new club is now a fifteen-minute job. Spin up the subsite, pick the brand variant, drop in the photography, hand the keys to whoever runs that club. They edit their own content. We never touch the codebase.

While I was in there, I rebuilt the WordPress foundation for security and performance: hardened the admin surface, locked down plugin permissions, set up proper caching layers, and tuned the database and asset pipeline. That work is what turned a stack of fragile sites into something that could carry real traffic.

On top of that, I trained a Chatbase chatbot on the entire site's content. Visitors can ask anything (“What's the dress code at Hollandsche?”, “How do I book a tee time?”) and get a sourced answer. To extend it to live data like member directories and tee times, I wrote a small MCP server that bridges the chatbot to internal systems safely.

None of this happened in a vacuum. I worked closely with HGC's internal team throughout: marketing on the brand layer, ops on the chatbot's source content, IT on the security model. The platform looks the way it does because they pushed back when I needed it.

Fig. 01 · System architecture
Utrecht
Rotterdam
Almkreek
+ 13 more
WordPress
Multisite core
MCP Server
Python · FastAPI
Chatbase
Trained on full site
Member API
Tee-times etc.
15 min

To spin up a new subsite from scratch, brand layer included.

↑ 150%

Increase in organic traffic after the performance and SEO rebuild.

↓ 38%

Drop in factual support tickets after the chatbot went live (first quarter).

What this actually unlocks

  • · New acquisitions get a site without budgeting for an agency.
  • · Brand teams ship visual variants without dev involvement.
  • · Hardened security across all sixteen subsites at once.
  • · Plugin and security updates: one deploy, not sixteen.
  • · Chatbot answers are sourced, so staff can audit them.
  • · MCP layer keeps live data scoped and isolated per club.
04 · Tech
WordPress MultisitePHP 8PythonClaude APIMCPChatbaseFastAPIMySQLCloudflare
Have something similar?

Legacy stacks rescued. New ones built properly.

Drop me a line →