Why we built Spanwise offline-first
Every general-purpose business tool we looked at before starting Spanwise made the same quiet assumption: that you'd always be online. In much of Africa, that assumption breaks daily — a load-shedding schedule that cuts power mid-afternoon, a router that's been down since morning, a bursar collecting fees somewhere with no signal at all.
So the ledger stayed on paper. Re-typed into a spreadsheet later, if at all. Not because schools didn't want better tools, but because the better tools didn't actually work where they needed them to.
Offline as the default, not the exception
We built Spanwise the other way around. Every action — collecting a fee, marking a register, entering a mark — writes to the device first. If there's a connection, it syncs immediately. If there isn't, it queues, and syncs the moment one appears. Nobody using Spanwise day to day should ever need to think about which state they're in.
If a feature doesn't work without internet, we don't consider it done.
That's not a slogan we put on the website and forgot about. It's a rule that shaped real engineering decisions — down to how receipt numbers are generated on a phone with no signal, so two teachers collecting fees in different classrooms never collide, and how a server-assigned number quietly takes over once the device reconnects.
What this means for a school day to day
- Fee collection keeps working through a power cut — nothing waits on the network.
- A teacher can mark a full attendance register with zero connectivity, and it appears on the server the moment their phone finds a signal.
- Marks entered from home, with no wifi, sync in automatically the next morning.
We didn't set out to build "software with an offline mode." We set out to build software that assumes the conditions schools actually operate in — and treats reliable internet as a bonus, not a requirement.