I built a Flutter app to fix the #1 source of trust issues in a housing society
It's a full mobile app for Indian residential societies, covering dues, payments and expenses, and I built the whole thing myself in about a month.
12
Database Tables
44
Supabase RPCs
3
User Roles
30–35
Days Solo Build
Chapter 01
The Same Argument, Every Month
Most societies are still run on WhatsApp groups and Excel sheets. Nobody's a bad person here. They just don't have a system, so the same fight happens every month.
Payment proofs lost in WhatsApp
Everyone dumps their payment screenshot into one giant group chat. Good luck finding the right one when someone swears they already paid.
Monthly disputes between neighbours
"Mera toh paid hai!" Every admin has heard that a hundred times, and usually has no real way to check.
Zero expense transparency
Nobody can see where the maintenance money actually goes, so every meeting turns into a guessing game.
It was never really about bad people. It was that nobody had the same information. Once everyone can see the same thing, there's nothing left to argue about.
Chapter 02
How the App Actually Works
Here's the whole flow, start to finish, from the admin setting things up to a member proving they paid.
Admin sets it up once
Set the maintenance amount and due dates once, and the app generates a full year of dues for every flat automatically. You're not doing this every single month.
Members pay and upload proof
People still pay however they normally do (UPI, bank transfer, whatever). They just snap the screenshot and upload it. Takes about 30 seconds.
Admin approves with one tap
One tap to approve or reject, and the member gets notified right away. That record is permanent, so nobody has to dig through chat history to prove they paid.
Everyone sees the same truth
Admin and members see the exact same numbers: dues, payments, expenses. Once everyone's on the same page, there's nothing left to dispute.
Chapter 03
How It Was Built
The short version. I'll spare you the deep technical dive.
I broke it into six phases: figure out the real problem, design the database, write the backend logic, then build the actual app in Flutter. Every step got planned and reviewed before I touched any code.
SUGGESTED
Two new tables for multi-month payments
CHALLENGED
Could one column do the same job?
SHIPPED
Turned out yes. One column, way simpler.
That's how I used AI on this whole project. It suggests, I push back when something feels off, and I decide. I understood every RPC and every schema choice before it went live.
Built with
Chapter 04
What I Actually Learned in 30 Days
I built this solo in about a month. Here's what actually mattered, and it wasn't the feature list.
12
Database Tables
All with RLS enabled
44
PostgreSQL RPCs
Zero raw queries in Flutter
3
User Roles
Super admin, admin, member/tenant
30–35
Days Solo Build
Idea to production-ready
Plan first. Build second. Always.
I described every feature and got it reviewed before writing a single line of code. Honestly, that's where most of the good decisions actually happened.
AI-augmented development is a skill, not a shortcut
Claude wasn't on autopilot. It kept questioning my assumptions, which was more useful. Knowing when to push back on its suggestions was the real skill.
Real requirements never arrive all at once
Tenants, multi-society support and penalty settings were not in my original plan. New stuff kept showing up, and it worked out because I'd built the architecture to grow, not just to work.
Building a women's health app?
Let's talk.
I'm a Flutter developer in Ahmedabad, India, with 5 years of experience. I now focus on women's health apps that keep patient data private. I'm open to new projects.
Related reading: How to improve user engagement in a health tech app