Madhav Sharma
Side
BuildOperate
Type
Client system
For
BabyBrain
My role
Built the platform; sole engineer for its first ten weeks
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

  • Next.js
  • Vite
  • Supabase
  • Postgres
  • Stripe Connect
  • GetStream
  • OpenAI API
  • Resend
babybrainSingapore
  1. parents book classes
  2. 66vendor listings imported
Schematic of the marketplace: parents book, the booking reaches a vendor, and the platform pays the vendor out. The 66 squares are the vendor listings the import pipeline created.

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.

More work on the same problems