The site has to change identity every year
New edition, new poster, new colour, new dates. On a template that means a redesign conversation every single year. On the festival site I built, the whole brand runs off one CSS colour token — the organizers re-skin it themselves in about a minute, with no developer and no rebuild.
The date is public and immovable
A festival can't slip. Opening night is opening night, and a site that lands late is worse than useless. That's why the scope, price and two-week timeline are fixed up front rather than discovered along the way — and why anything that would genuinely expand scope becomes an explicit conversation instead of a silent overrun.
Whoever edits it next year wasn't trained this year
Festival teams turn over. The site gets edited furiously for six weeks, abandoned for ten months, then edited again by a partly different set of people. So the CMS isn't optimised to be powerful — it's optimised so a volunteer can open it in October, having last touched it in March, and not be confused.
Photos arrive faster than anyone can upload them
During the event, the person with the photos is at the venue on their phone between screenings. Nobody is logging into an admin panel. So organizers drop photos into the shared Drive folder they already use, and they appear in the homepage gallery — no upload step, nothing to learn.
Audiences decide on a phone, in a hurry
Programme, times, venue, tickets — usually checked on mobile, often on bad wifi. The old Google Sites page scored 37 on mobile and visibly shifted around as it loaded, which costs trust at exactly the moment someone is deciding whether to come.