Education software development
Fee collection, learner platforms and reporting — built for organizations that run across many centers.
What Education actually demands.
Education organizations rarely fail at teaching. They fail at the operational layer wrapped around it — fees, rosters, batches, receipts, reporting — which grows one spreadsheet at a time until nobody can answer a simple question about money without an export and an afternoon.
The structural reason is that education is almost never one place. A school opens a second branch, an academy adds a center in another city, a training provider runs the same course as four batches with four start dates. Each one quietly invents its own receipt book, its own discount rules and its own idea of when a month begins. Software that assumes a single location, a single price and a single term breaks on first contact with the second center.
So we build the boring parts properly first: one ledger where a cash payment and a card payment behave identically, a hierarchy that mirrors how you actually operate, and reporting that filters rather than aggregates. Portals, receipts, dashboards and reminders are views over that. Get the ledger right and the rest is straightforward — get it wrong and no dashboard rescues you.
What we build here.
Fee collection, learner platforms and reporting.
Fee collection & receipting
Recurring plans, online and offline payments, and receipts that match the ledger. We model a fee plan as a schedule generator rather than a price tag, so dues are derived instead of hand-typed, and every concession or adjustment leaves a trail. Cash handed to a coach and a card payment made at midnight land on the same posting path.
- Monthly, quarterly and yearly cycles from one plan definition
- Part-payments, refunds and adjustments recorded as ledger events, never as edits
- Receipts issued in your own format, identical whether payment came in by card or cash
- Per-student overrides and concessions recorded against the plan, not buried in a note
Multi-center, batch and cohort structure
A hierarchy that matches how the organization actually runs — student to batch, batch to center, center to city — with every payment inheriting that path the moment it's recorded. New branches open as data, not as a code change. Access is scoped server-side, so a center login cannot read another center's roster or revenue.
- One hierarchy shared by roster, plans, payments and reports
- Role-based access scoped per city, center or campus
- Batches, terms and intakes handled as first-class objects, not as tags
Parent and learner portals
Portals that survive contact with real users. Parents follow a link, find their student, see what's due and pay — no signup, no app store, no password reset at 9pm before a deadline. Learner-facing views cover schedules, attendance, materials and progress, and stay usable on a mid-range phone on mobile data.
- Public payment flows that need no account, while still posting against the right student and batch
- Learner and parent views built from the same data the staff console writes
- Front ends tuned for slow networks and small screens, not just for the demo laptop
Finance & operations reporting
Head office gets the other half of the system: collections, dues and income filterable by city, center, batch, plan and period — built on the same ledger the portal writes to, so the two views cannot drift. Reports drill from an organization-wide total down to a single batch without leaving the browser.
- Outstanding dues as a live view rather than a month-end reconstruction
- Offline entries attributed to the staff member who recorded them
- Exports where finance genuinely needs them, not as the only way to get an answer
Migration & legacy modernization
Most of this work starts with data you already have — spreadsheets in varying shapes, an aging admin panel, a fee history somebody maintains by hand. Import is a first-class feature, not a one-off script: upload, validate, review, commit. It runs again every intake season, and again each time a new branch comes online.
- Dry-run validation that reports bad rows before anything is written
- Students, batches, plans and outstanding dues in the same pass, so the ledger starts honest
- Idempotent imports — re-running a corrected file doesn't duplicate a student
- Legacy PHP and CodeIgniter systems modernized in flight, not by big-bang rewrite
Work we've shipped in this space.
Real engagements, picked because they were hard.
How we'd engage.
Custom Software & SaaS
Business-critical platforms, engineered MVP-to-scale.
Full-Stack Team on Demand
Frontend + backend capacity, onboarded fast, in your stack.
Education, answered.
No. A parent follows a link, finds their student and pays, and the payment still posts against the right student, batch and center. Requiring an account is where fee portals lose collection — a password reset at 9pm before a deadline is a cost nobody budgets for.
They post through the same ledger and receipt series as card payments, attributed to the staff member who recorded them. Dues and reporting behave identically either way, so month-end stops being a stitching exercise across center spreadsheets.
That's the normal case, so a plan is modeled as a schedule generator rather than a price tag. Monthly, quarterly and yearly cycles come off one definition, and per-student concessions are recorded against the plan instead of buried in a note.
Yes. Collections, dues and income filter by city, center, batch, plan and period off the same ledger the parent portal writes to, so the two views cannot drift. Reports drill from an organization-wide total to a single batch in the browser.
Project-based with milestone billing, scoped after a discovery call with written notes from the engineer who'd lead it. Admin teams are rarely technical, so handoff is runbooks and documented code alongside the repo, and the code is yours with no lock-in.
Related.
Building in Education?
Share the brief and we'll reply within one business day — from a senior engineer, not a sales bot.