Case study · Content platforms
A bilingual platform for a festival with thirty years of history
Baltic Sea Docs is a documentary film festival in Riga. It needed a platform that could carry a live programme, three decades of archived editions, and an open call for projects — in two languages, maintained by the festival’s own team.
- Client
- Baltic Sea Docs
- Role
- Sole engineer
- Languages
- English & Latvian
- Origin
- Designer referral
- Status
- In production · 2026
The brief
A festival website has two jobs that pull in opposite directions. For a few weeks a year it is a live programme that has to be accurate to the hour. The rest of the time it is an archive — the record of who screened, pitched and decided, going back three decades.
Most festival sites solve the first job and neglect the second. The brief here was to build both properly, in English and Latvian, on an architecture the festival team could maintain themselves rather than commissioning a developer every time the programme changed.
Constraints that shaped the build
Two languages, equal weight
Neither language could be a translation afterthought. Every content type needed a parallel structure, and editors needed to see at a glance what was still missing in the other language.
Thirty years of unequal records
Historical editions do not hold the same detail as recent ones. The archive model had to stay consistent enough to browse and search, while tolerating editions where whole categories of information simply do not exist.
Editors, not developers
Everything that changes annually — programme, participants, partners, open call — had to be editable in the WordPress admin without touching code or arranging developer time.
A fixed public moment
Programme publication is announced in advance and cannot slip. That shaped the delivery order: the content model and the programme system first, refinements after.
How it was approached
Five decisions carry the build. The margin notes are the evidence: what each decision concretely produced.
A content architecture built around the festival’s own vocabularyn.01
Rather than bending pages and posts into shapes they do not fit, the platform models what the festival actually has. The admin reads like the festival’s own language, which is what makes it maintainable without a manual.
A custom programme and schedule systemn.02
The programme is generated from structured entries rather than hand-built pages. Visitors filter the listing down to what they care about, and the same underlying data serves both the current edition and the archive.
An archive designed to stay coherentn.03
Roughly thirty years of editions are held in one consistent structure, browsable by year and filterable across categories, with each edition degrading gracefully where historical detail is thin.
Project submissions inside the platform
The open call runs on the site itself: submissions arrive as structured records the team can review in the admin, instead of as email attachments to be collated by hand. The public result is published from the same model.
A bilingual frontend, built to the design
A custom responsive theme implemented from the designer’s work — no page builder, no theme framework to fight — serving both languages from the same content model.
Discoverability and privacy are handled in the same spirit: a custom SEO and sitemap architecture covers every content type in both languages so archived editions remain findable, and cookie consent is implemented in production rather than bolted on.
Outcome
The festival has a platform where the programme, the participants and thirty years of archive share one content model, in two languages, maintained in-house.
The engineering result that matters most is boring on purpose: an annual edition is now a content task rather than a development project. Nothing in the yearly cycle requires me.n.04
- WordPress
- Custom theme
- Custom post types & taxonomies
- Bilingual content model
- Custom SEO & sitemap
- Consent
- Production deployment
What I deliberately did not build
Scope discipline is most of what makes a fixed price work. Three things were left out on purpose.
No page builder
Editors get purpose-built fields instead of a canvas. Fewer ways to break the layout, and the design stays as it was drawn.
No plugin for every requirement
Where core WordPress already had the concept, it was used. Each avoided plugin is one fewer thing to update, pay for and debug in three years’ time.
No custom admin interface
The WordPress admin the team already knew was extended rather than replaced, which removed the need for training and for maintaining a second interface.