Planned Not yet started — this page describes the intended design and build plan.
Overview
Notipa is built for schools that may serve families without reliable smartphones or data plans, which
makes an app-only notification path a real access gap. SMS fallback sends a short text message for
time-sensitive items — a new announcement, a homework due date, a fee notice, a permission slip — to a
guardian who either doesn't have the app installed or has opted into text alerts as their primary
channel.
This is a fallback, not a replacement: the full content still lives in the app, and the text message is
a short "there's something for you in Notipa" notice, not a substitute for the actual announcement.
How it will work
Opt-in per guardian. A guardian adds and verifies a phone number, and chooses which notification types (if any) they want by SMS, alongside or instead of in-app/email notifications.
Short, actionable texts. Messages stay brief — sender/school name, a one-line summary, and a link if the guardian's phone can open it — to keep per-message cost low and respect the format's limits.
Pluggable SMS provider. Since this is self-hosted software running in many different countries, the app integrates with an SMS gateway through a swappable provider interface rather than hard-coding one vendor, since coverage and pricing vary enormously by region.
Cost visibility for admins. Because SMS costs money per message (unlike everything else in Notipa), an admin gets visibility into a school's own provider account and usage, rather than the app hiding a per-message cost from them.
Development plan
1Phone verification & preferences
Phone number field on the guardian profile with an OTP verification step before it's trusted as a notification target.
Notification-preference model extended to include an SMS channel per notification type (announcement, homework, fee notice, permission slip, message).
2Provider abstraction layer
A thin, swappable SMS-provider interface (send message, check delivery status) so a self-hosting school can plug in whichever gateway is available and affordable in their country/region.
Reference implementation against one or two widely available providers, documented clearly enough that a school can substitute their own.
Configuration lives in the same environment-variable pattern Notipa already uses for other external services, keeping setup consistent.
3Message composition & sending
Short-message templates per notification type, kept under standard SMS length limits.
Hook into the existing notification-dispatch path so SMS is one more delivery channel alongside in-app and (if present) email, not a parallel system.
Delivery status tracking and basic retry/backoff for failed sends.
4Admin visibility & testing
Admin dashboard panel showing recent SMS volume and any provider errors, so a school can see what it's actually being charged for.
Testing against provider sandbox/test modes to avoid real charges during development and CI.
Graceful degradation: if no SMS provider is configured, the feature is simply unavailable rather than erroring, so it stays fully optional for schools that don't need it.
Technical considerations
SMS gateway coverage and pricing vary drastically by country, which is why a provider-abstraction layer matters more here than it would for a single-market SaaS product.
Real per-message cost means this can't default to "on" — it has to be a deliberate, visible opt-in for both the school (configuring a provider) and the guardian (choosing the channel).
No two-way SMS (replying by text) in the first version — this is outbound notification only, keeping scope tight.