How to Organise a Developer Meetup in an Indonesian City

The first meetup I helped run had chairs in neat rows, a projector that worked, and food counted per head off the sign-up list. What it did not have was the people. The back third of the room stayed empty all evening, and a stack of boxes went home with us.

This post is the operational detail nobody writes down: how to get a room, why the sign-up number is fiction, which channel actually delivers a reminder in Indonesia, and how to choose talks that earn a second event. It is written for a city outside the Jakarta bubble — Bandung, Surabaya, Yogyakarta, Medan, Makassar — where the constraints differ and the room is harder to find. If you would rather not start from nothing, a Google Developer Group chapter already has a platform, a brand and a calendar; the rest of this is for when there is none, or when you want one that is yours.

The venue decides the event, and the free room is rarely the cheap one

Three kinds of organisation in an Indonesian city actually have a room with chairs, a projector and a plug: a campus, a coworking space, and a company with an engineer inside it willing to ask. Everything else — a cafe, a friend's office lobby, the back room of a restaurant — seats twenty people badly and costs you the evening in noise. Decide which of the three you are asking before you write to anybody, because each wants a completely different thing in return.

• A campus wants the event to belong to it. Expect a student chapter as co-host, a lecturer's name on the poster, and sometimes a formal letter to the faculty. The room is free and the paperwork is not.
• A coworking space wants marketing. Photographs, a tag on Instagram, your attendees seeing the desks they might rent. You either pay a modest room fee or trade it for that visibility, and the trade is usually stated plainly.
• A company wants hiring reach. One engineer sponsors you internally and their goodwill is the entire booking, so if that person changes team or goes on leave, your venue quietly disappears two weeks before the event.

The pattern is that the free room costs the most coordination. A campus booking can take weeks of approvals and still arrive with a hard lock-up hour set by somebody you never meet. A coworking space answers in a day and keeps the door open until closing. If you have any budget at all, spend it here first — paying for a room is the cheapest coordination you will ever buy.

RSVPs lie, and the only useful number is your own

Every sign-up list overstates the room. That is true everywhere, but the size of the gap is local: it moves with the day of the week, the rain, the distance from campus, whether the event is free, and whether your reminder reached a phone the attendee actually reads. Do not take a no-show percentage from an American meetup blog and cater to it. The number is not transferable, and using it either wastes food or embarrasses you in front of a sponsor.

Measure instead. Record two figures per event — how many said yes, and how many walked in — and you will have a rough ratio by your third event and a usable one by your sixth. Cater to the measured ratio, never to the sign-up count. One event's number on its own is noise: a long weekend, a national holiday or an afternoon of rain moves it more than anything you did.

// Day-before confirmation. Posted ONCE in the announcement group, at 19.00,
// because that is when a phone in Indonesia is being read rather than charged.
// One question, one-word reply, no link. Anything longer gets scrolled past.

Halo semua! Meetup besok, Sabtu, 13.00 - 16.30, Ruang Seminar Lt. 3.
Balas IKUT kalau jadi datang, SKIP kalau berhalangan.
Konsumsi dipesan besok jam 09.00, jadi jawaban sebelum itu sangat membantu.

// The whole measurement system. Two columns, one row per event.
// Resist building a dashboard for this; a note on your phone is enough.
//
//   event   signed_up   confirmed_day_before   walked_in
//   ------  ----------  ---------------------  ---------
//   #1      ?           ?                      ?
//   #2      ?           ?                      ?
//   #3      ?           ?                      ?
//
// show_up_rate = walked_in / signed_up          <- what you cater to
// confirm_rate = walked_in / confirmed_day_before
//
// Do not average across cities, venues or weekdays. A Saturday afternoon on
// campus and a Wednesday evening downtown are two different populations.

Three mechanics move the ratio, in increasing order of effect. A confirmation message about twenty hours out, which turns a three-week-old yes into a fresh one. A small commitment — choose a session, bring a laptop, claim a seat number — because a person who has already done something is far more likely to appear. And any barrier at all: a token fee, a two-question form, a named seat. A free event with one-tap sign-up is the easiest to promote and the hardest to forecast, and you should know which of those two problems you are choosing.

Why the WhatsApp group beats the event platform here

Put the community where people already are. We Are Social's Digital 2026 summary for Indonesia calls WhatsApp the most frequently used and most loved app in the country, with nine in ten Indonesians active on it each month. An event platform's push notification competes with every other notification a person has already muted. A WhatsApp message lands in the same list as their family and their team, which is why it gets read within the hour.

Keep the platform listing anyway. It is discoverable, it survives a search months later, and it gives a first-time attendee something to look at that is not a request to join a group of strangers. Treat the listing as the front door and the group as the building. WhatsApp Communities are shaped for exactly this: an announcement group that reaches everyone at once, plus topic groups where conversation continues between events. The announcement group is what makes a reminder land. The topic groups are what stop the community dying during the eleven months a year you are not running an event.

One deep talk beats three shallow ones

A meetup that fills ninety minutes with three twenty-minute overviews teaches nothing anybody could not have read on the way there. One speaker going properly deep on a problem they actually hit — the migration that failed, the queue that backed up, the printer that would not cut paper — leaves the room with something to argue about. An argument in the corridor afterwards is the best predictor I know of who comes back next time.

