How the app is built
Why the Mridanga Seva app uses Expo, Supabase and PostgreSQL. The class has about 200 students, many of them children, and is run by volunteers with no budget. These choices follow from that.
Three ideas behind it
- One code base. The Android app, the web version for iPhones and the version for computers all come from the same code.
- Rules in the database. Who may see a child's record is decided by the database itself, so no screen or old version of the app can get round it.
- Nothing to pay in the first phase. Every service runs on a free plan. Paying later is a choice, not a rewrite.
What the app had to handle
- Children's data: dates of birth, parents' phone numbers, consent and attendance for students under 18. India's DPDP Act applies.
- Most members use iPhones: an App Store listing costs US$99 a year, which the first phase cannot spend.
- No budget and few volunteer maintainers: the code must be in common languages, with the rules written down in one place.
- Drop-in, not batches: students come any time in the open window, so attendance is a visit with check-in and check-out times.
- Three languages, more centres later: English, Telugu and Hindi now; other centres, possibly abroad, each with its own time zone.
The pieces
On your phone or computer: the app, built with Expo (React Native and TypeScript). Android users install it from a link; iPhone users add the web version to their home screen.
Behind it: one Supabase project, which is a PostgreSQL database with sign-in, file storage and scheduled jobs. Every read and write goes through the database's rules.
Outside services, each replaceable: Expo and Firebase deliver Android notifications, Brevo sends emails, lesson videos stay on YouTube, and Cloudflare Pages serves the web version and this website.
Compared with the usual alternatives
Each row is a way this app could have been built. The comments are about this class's situation, not about the technology in general.
| Option | Good for us | Problems for us |
|---|---|---|
| Expo + Supabase (what we use) | Free plans; one code base for Android, iPhone web and later an iOS app; access rules inside PostgreSQL; reports are plain SQL; the data is a standard PostgreSQL dump. | The rules need SQL skills; iPhone users get a web app for now. |
| Flutter + Firebase (our first draft) | One code base; popular. | For new projects, file storage and server functions need a paid plan with a card; reports are harder in a document database; data and rules are Firebase-specific. |
| Separate Android and iPhone apps | The best iPhone app. | Two code bases plus a server; needs a Mac and US$99 a year. |
| PHP or Node with MySQL | Common skills; fully our own. | Hosting costs money every month; MySQL cannot limit rows per user, so every rule lives in a server we must write, secure and patch; sign-in, files and notifications are all ours to build. |
| No-code (Google Sheets with AppSheet or Glide) | Quick to start; easy for non-programmers. | Children's data sits in a spreadsheet anyone with edit access can read or change; paid per user as the class grows. |
| Ready-made music-school software | Nothing to maintain. | A monthly fee; built for booked, paid lessons, not drop-in seva or Telugu and Hindi. |
| WhatsApp and Excel (how the class runs today) | Free; everyone already has it. | Every member sees every phone number; no consent record; no attendance history at 200 students. |
Why PostgreSQL and not MySQL?
Both are good databases. The deciding point is where the rules live.
- Row-level security: PostgreSQL itself can refuse a row to a user, so a student sees only their own record. MySQL cannot, so we would need our own server in between.
- Checks when a change is saved: "a child on record must have a parent's consent" is checked at the end of a change, even one made in several steps.
- Scheduled jobs inside the database: daily follow-ups and closing forgotten check-ins.
- A free service around it: Supabase adds sign-in, file storage and an interface for the app to PostgreSQL on a free plan.
Why Expo?
- One code base for the Android app, the web version and, when the budget allows, an iPhone app.
- Builds in the cloud, so nobody needs a Mac or a full Android setup.
- Updates without reinstalling: fixes reach installed phones in minutes.
- Ready parts for notifications, the camera for QR codes, sound for practice tools and location for check-in.
- Common skills: TypeScript and React are widely known.
What these choices cost us
- The free database pauses after 7 days without use. Daily class use keeps it awake, and Supabase sends a warning first.
- The free plan has no automatic backups. We take an encrypted backup every week and practise restoring it.
- The free plan holds 500 MB of data and 1 GB of files. Videos stay on YouTube; the paid plan (about US$25 a month) is the next step, with no code changes.
- We depend on the Expo and Supabase accounts. Both run on open, standard code, so a move elsewhere stays possible.
Short answers
Isn't a free plan risky?
The free plan has the same database rules as the paid one. The risks are a pause or lost data, and we handle them with weekly backups. Moving to the paid plan takes a day.
What if Supabase closes or changes its prices?
The data is ordinary PostgreSQL. A backup restores on any PostgreSQL host, and Supabase itself is open source and can run on our own server.
Why not just keep WhatsApp?
WhatsApp shows every parent's number to every member and keeps no attendance history. The app takes over the record-keeping; WhatsApp can stay for chat.
Prices and free-plan limits as of October 2026. The full reasoning, with a diagram, is in the project's source code.