A tech meetup website that outlasts any one event
Event platforms are good at one thing: the next event. A recurring meetup needs more than that: a record of past talks so speakers and sponsors can see what you do, a way to propose a talk, and somewhere to thank sponsors. A small site with the next date at the top, a talk archive and a proposal form covers it.
Why a meetup needs its own site
Most groups start on a listings platform or a Discord server, and that's fine for RSVPs. The trouble starts when the group outgrows the platform's page: talks disappear into old event listings, slides live in someone's drive, and a potential sponsor asks for "something to send to marketing". A tech meetup website at your own address gives the group a memory and a front door that doesn't change when the organisers do.
What the home page should say
- The next event first: date, start time, venue with step-free access details, the talks if known, and a link to wherever people RSVP.
- Who it's for in one line: "Rust developers in Leeds, beginners welcome" does more than a paragraph about community.
- How often you meet: "second Thursday, every month except August" lets people plan.
- A code of conduct link. Speakers and sponsors look for one, and it tells attendees how to report a problem.
- How to get involved: speak, host, sponsor or help organise.
Past talks as a collection
An archive of talks is what makes a developer meetup page useful months later. Keep it in a CMS collection, one entry per talk, with fields for the title, speaker, date, a short abstract and links to the slides and recording. Each talk gets its own page at its own address, and the collection page lists them all. Entries are edited in the dashboard, so any organiser can add last night's talks without touching the design.
Recordings can't be embedded on published Anticode pages, because the pages block outside frames. Link to the video on YouTube or wherever it's hosted. Write a proper abstract for each talk rather than pasting the title alone: those few sentences are what people find when they search for the topic later.
A talk proposal form you can triage
A call for talks needs more than a contact form's name, email and message. Ask for the talk title, a short abstract, length (lightning or full), experience level, whether it's the speaker's first talk, and preferred months. On Anticode that's a custom form tied to a site function, with up to 30 plain-text fields, and the thank-you page can tell the speaker what happens next. Speakers can't attach slides; ask for a link instead.
| Destination | Good for |
|---|---|
| Airtable or Google Sheets | A shortlist with columns for status, month and who's talking to the speaker |
| Notion | Groups that already plan events in a shared Notion workspace |
| Slack or Discord | Organisers seeing each proposal as it arrives and reacting to it |
| Small groups with one organiser; every submission can be emailed to you |
Connectors send each submission once, without retries, but every proposal is also saved in your dashboard, so nothing is lost if the destination is briefly down. The call for speakers page guide goes deeper on wording a call for talks.
A sponsors section that sponsors will read
Sponsors of a user group usually provide a venue, food or a small budget. Say what you offer in return in plain terms: a logo on the site and slides, a two-minute slot at the start, a job post in the chat. Give honest numbers you can back up, such as typical attendance, and add a sponsorship enquiry form. Thank past hosts by name with a link; that's often what persuades the next one. The sponsorship page covers tiers in more detail.
Building it
Describe the group: "a website for a monthly Python meetup in Bristol, next event 12 November, with past talks, a talk proposal form and a sponsors section". The Architect may ask whether you want separate pages, and shows the plan first. The Technical design system (IBM Plex Sans) suits most tech groups; Swiss or Brutalist if your branding is bolder. Organisers can edit text in place, and recent saves are kept in version history, so a hurried update before an event can be rolled back.
Limits worth knowing
- No RSVPs with attendee lists or waitlists. Keep using your event platform for that and link to it.
- No member logins or member-only pages; everything published is public.
- No embedded recordings, maps or chat widgets. Link out instead.
- No automatic reminders to attendees. A newsletter form sending sign-ups to Mailchimp or Kit lets you email them yourself.
Questions people ask
Can several organisers update the site?
Yes, in a Team workspace with members. Members can edit, but can't delete projects or take sites down.
Can the site show the next event automatically?
Not on a timer. Update the date when you announce the next event; it takes a minute in the visual editor.
Do we need our own domain?
No. A free anticode.dev address works. A domain such as leedsrust.dev is available on paid plans and survives any future change of platform.