1. Ask for the problem, not the topic. A proposal that says GraphQL is a lecture. One that says our GraphQL layer hid an N+1 query for a month and here is how we found it is a talk.
2. Run a rehearsal, not a pep talk. Sit the first-time speaker in front of two people a week early and make them run the whole thing, demo included. Encouragement never finds the slide that makes no sense.
3. Rehearse the demo failing, too. Decide in advance what happens when the wifi drops: a recorded terminal session, a local fallback, or one clean sentence that moves on without apologising for four minutes.
4. Cut the introduction. Most first talks spend ten minutes on background the audience already has. Start at the problem and let the background arrive when it is needed.

A live demo that fails in front of the room still beats slides that cannot fail, because the recovery is the part people remember and the part they learn from. What is not acceptable is a demo nobody tried on the venue's network. Test the projector, the resolution and the wifi with the speaker's own laptop, in the actual room, before anybody arrives — a guest network behind a captive portal will not authenticate while a laptop is mirroring to a projector, and you will discover that at 13.05 with forty people watching.

The language decision is a real decision

Three options, and each one changes who is in the room and who volunteers to speak. All-Indonesian is the most welcoming and by far the most likely to get a nervous first-timer to submit, but it removes the talk from any recording an international audience would watch. All-English raises the perceived bar so high that in most cities outside Jakarta you get the same four confident speakers every time. Slides in English with the talk delivered in Indonesian is the option I would choose: the terms stay in the language the documentation is written in, and the speaker explains them in the language they think in.

Whichever you pick, say it out loud in the announcement, because the ambiguity is what actually puts people off. A speaker who does not know whether English is expected will simply not submit. State it as a rule — slides in English, speak in whichever language you are more fluent in, questions in either — and proposals arrive from people who would otherwise have stayed quiet.

What a sponsor is actually buying

A sponsor is not doing you a favour, and treating the conversation as charity is why most sponsorship requests go nowhere. A company sponsors a developer meetup for two reasons: hiring reach, meaning a room of engineers who now recognise the name, and product awareness, if they sell something developers choose. Write the offer in those terms and it becomes a transaction both sides can evaluate in one email.

Food is the highest-leverage thing you can spend money on, and it is the first line to fund. It is the reason people stay after the last talk, and staying after the last talk is where the community actually forms. A sponsor whose only contribution is catering gets a genuinely good deal, because their name attaches to the part of the evening people enjoyed. Ask for that specifically rather than an unnamed amount — cover the food is a request a middle manager can approve without opening a procurement process.

Be careful with the sponsor who offers their office, though. That is a venue, a discount and an obligation arriving together: their security desk decides who gets in, their building decides when you leave, and their reorganisation can cancel your event without anybody meaning to. Take it, but keep a second room in mind and never announce a date before the room is confirmed in writing.

The unglamorous list that decides whether it works

Everything remaining is scheduling and physics. None of it is interesting, and all of it is what people remember afterwards.

• Timing. An evening event in a large Indonesian city has to survive the commute. Start too early and you lose everyone who cannot leave the office; start too late and you run into the venue's lock-up. Pick the start time after you know the lock-up hour, not before.
• Prayer times. Asar for an afternoon event, Maghrib for an evening one. Both move through the year and differ between cities, so look up the schedule for your city and your date on the Ministry of Religious Affairs' Bimas Islam site instead of reusing last month's plan. Build the break around it and confirm the prayer room is unlocked.
• Power and network. Count the sockets before you count the chairs. A room with two working outlets cannot host a workshop, and a guest network behind a captive portal defeats more demos than a slow connection ever will.
• The lock-up hour. Every venue has one and it is enforced by a person whose shift ends. Get it in writing, tell the speakers, and build the schedule backwards from it rather than forwards from the start time.
• Cleanup. Name the person responsible for the room being empty and tidy, out loud, before the event begins. It is the single thing that decides whether you are welcome back.

RUN SHEET - Meetup #4, Saturday
Venue contact: Pak Yudi, security desk, ground floor - number held by Dewi
HARD LOCK-UP 17.30. Every line below is built backwards from that one.

12.30  Doors. Projector, resolution and wifi tested on BOTH laptops    Dewi
12.55  Registration table, name tags out, sponsor banner up            Rian
13.05  Welcome, 3 min: wifi password, toilets, prayer room, exits      you
13.10  Talk 1, 35 min + 10 min questions                               speaker A
13.55  Break, food out. Prayer room unlocked and pointed at            Rian
14.30  Talk 2, 35 min + 10 min questions                               speaker B
15.15  Break for Asar - look up TODAY's time, not last month's         Rian
15.45  Open floor and lightning demos. Hard stop 16.15                 you
16.15  Group photo, sponsor banner in frame                            Dewi
16.30  Chairs back, rubbish out, projector returned                    everyone
17.00  Room empty, keys handed back                                    you

# One name per line. A line with no name is a line nobody does.
# The 15.15 break moves with the prayer schedule, so check the date, not the month.
# The 17.00 line is not optional: the person who locks up has a shift that ends.

Write all of that as an actual run sheet with one name against each line, and share it with the venue contact and the speakers the day before. Two things it must contain that most run sheets omit: who is holding the venue contact's phone number, and the time you are physically out of the building.

The rule I would hand anyone starting: fix the room and the lock-up hour first, then design the evening backwards from them. Talks, sponsorship, language and reminders are all easier to arrange than a room, and none of them matter if the room is uncertain. Then measure your own numbers from the very first event, because a borrowed no-show rate only tells you about somebody else's city.