What shipped, month by month.

The venue side of Gelar is live, with Space by Kultura in Kemang as the first listed venue. Everything below is in production today.

A listing a venue writes itself. Photos, spaces, prices, house rules, amenities, FAQ, operating hours and booking rules — entered by the venue on a phone, published by the venue when its own checklist is complete. Listing and inbox are free, with no commission, ever.

A room you can see. The listing shows the room as drawn from the venue's own plan, with its dimensions, and up to three layout examples the venue arranged itself. Coba tata letak opens that room in the playground so an organizer can try their own layout before asking.

Ask, quote, book. An enquiry names the space, the dates and the hours. The venue answers with a quote; accepting it creates a booking with a deposit and a settlement date; every payment is by bank transfer with a bukti the venue verifies. The venue's calendar marks the dates as tentative or taken, and the public page shows only free / tentative / taken — never a name.

In two languages. The listing, the quote and the booking page render in Indonesian or English. The venue's own words — its description, prices and the terms a booking is made on — stay exactly as the venue wrote them.

For organizers, the door is open. Start free creates a workspace without a waiting list. Events up to 50 tables are free until 30 November 2026; above that, Gelar's per-table fee is invoiced once per event after it closes, paid by bank transfer. Nothing is charged automatically.

Who issues your invoices. An organizer can verify as a company (PT or CV) or as an individual. An individual's ID number is stored only as a one-way hash and is never printed; the ID photo is kept in a private store and deleted after 30 days.

Not in this release, by decision: online payment (a provider is not yet chosen), instant booking, reviews, and two-way calendar sync.

A pass over every public page, done in one day against a written review.

Measured before changed. Every call to action and the access form now report to our analytics, so the changes below can be judged in a month rather than argued about.

Six truth-fixes. Sentences that described features we had not shipped are gone. A page names a capability only once that capability is live.

One language per screen. English pages are English throughout; Bahasa pages are Bahasa throughout; the switcher says plainly when a page has no twin instead of pretending.

Pricing, shortened. The price is in the headline; the plan tiers are off the page until they can be bought. The calculator is unchanged.

Home, shortened. The three-column pitch, the bullet lists and the plan cards are out; what remains is what a visitor asked about.

The playground on a phone. The sandbox tells you before you enter what a phone can and cannot do there, and offers to send the link to a laptop.

Nothing here changes how any organizer's events run.

We are moving to a different payment provider. The previous integration has been removed from the product, the database and the site.

What this changes for you today: nothing about how money is collected. Online card and e-wallet payment was never switched on for any organizer — every event that has run on Gelar collected by bank transfer, with the tenant sending a bukti and the organizer verifying it in one click. That path is unchanged and remains the live one.

What we removed: the payment-link button, the provider's webhook, four columns on the invoice record, and every mention of the provider's name in our pricing, trust and privacy pages. A sub-processor list should name the company that actually handles your data, so ours now names none — because none currently does.

What we kept: the escrow model itself, the invoice numbering, and the protection that a payment record outlives the invoice that requested it. Those belong to Gelar, not to a vendor, and the next provider inherits them.

What is next: online payment returns when a provider is chosen and integrated. We will name it here, and in the privacy and trust pages, before it processes a single rupiah.

The pricing page now opens with a calculator. Set the number of tables in your floor plan, how many you expect to sell, and how many events you run a quarter — it answers with the per-event fee, the per-table total, and the pay-as-you-go cost per event and per quarter.

It also does the comparison maths for you. When a subscription would be cheaper at your volume, it says so and names the tier — and it shows what the same event would cost on a percentage-of-revenue fee at 3.5% and 5%, because that's how most alternatives price and we think you should see that number next to ours.

Your estimate is a link. The inputs travel in the URL, so you can send a computed estimate to a colleague and they'll see exactly what you configured.

One source of truth for every number. The calculator, the band table and the plan cards on the pricing page all read from the same constants module our billing code uses — the public page can't drift from what we actually charge.

Until now /venues was a catalogue you could read. Now it's a place where a conversation starts: an organizer sends a structured enquiry from a venue page, and it lands in that venue's inbox as a pipeline card.

For organizers: a Send enquiry form on any public venue page — event type, dates, headcount or booth count, budget, contact and message. No account needed.

For venue operators: an inbox at your venue with a pipeline board — new, contacted, quoted, deposit, confirmed — and a thread view per enquiry showing the structured ask, the message history, a reply box and a WhatsApp hand-off when the conversation should move there. Venue-kind orgs now land on their inbox at sign-in instead of an events index that was never theirs.

