Waktumu
2026 — A realtime rundown and event timer where the timekeeper changes the rundown and runs the clock, and every phone and stage screen follows live
01 Problem
At most events in Indonesia the rundown and the time live with one person. The rundown changes as the event runs. A speaker arrives late, a session is cut, or two segments swap, and the printout in everyone else’s hand is already wrong.
So everyone keeps asking around. The MC asks which segment they are in, the crew asks what comes next, the next speaker asks how long until their turn, and the committee asks who is on stage now.
The speaker on stage has it worst. They watch for hand signals from the front row and listen for someone calling from backstage, and their attention leaves the talk. Sessions run over, and the event ends late.
02 Solution
Waktumu turns the rundown into one live page that everyone reads. One person, the timekeeper, owns the rundown and runs the clock from a laptop. Everyone else only opens a link the timekeeper shares, with no sign-in and nothing to install.
The presenters see the time they have left on a screen in front of them, the Timer View. The crew, the committee, and the participants waiting their turn see the whole rundown on their phones, the Rundown View. Every change the timekeeper makes appears on every screen at once, so the schedule in everyone’s hand is always the current one, and nobody has to ask.
03 What the timekeeper sees
The rundown is a list of timers, each with a name, a duration, the people performing, and tags, made for how the event is run rather than copied from the program.
While the event runs, the timekeeper can insert a timer between two others, drag one to a new place, change a duration, or mark a segment finished or cancelled. Every start time after it shifts, and the header compares the estimated end with the target end as it happens. Every change saves itself, with nothing to resend.
From the same page the timekeeper starts, pauses, adds or removes time, and moves to the next timer, while a preview shows exactly what the stage sees.
Each finished timer keeps how long it actually ran, in green when it ended early and red when it ran over, and the whole rundown exports to CSV after the event.
04 What the crew and participants see
The Rundown View lists every timer with its start time. Finished ones dim, and the running one shows how much of it is left, so anyone can tell where the event is with a glance at their phone.
A speaker or contestant who only cares about their own turn picks their name from the performer list. Every timer they are not in fades, so their slots stand out in the full rundown and they can see how long until they are on.
05 What the presenters see
The Timer View fills the stage screen with one large countdown for the timer that is running, with its name and a progress bar along the bottom.
The countdown is green, turns yellow and then red at thresholds the timekeeper sets, and past zero it keeps counting below zero, so a speaker knows they are over and by how much without anyone waving from the front row.
06 Additional features
When a speaker needs to wrap up, skip a topic, or take one more question, the timekeeper types it and sends it. The message appears on the Timer View at once, below the countdown, or over it in full when it cannot be missed. The speaker reads it without the audience noticing, so nobody signals from the front row or calls from backstage.
Flash makes the stage screen blink to catch a speaker’s eye when a message is not enough. Blackout turns the screen black, for a break, a video, or a moment when the stage should show nothing, and the countdown keeps running underneath it.
07 Constraints
A Timer View link binds to the first device that opens it. That device signs in anonymously, and the server claims the link for it in a transaction, so a link forwarded to the wrong group chat cannot take over the stage.
The timekeeper sees every stage screen as Live or Disconnected, from its presence in the database, and can release a device or delete its link.
A Rundown View link is the opposite. Anyone can open it, as often as they like, and the timekeeper can turn it off or replace it. Viewers read the database directly, so a thousand of them add no load to the server.
08 Bad network connection defence
The server never sends the time left. It sends what the countdown was at a moment, whether it is running, and that moment, and every screen works out the rest from its own clock. So when the venue Wi-Fi drops, the stage screen keeps counting, because it needs nothing from the server to know the next second.
Counting on never hides the lost connection, on any side. The Timer View tells the speaker the connection is lost and the timer is still running. The Rundown View tells the crew it is disconnected and the rundown may not be current. The timekeeper sees each stage screen as Live or Disconnected, with how long ago it dropped, so they know which device to go and fix. When the timekeeper’s own laptop drops, the controls turn off until it reconnects, while every Timer View keeps counting.
Once the connection is back, each screen reads the latest state and jumps straight to where the timekeeper is, so anything that changed while it was away, a paused timer, added time, or a new segment, shows at once.
The moment is server time, and each device corrects its own clock with the offset Firebase reports, so a laptop whose clock is a minute off still shows the same second as the stage.
09 System design
The app is SvelteKit running on Bun. Firebase Realtime Database is both the source of truth and the realtime channel, and Firebase Auth signs timekeepers in with Google and identifies stage screens anonymously.
Every change to the rundown or the clock goes through a JSON endpoint on the server, which validates it and writes it with the Admin SDK, together with the small state each shared link reads. Clients never write the rundown. They only read, and the database pushes each write to every open view, guarded by security rules that ship with the app. The only thing a client writes is a stage screen’s own presence, which is how the timekeeper sees it as Live or Disconnected.
The server runs as a Docker image on Cloud Run in Singapore, next to the database, and scales to zero between events. It serves only page loads and commands, never the live updates, so the cost of an event does not grow with its audience.
A push to the dev branch deploys to dev.waktumu.com and a push to main deploys to waktumu.com, each in its own Google Cloud and Firebase project, with both domains on Cloudflare. GitHub Actions builds the image, stores it in Artifact Registry, deploys the database rules, and then rolls out the new revision, so the rules and the code that depends on them always ship together.
10 Pricing
Every feature is in every plan, including the free one. What a plan buys is more rundowns and more stage screens, meaning Timer View links per rundown, because remote control of the stage is the core and the number of screens grows with the size of the event.
The Rundown View is unlimited on every plan and always carries the Waktumu watermark, so every committee member who opens one sees the brand. The Timer View drops its watermark only on Bisnis, which organizations buy to show in front of clients and speakers.
Each step up doubles the price and roughly triples the screens, from one stage screen on Gratis to 30 on Bisnis at Rp399.000 per 30 days. The paid plans open once the payment gateway is in place.
11 Market
There is no local product. A search for an event timer in Indonesian finds generic countdown apps and do-it-yourself tutorials, so the market is open but has never been taught the category.
Abroad the category belongs to Stagetimer, and every core feature here already exists in it and its close copies, so features are no moat. At home the real competitor is free tools like Google Timer, countdown slides, and hand signals. What sets Waktumu apart is the language, a timer that survives the venue connection, and the price.
The market is counted in organizers, with each study program, company, or event organizer as one customer, valued at the plan it would buy. A study program would buy Plus for three months a year, and a large company or event organizer would buy Bisnis for six to eight months.
12 Funding
Waktumu is in Universitas Indonesia Incubate 2026, in its product-market fit track, as a team of three, with Ardian on technology, Chelsea on business, and Syarifah on marketing.
It asks for Rp98 million over six months, half of it for market validation by being present at events, recording what timekeepers say, and running a campus program that starts at UI. The goal is 50 real events and 10 paying organizations. The funding is still in process.
Waktumu
Live and free at waktumu.com, with paid plans waiting on a payment gateway