School management SaaS MVP: fees, attendance and a parent app

The situation

Picture a founder who spent ten years selling to schools and wants to build software for them. The target is mid-sized private schools in Tier 2 and Tier 3 cities: 500 to 2,000 students, a small office team, and no appetite for a complicated ERP.

The founder has spoken to dozens of principals and accountants, and the same two problems come up every time. Collecting fees means counter queues, cheques, cash and handwritten receipts, followed by hours of matching payments against bank statements. Keeping parents informed means WhatsApp groups that are noisy, unofficial and hard to control. Larger school ERPs exist, but these schools find them expensive and heavy, and use a fraction of what they pay for.

The founder doesn't need a full ERP in version one. They need a product that solves those two problems well enough that the first ten schools will pay for it, on a foundation that can grow to hundreds of schools without a rewrite.

Signs this blueprint fits you

• You know your customers' problems first-hand and have early schools willing to pilot.
• You want to reach paying customers in months, not a year.
• You need a multi-tenant product, not a custom system for one school.
• You have a budget for an MVP and want to keep options open for funding later.

What we'd build

• A multi-tenant platform where each school is a tenant with its own data, users, branding and settings, all running on one codebase.
• Fees: fee structures by class, discounts and concessions, schedules, reminders, online payment with settlement to the school's account, receipts and collection reports.
• Attendance that teachers mark from a phone in under a minute, with absence alerts to parents.
• Notices and messages to a class, section or the whole school, replacing unofficial WhatsApp groups.
• A parent app (Flutter) for fees, attendance, notices and homework, with one login for parents with several children.
• Onboarding and billing for schools: import students from Excel, set up classes, and subscribe the school to your plan.

How the pieces fit

Multi-tenant from day one

Every table carries a school ID, and every request is scoped to the user's school. We use PostgreSQL row-level security as a second line of defence, so a bug in application code can't show one school's data to another. This is cheap to build at the start and very expensive to add later.

Fees that reconcile themselves

Payments go through a gateway with split settlement, so money goes straight to the school's account and your platform fee is deducted automatically if your model needs it. Each payment is matched to a student and fee item, receipts are generated in the school's format, and the settlement report is reconciled daily.

Only what the first schools need

The MVP deliberately leaves out exams, timetables, transport, library and payroll. These are real needs, but every one of them delays the first sale. The roadmap after launch is driven by what paying schools ask for most.

Built to sell

Self-serve onboarding, Excel import and simple subscription billing for schools are part of the MVP, because a product that needs your engineers to set up every school won't scale past the first few.

One fee cycle, end to end

Here is a term-fee cycle for one class, from setting the fee to the accountant seeing reconciled collections.

What the school and parents would see

The school office sees collections by class and who is overdue, and can remind them in one tap. Parents see what's due, attendance and notices in one place, and pay without visiting the school.

Scope of the MVP

Technology

Delivery plan

Three schools act as design partners from the first week: their office staff review designs, test early builds and go live first. Once they're running smoothly, onboarding becomes self-serve and the founder's sales effort moves to the next seven.

The team

What changes the effort

• Fee complexity. Instalments, late fees, concessions and transport fees each add rules.
• Languages. English is the baseline. Hindi and regional languages in the parent app add translation and testing.
• Teacher app. Attendance from the web app on a phone is the MVP; a separate teacher app is a later step.
• Data migration. Clean Excel imports are quick; data from an old ERP needs mapping per school.
• Compliance. Children's data needs careful consent and access controls under the DPDP Act from the start.

Risks and how we'd handle them

What we'd measure

Build or buy?

For a founder, the question is less build versus buy and more build now versus build later. White-label school ERPs can be resold, but you'd be competing on price with the vendor and its other resellers, with no product of your own. A focused MVP built on a sound multi-tenant foundation gives you something to sell, learn from and raise money on. The key is keeping version one small enough to launch in a term, not a year.

Questions we'd ask on the first call

• Which schools have agreed to pilot, and what do they use today?
• What will schools pay, and is it per student or per school?
• Do you plan to take a fee on payments, a subscription, or both?
• Which features have schools said they'd switch for?
• What's your timeline for funding, and what do investors want to see?

FAQ

Who owns the code?

You do. The code, cloud accounts and data are yours from day one.

Can we add features after launch?

Yes. The platform is designed to grow module by module, and we can continue with you or hand over to your own team.

How do schools pay us?

The MVP includes simple subscription billing for schools, and the payment gateway can deduct a platform fee automatically from parent payments if that's part of your model.