Enquiries to unclaimed venues aren't lost. They're held against the listing, and when someone claims that venue the held enquiries are released into their new inbox. Claiming a listing comes with a pipeline already in it.

Abuse controls, because this is a public write path: honeypot field, 5 enquiries per contact per hour, 40 per venue per hour.

On the security work, since a marketplace means untrusted input reaching a real inbox: enquiry loaders live in a query module, not in the server-actions file — action exports are public RPC endpoints, and a loader that relies on its caller for auth is a loader with no auth. Row-level security covers reads (owning venue-org members, the enquirer, platform staff), inserts (anyone, including anonymous, on a public venue) and updates (venue-org members and staff), with cross-org isolation coverage in the regression suite.

Next on the venue side: more real listings with real photos. The catalogue is the part of this that's still thin, and it's the part we're working on.

The first release built from watching a real team use Gelar under pressure rather than from a spec. Almost everything here came from someone saying "I can't see that" or "that number is wrong".

The floor plan you can actually read:

• Empty booths are visible. They were transparent with a sub-pixel stroke — effectively invisible at working zoom. Now they carry a soft fill, and every stroke renders at device pixels so selection and drop rings hold up at any scale.
• Unassigned booths tint by tier, and booth codes are sized to the booth so B15 and G1 are legible without zooming. A tier legend sits beside the funnel-stage legend.
• The venue underlay renders behind the booths, at the same scale and offset as the layout editor — so what you plotted is where it sits.
• Walls and decorations from the published layout — labels, cafe tables, chairs, doors — now render read-only in Operations. The plan looks like the room.
• A held booth says who holds it. It used to read "Available", which is how a booth gets sold twice.

More room to work: the header and KPI strip are slimmer, and both side rails collapse to a 40px strip — up to ~600px more floor plan. Selecting a booth auto-expands the detail rail.

Tenant records that match how teams actually file things: tenant category (free text — "TCG", "Sports Card" — distinct from the Bronze/Silver/Gold booth tier) and social handle, both end-to-end through the CSV importer, All Leads filters and the detail rail. A bare @handle opens Instagram; a full URL opens as-is.

One honesty fix worth naming: the "DP collected" KPI showed a hardcoded "↗ +3 in last 7 days" — a prototype leftover that read +3 even when the number was zero. It now says what's true: "no payments yet", or the real count.

Also: money formats consistently in the app UI (Rp 4,000,000), while WhatsApp templates deliberately keep Indonesian formatting because those messages go to tenants. Daily automated backups of the operations snapshot to private storage.

THE MARKET Vol 3 (FanCon, 4–5 July 2026, MGP Space SCBD Park) was operated end-to-end on Gelar. No parallel spreadsheet, no fallback to the old process mid-event.

That is the only release note that matters this year. Everything before this was a claim; this is the evidence.

What that actually meant in practice:

• The pipeline lived in one place. Sales moved leads through the funnel, producers plotted and re-plotted the floor, and finance reconciled — all against the same data, at the same time, from different devices.
• Booth status was derived, never typed. Status came from the assignment plus the lead's stage, so the plan and the pipeline could not disagree with each other. Nobody had to remember to update a second thing.
• Money reconciled from payments. Escrow settlements and verified bukti transfers both fed the finance view directly, which is why the numbers held up during the event rather than after it.
• It survived a real day-of. The tablet on the floor, the laptop in the back office and the phone in someone's hand all showed the same plan, updating live.

What we learned is going into the product, not into a slide: onsite rebooking for the next volume is being built for Vol 4 in December, and the revenue-forecast card came straight from watching how the team actually read the finance view under pressure.

A full case study — the before-and-after, the numbers, and what the operating team says about it — is being written up with the team. We'd rather publish it with their words and their figures than ship a marketing page the week after the event.

Next up: a request-access form that isn't an email link, a pricing calculator that shows the arithmetic, and a public demo you can touch without talking to anyone. The product is ahead of the way we've been explaining it — that's the gap we're closing now.

The first public surface of the venue marketplace: a browsable catalogue of Indonesian event spaces at /venues, with a detail page per listing.

What's live:

• Filterable catalogue. Filter by city, venue type and indoor/outdoor. The filter architecture is built for a catalogue in the hundreds, not the handful currently in it.
• Listing pages. Capacity, type, location and description per venue, at a stable public URL.
• Schema first. Venues, venue members and the claim path exist in the database with row-level security from the start — so owner claiming and the earned-response badge can land later without a migration scramble.

Being straight about the state of it: there are two real listings today, and the photo pipeline isn't built. A researched dataset of 108 Indonesian venues exists but was authored against an older schema and needs re-keying before import. Until listings carry real photos and the catalogue is worth browsing, this stays an early preview rather than something we point people at.

