- Side
- BuildOperate
- Type
- Client system
- For
- BabyBrain
- When
- Jun 2026 to present
- Status
- In progress
BabyBrain
A two-sided marketplace for children's classes in Singapore, built from the first commit. Parents find and book, vendors manage listings, chat and payouts, and an LLM pipeline turns vendor websites into listings.
- audit findings closed, each checked against the running database
- 21 of 21
- Checked against the data
- vendor listings created by the import pipeline
- 66
- Checked against the data
- as the only engineer, from the first commit
- 10 weeks
- Checked against the data
Stack
- parents book classes
- 66vendor listings imported
BabyBrain connects parents in Singapore with children’s activities and classes. It is two products on one platform: a parent app for discovering, booking and paying, and a vendor portal for listings, schedules, chat and payouts.
I wrote the first commit in June 2026 and was the only engineer until a second one joined in late August. Everything below was built in that window or since.
The platform
Both apps are single-page front ends served from one deployment, with a shared API underneath and Supabase Postgres as the system of record. Row-level security decides who can see and change what, so a vendor can only ever touch their own classes and a parent only their own bookings.
Money moves in both directions
Payments were the hardest part, because a two-sided marketplace has to collect from one side and pay the other.
- Bookings through Stripe, including class packages that are paid once and redeemed as credits, and make-up tokens for missed sessions.
- A paid membership for parents.
- Vendor payouts through Stripe Connect, with each vendor’s commercial terms recorded and auditable.
- Live and test modes side by side, with configuration scoped per mode so a test payment can never touch live money.
- Idempotent webhooks, so a payment event delivered twice can never grant a package twice.
Listings from the open web
A marketplace with no vendors has no parents. To seed it, I built a pipeline that crawls vendor websites, uses an LLM to extract the structured details a listing needs, geocodes the address, and creates claimable listings that vendors can take over. It created 66 listings, and a weekly scheduled job keeps them fresh.
Chat runs on GetStream: a vendor inbox, enquiries from parents, and a group chat for each class slot that only booked parents can join.
An audit that was verified, not trusted
In September I ran a full read-only audit of the codebase: the back end, both front ends, every database migration, the admin panel and the integrations. It found 21 issues, seven of them critical. Among them were a security policy that trusted an ID sent by the client, a booking that could be confirmed before an asynchronous payment had actually cleared, and a race that could sell the last seat in a class twice.
All 21 were fixed: IDs derived on the server, payment status checked before confirming, and row locks where two people could reach for the same seat. Each fix was checked against the code and the running database, not against the commit message that claimed it.