A publishing system the organisers can actually run — without a dev cycle.
CrownX built a flagship site and content backbone for Revitalise WCS — a community organisation publishing events, training and updates weekly. The goal was simple: give non-technical organisers the tools to ship without waiting on us.
Every update was queued behind an engineer.
Every update used to require a developer. Event dates, training schedules, news posts — all bottlenecked on a single engineering queue, no matter how small the change was.
The organisers shipping the actual programs had no way to push updates themselves. A new event could not go live without a code change, which meant the cadence of the site never matched the cadence of the organisation.
Design drift was creeping in too. Each new content type was slightly different from the last, because every surface had been built ad-hoc rather than from a shared model. The site felt inconsistent, and it was getting harder to extend.
The system we built.
A structured content model, a publishing UI organisers can actually use, and automatic rendering across every surface — so shipping a new event is a draft, not a dev ticket.
Structured content model
Events, sessions, posts and people are first-class content types — not fields hacked into a WYSIWYG editor. That means every surface pulls from the same shape, every time.
A publishing UI organisers own
Draft, preview, schedule and publish directly from a purpose-built studio. Non-technical staff manage events, sessions and posts the same way they manage a calendar invite.
Automatic rendering
New content appears on the right surface without manual placement. Add an event — it surfaces on the home page, events index and session detail automatically. No handholding, no stale lists.
Guardrails and schema validation
The system rejects broken events before they publish — missing dates, orphaned sessions, malformed links. Organisers get a clean error, not a broken page.
Where it was breaking.
- Every update queued behind an engineer
- Slow, unpredictable publishing cadence
- Design drift across event and content types
- Dependent on engineering availability
- Content shape differed from surface to surface
- Organisers waited days for a small change to go live
How it runs now.
- Organisers publish directly, multiple times a week
- Consistent cadence that matches the organisation
- Design held by the content system, not by hand
- Zero engineering dependency for routine updates
- Single content shape across every surface
- Small changes go live in minutes, not days