Next: re-key and import the 108-venue dataset, settle the photo sourcing policy (owner-supplied, staff-shot or licensed — never scraped), and publish at least 20 listings that meet the photo bar. Owner claiming and the "Responsif" badge come after that.

Superseded on 31 August 2026 — this integration was removed. Gelar is moving to a different payment provider, not yet chosen. Online payment is not currently available; the live path is bank transfer with bukti upload and one-click verification. This entry is kept because it records what shipped on the day, which is what a changelog is for.

Tenants can pay online. Money moves through Xendit escrow, the platform fee is skimmed at source, and finance reconciles from actual payments instead of from where a lead sits in the funnel.

What's live:

• Escrow checkout. Invoice a lead, send the payment link over WhatsApp, tenant pays by VA, QRIS, e-wallet or card. Funds land in escrow, not in anyone's personal account.
• Skim-at-source fee. The per-table fee comes off at settlement, so there is no separate Gelar invoice to chase and no month-end reconciliation exercise.
• Custody stays with Xendit. Gelar never holds tenant money. This is a deliberate constraint, not a limitation we plan to remove.
• Bukti transfer as a first-class fallback. Manual transfers still work exactly as before — upload proof, ops verifies, booth status flips. Online payment is an addition, not a replacement.
• Finance derives from payments. Revenue collected, cash position and the zone breakdown all read from the payments table. A lead marked "lunas" with no payment against it no longer inflates the numbers.

Under the hood: webhook handlers are idempotent at the database level, callback tokens are compared in constant time, and every settlement writes an audit-log row. Invoice numbers are allocated by an atomic sequence per org, so two people clicking "invoice" at the same moment cannot collide.

Not yet: refunds and cancellations are handled manually with finance in the loop. The self-serve refund flow, the payout SLA timer and downloadable receipt PDFs are all scheduled work.

Until now, floor plans were a fixed fixture traced from a deck: fine for one event, useless for the next one. The layout editor makes plotting a first-class thing you do in Gelar.

What's live:

• Draw, drag, resize, snap. Place booths on a multi-floor SVG canvas with corner-resize and a snap toggle. Centimetre-accurate — the plan is a working document, not an illustration.
• Zones. Assign booths to zones, including custom zones with their own colours, and they round-trip through save and publish intact.
• Click-to-sequence numbering. Click booths in order to renumber a run. The renumber is two-phase and atomic, so a half-applied sequence can't leave duplicate codes behind.
• Templates. Save a floor as a template and start the next event from it instead of from an empty canvas.
• Publish to Operations. Publishing pushes geometry into the live event. Booths keep a stable internal identity across renames and renumbers, so renumbering a booth never orphans the tenant assigned to it — the failure mode that would have quietly destroyed a sales pipeline.
• Undo/redo, and an unsaved-changes guard so closing the tab can't discard an afternoon's plotting.
• Optimistic locking on publish. Two producers editing the same floor no longer silently overwrite each other; the second save is refused with a conflict message rather than winning by accident.

Deliberately not yet: measure/scale-calibration, background trace import, align-and-distribute with smart guides, version snapshots and full iPad touch mode. Those are specified and scheduled — the editor's next release is an interaction and shell redesign, not a new engine.

First production release of Gelar — a multi-user web app with magic-link auth, Postgres + row-level security, and Supabase Realtime, replacing the single-user React+Babel prototype.

What's live:

• Lead pool + funnel. Six pipeline stages (prospect → contacted → invoiced → DP → lunas → activated). Drag a lead onto any booth in a multi-floor SVG plan to assign it.
• Right rail. State-driven detail panel for the selected booth or lead. Inline WhatsApp deep-links with five Bahasa Indonesia message templates pre-filled with tenant name, amount, and due date.
• Finance view. Revenue card, cash position, zone-by-zone breakdown. Replaces manual reconciliation.
• Bukti upload + verify. Tenants upload payment proof via a per-lead WhatsApp link; ops verifies in one click and the booth status flips automatically.
• Magic-link auth. Sign in with email — no passwords. Per-org membership with role-based scoping.
• Realtime. Booth-status changes propagate across every viewer instantly.

Foundational choices baked in from day one:

• Multi-org Postgres schema with row-level security — multi-tenancy is a constraint, not a feature added later.
• Idempotent xlsx importer for orgs migrating off spreadsheets.
• Migrations versioned in-repo; audit log per status change.
• Hosted in ap-southeast-1 (Singapore) for low-latency access from Indonesia.

Next: layout editor for plotting new events, venue marketplace, and onboarding more organizers from the waitlist.