Work
Four websites I built, each with a technical write-up: what the organisation does, which solution it got, and what the owner can change without me. All four are live — every write-up links to the running site.
Updated
Projects
Four different solutions — from a headless CMS to plain HTML.
- A Language School Website with Astro.js and SanityA course catalogue, a news section, a gallery and testimonials — content that changes every season. Here is why this project got Astro.js with Sanity CMS rather than WordPress.
- An Association Website with WordPress and DiviAn organisation where the content is written by staff and volunteers rather than developers. Here is why this project got WordPress with Divi, even though I recommend Astro.js elsewhere.
- A Multilingual Website for a Children's CentreThree languages, a catalogue of clubs and a schedule that has to be updated every season. Here is what being multilingual really means for the amount of work, and how it is handled technically.
- A Farm Website Without a Content SystemA project where the right decision was to add nothing. No CMS, no store, no plugins — only as much as it takes for the farm to be found in search and called.
How to read these write-ups
Each write-up is technical rather than promotional: what the organisation does, which stack it got, why that one, and what the owner can do without a developer. You won’t find result numbers here — I don’t publish client figures without their say-so, and what can be checked is visible on the live sites themselves.
Why the four are different
Four projects, four different solutions, and that isn’t an accident. A language school whose content changes weekly got Astro.js with Sanity CMS. An association whose team already worked in WordPress got WordPress with Divi. A children’s centre needed three languages; a farm needed one fast page and no content system at all.
Which one to suggest isn’t decided up front — it follows from who edits the content and how often. The same question is covered in more depth on business website development and speed optimization.
What all four have in common
Underneath four different stacks the baseline is the same one.
Everything is registered to the client and handed over at launch: the domain, the hosting account, the CMS and the code. Nothing is kept on my side, so continuing with a different developer is a decision rather than a rescue operation.
The technical SEO groundwork is part of the build, not a later add-on — clean HTML, meta tags, schema.org markup, a sitemap and a submission to Google Search Console. So is speed: compressed images, self-hosted fonts, and as little JavaScript as the page can get away with.
And every site is live. The links in each write-up go to the running site rather than to a screenshot, so anything I claim about speed or structure can be checked with the same tools I used.
What a write-up leaves out
The client’s numbers. No traffic charts, no conversion percentages, no before-and-after — those belong to the client, and publishing them without asking would say more about how I treat clients than about how I build sites.
What stays in is the reasoning: what the constraint was, which option was turned down, and what it would have cost to choose otherwise. That is the part that carries over to a different project.
What's next
A similar project?
Tell me what your organisation needs — I'll say which of these approaches would fit and why.
Get in touch