A concept brief for an East London live-music promoter selling tickets and taking private-hire briefs from a single page. Built end-to-end to show the work — live client work shown on request.
Studio concept
Foundry Nights is a fictional East-London promoter — there's no paying client behind it. The brief was set internally to explore the events-and-private-hire double-act in a category that almost universally splits the two into separate sites that contradict each other. The visual language borrows the single-tall-page move from Ome Duo's Groningen site, but in an editorial register rather than flyer-energy. The deltas at the end are what would change on day one of a real engagement.
Foundry Nights is a concept brief for a Hackney-based events promoter — no fixed venue, books warehouse rooms and industrial-conversion spaces across East London, runs gigs, electronic nights, jazz Sundays and the occasional festival day. Second revenue line is private hire: weddings, launches, brand parties where Foundry curates the music and production. The category problem: promoter sites are either flyer-energy noise that scares off private clients, or sterile booking forms that say nothing about the rooms. The brief: one tall page that sells the next ticket and takes a private-hire brief without either feeling secondary.
One page. Next show on top. A wedding enquiry should land in the same inbox without anyone changing tone.
The four specific calls that defined this build.
Most promoter sites bury the buy link behind a modal, a date page, or a third-party redirect that loses the visitor. Every Foundry Nights event card shows price, capacity-remaining state, and a sticky ticket button — no second click before purchase intent dies.
The usual move is a /private-hire microsite that breaks the brand and the analytics. Foundry runs it as one inline block between the public events list and the archive — same voice, same type, a different CTA. Couples planning a wedding see the live programming and trust it.
Old event pages on promoter sites are dead links to expired tickets. Foundry's archive is a tight visual grid — flyer, room, date, headline act — with no ticket CTAs. It's a credentials wall doing the work that an 'About' page usually fails at.
Promoter sites either skip the practical stuff (entry, age, sound, accessibility) or bury it in a collapsed accordion. Foundry's info block runs as one long, plain-language column — door time, last entry, ID policy, accessibility per-venue, ear-protection on sale at the door. The honesty about being loud and being late is a filter that improves the room.
What was ruled out, and why.
Standard for promoter sites is a Google Map pinning the warehouse. Skipped because Foundry doesn't have a fixed venue; pinning a different address per event would scatter the brand. Each event card states the room by name; directions live on the DICE ticket.
Promoter sites lean on a 3×3 IG embed to look active. Skipped — the cadence on Instagram is louder than the website should feel. A single linked handle in the footer is enough.
Most events brands ship a five-colour rave palette. Foundry holds the line at one accent — molten amber — on CTAs and event flags only. The restraint is what reads to a private-hire client as competence, not just nightlife.
Every tool chosen on purpose, with a reason that beat the obvious alternative.
Static for the marketing surface, ISR on the events list so a sold-out flag flips without a redeploy. Archive route reads from the same data.
Promoter updates the upcoming list from a phone the day a flyer drops. One schema covers public events and the archive — published date controls which list they appear in.
DICE handles registration, waitlists, and ID-tied tickets that prevent resale. Foundry keeps the brand surface and bounces to DICE only for the final checkout — no embedded iframe that looks like 2014.
Private-hire briefs drop into a Notion board the promoter triages weekly. Slack pings on anything tagged 'wedding > 200 guests' so the lead doesn't sit over a weekend.
Two letters a month — one programming, one private-hire case study. Plain-text aesthetic matches the editorial voice; Mailchimp would force a template fight every send.
Plausible covers the marketing-page side cookie-free; DICE referral params close the loop on which event card actually sold the ticket. Two dashboards, no GA.
The numbers a real engagement would be scored on.
What would change on day one of a real engagement.
Like this for your business?
