Pulen is a take-a-number app for a roti mochi bakery in Bandung. The bakery is fictional, the problem is real: the line starts at 6:40, people wait 45 minutes, and the cheese one sells out before nine.

You fill a box from home and pay, and your number only exists once the card clears, so nobody can hold buns with a fake order. Your paper ticket follows the oven and tells you when to start walking. In the kitchen, every tray of 36 is planned from paid boxes first. Unpaid holds, missed boxes, sold-out flavours and the owner's closing summary with an AI suggestion all run on their own.

If Bandung is asleep when you visit, press "Play the morning" to watch a whole morning in 70 seconds. To try ordering, use the Stripe test card 4242 4242 4242 4242.

Built in Base44 from 12 plain-English prompts.

I'd test the last cheese bun with two payments completing at once. Does Pulen reserve stock during checkout and release it on expiry, or allocate only after payment with a refund path if that flavour has sold out?

A booking platform is more than a calendar. I worked on Duna, a Pilates scheduling platform with an integrated payment gateway.

What interests me about projects like this is the connection between the software and the actual business workflow: how people book, how payments fit into that process, and how the experience works for both customers and the team.

It’s the kind of development I enjoy—turning an operational need into a usable web product.

I’m open to projects involving booking systems, API integrations, and custom business applications.

The tricky part is keeping a class spot reserved while payment is still pending, then releasing it cleanly if checkout expires. Did you use a temporary booking hold for that?