Student & parent apps,
built for Nepali schools.

What this is (and what it isn't)

The Student Experience App is the layer that parents and students actually open every day. It's a separate product from the School ERP — and intentionally so.

The ERP runs admissions, billing, payroll, exam scheduling, MoHP and board reporting, transport, the unglamorous operational work. The Student Experience App reads from that data and adds the things the ERP wasn't designed for: real-time push notifications, in-app payments, photo and message feeds, multilingual parent communication, a learning timeline the student can see.

If you already have a School ERP — ours, Fedena, Tally, Gradelink, in-house — this app sits on top via integration. If you don't have one yet, we can build both together. See our School ERP solution for the admin side. The two are designed to work in tandem.

Why a separate app, not a portal in the ERP

Most ERPs ship a "parent portal" as an add-on. It's usually a stripped-down web view of the admin tables — login, see grades, see fees. Nobody opens it twice. The reason is structural: an admin tool's job is to show the admin everything; a parent app's job is to surface the 3 things this parent needs right now.

That's a different product. Different default screen, different notification strategy, different UX vocabulary, different update cadence. We build it as a separate app for the same reason banks have a different mobile app from their teller software — same data, different jobs.

(More on the design choice in our piece on student-centric school software.)

Modules we typically ship

• Real-time attendance — biometric or QR check-in pushes a notification to the parent within a minute. Absent-student SMS as a fallback for parents without the app installed.
• Fee payments — invoice push, in-app payment via eSewa, Khalti, IME Pay (or bank transfer with screenshot upload as fallback). Receipts auto-emailed. Late-fee handling built in.
• Homework and assignments — teachers post; parents and students see; submission flow optional.
• Gallery and announcements — school events, sports day photos, term-end notices. Push-notified.
• Two-way teacher messaging — bounded channels with moderation. Translation to Nepali or English at the click of a button.
• Report card delivery — when results publish in the ERP, the report card lands in the app as a downloadable PDF + a friendly summary view.
• Student learning timeline — for older students, their own view of recent results, feedback, upcoming work, and personal goals.
• Event calendar — exams, holidays, parent-teacher meetings, sports day. Add to phone calendar in one tap.

The integration story

The app needs to read student data from somewhere. Options we support:

• REST / GraphQL API integration — if your ERP exposes one. We sync via webhooks or scheduled pulls.
• Direct database read (read-only) — common for older ERPs that don't have a clean API. We add a read replica or a per-table view to avoid touching the operational DB.
• Scheduled export / SFTP — for legacy systems that only support nightly CSV exports.
• Our own School ERP — native integration; no work needed.

We've integrated with Fedena (REST), Tally Education (DB read), Gradelink (API), in-house systems (varies), and several Excel-based "systems" (CSV import with reconciliation rules).

The Nepal-specific bits

A few things we build differently because of Nepal's reality:

• Payment provider redundancy — eSewa, Khalti, and IME Pay all have outages. We integrate at least two so a parent can always pay.
• Mobile-first, intermittent connectivity — the app works offline for read; queues writes for retry. Important outside Kathmandu valley.
• SMS fallback for parents without the app — for the school's poorer parents, SMS is still the right channel for attendance and fee notices.
• Multilingual content — Nepali primary, English secondary, with selective regional language support where required.
• Data residency — for schools concerned about data leaving Nepal, we deploy to in-country data centers (NTC, World Link, etc.) instead of AWS.

What it's not (so you don't ask)

• It's not a learning content platform. We don't host courses or video lessons. (We integrate with platforms that do.)
• It's not a tutoring marketplace. Different product, different business model.
• It's not gamified-everything. Engagement comes from genuine value (real-time attendance, easy payments) — not points and badges that decay.
• It's not a replacement for face-to-face parent-teacher meetings. It reduces the volume of low-value interactions so the high-value ones get attention.

Hosting + pricing

Same two models as our other education solutions:

• SaaS (we host) — your school's instance on our infrastructure. Per-student-per-month pricing, app published under your school's name in App Store / Play Store.
• Self-hosted — deployed to your cloud account or in-country data center. You own everything.

App store accounts (Apple Developer + Google Play) are typically registered to the school; we manage the publishing process.

Implementation timeline

A typical single-school rollout:

• Weeks 1–2: ERP integration audit, data flow design, app branding (colors, logo, name).
• Weeks 3–6: Phased build — core modules first (attendance, payments, comms), then secondary (gallery, calendar, timeline).
• Weeks 7–8: App Store submission, beta with select parents, staff training.
• Weeks 9–10: Parent onboarding (in-person sessions work better than email instructions in Nepal), production rollout.

Multi-campus trusts add ~2 weeks per additional campus, primarily for parent onboarding.