Education
SIDER: an offline digital school for rural classrooms
A gamified STEM and English learning platform built as a PWA. It runs with no internet, updates by USB, and copes with power outages and data corruption.
Concept ✓ Feb 2026Prototype ✓ Mar 2026Pilot ✓ 2026
Next: Multi-school scaling in Urubamba
- PWA
- Offline-first
- Data-mule sync
- Gamification
The problem
Rural schools in Cusco have low-spec computers, power outages and no reliable internet.
Updates and content had to reach schools without a connection, and the system had to survive the conditions it would run in.
What I built
I led the design and build: concept, PRD and TDD, the PWA, USB deployment, and the pilot and logistics plans.
- A progressive web app for low-spec computers that works with no internet connection.
- A data-mule update system: new content travels by USB drive or local transfer.
- Handling for power outages, data corruption and field connectivity failures.
- A gamified STEM and English curriculum with missions and experience points.
- A teacher panel to register students, follow their progress and export data by USB.
From idea to pilot
Concept ✓ Feb 2026
The offline-first concept, the CONCEIVE and PLAN phases, and four technical concept documents (V1 to V4).
Prototype ✓ Mar 2026
PRD v1.0, TDD v1.0 and an MVP test plan, then the MVP: a student app and a teacher panel.
Pilot ✓ 2026
A pilot execution plan (V5) and a logistics automation architecture (V6), then the pilot itself: 6 schools in the Cusco region, 300+ students.
Result. The pilot reached 300+ students in 6 schools. The next step is scaling across schools in Urubamba.
Next: Multi-school scaling in Urubamba
Inside the product
Business and scale plan in seven parts
The plan as written in March 2026, before the pilot. Status says how much each part is worth: a figure from a source, a plan, a target still to be validated, or a risk that was open.
| Part | What the plan says | Status |
|---|---|---|
| 1. Problem | Rural Urubamba breaks any conventional software design: only 23.6% of rural households have internet (INEI, 2023), outages are frequent and earlier hardware donations failed for lack of maintenance and lost data. The rule that follows: no part of the system may depend on the internet to run. | Cited data |
| 2. Customer and market | The sponsor is FutureSense Foundation with Challenges Abroad. The pilot starts at one school; the aim is to reach 40 to 50 multigrade schools in Urubamba, about 3,500 students, within 24 months. | Plan |
| 3. Product | Three layers: a digital core of gamified missions that runs 24/7 without internet, a teacher panel with no command line, and physical STEM workshops run by volunteers and tied to the digital missions. | Built, piloted |
| 4. Unit economics | The school server was validated at S/ 405, 25.6% below the baseline, and the saving went into an SSD (about S/ 95) because memory cards fail with blackouts. Tablets are about S/ 460 each. The target is an acquisition cost of S/ 3,000 or less per equipped school, to be checked against invoices. | Target, to validate |
| 5. Delivery plan | A team of four for six months is 24 person-months. 21 are planned and 3 (12.5%) are kept as a buffer for the update system and field support. Seven initiatives are ranked with RICE and MoSCoW across three horizons. | Plan |
| 6. Success criteria | Eight criteria, held for four consecutive weeks, unlock expansion: uptime above 99% in school hours, no corruption incident, one successful USB export, more than 80% of students finishing a mission, more than 4 hours a week per active profile, 30 sessions under 200 ms, acquisition cost within target and no on-site repair visits. Results against them are not published. | Defined, results not published |
| 7. Risks | Nine technical and field risks, each with an owner. Two were open when the PRD was written: alignment with the national education plan, which needed an agreement with the local education authority before month 2, and the supply of Raspberry Pi in Peru, with donated mini PCs as the fallback. | Open at the time |
From the SIDER PRD v1.0 (20 March 2026). Amounts in Peruvian soles. The pilot has ended and SIDER is not running in schools today; scaling across Urubamba is the next step, not started.
Requirements: an excerpt of the PRD
I wrote the requirements and design documents of the pilot (PRD and TDD, version 1.0, 20 March 2026). These are the requirements that shaped the system most. Each one ends in something that can be checked.
| ID | Requirement | Priority | Acceptance criterion |
|---|---|---|---|
| FR-03 | Telemetry export by USB | Should, months 2 to 3 | A USB labelled SIDER_SYNC writes the log file in under 30 seconds and shows a success signal. No session is exported twice. Any other USB is ignored. |
| FR-04 | Offline update with A/B partitions | Could, months 4 to 6 | If an update fails (bad checksum, corruption or a failed boot), the system returns to the previous partition with no action from the teacher, no loss of data and under 3 minutes of downtime. |
| NFR-01 | Concurrency | Must | More than 30 simultaneous writes with a latency under 200 ms on a Raspberry Pi 4 with 4 GB. |
| NFR-02 | Memory | Must | Node.js, Express and SQLite use no more than 500 MB under a load of 30 sessions. |
| NFR-03 | Availability | Must | The server is up more than 99% of the time that power is available, and it survives blackouts because the operating system is read-only. |
| NFR-05 | USB security | Must | Only USB drives labelled SIDER_SYNC and signed updates are processed. Zero unsigned programs run. |
| NFR-06 | Touch targets | Must | Every control is at least 48 by 48 px for tablets of 7 to 8 inches. |
| NFR-09 | Privacy | Must | No full name or ID number is stored in plain text in the exported logs. Students are identified by a SHA-256 hash. |
| NFR-10 | Power loss | Must | 1,000 consecutive simulated power cuts without corrupting the SQLite database. |
Excerpt of the SIDER PRD v1.0, 20 March 2026, written for the pilot sponsor, FutureSense Foundation. School and people names are removed. These are requirements and acceptance criteria, not test results.
Design decisions: an excerpt of the TDD
The TDD answers three questions for each subsystem: which pattern, why it beat the alternatives, and how it fits the rest.
| Principle | What it means | Ruled out |
|---|---|---|
| Offline first | No network is the normal state, not an error to catch. | Code that tries a request and falls back when it fails |
| A deliberate monolith | One Node.js process runs everything. No containers and no service mesh. | Microservices, Docker Compose |
| Defensive writes | Every disk write assumes the power can go out. SQLite in WAL mode with immediate transactions is the only way to store data. | Writing JSON files directly |
| No runtime dependencies | The production bundle needs no network, not even for fonts or icons. | CDN links, remote fonts |
| Smallest attack surface | No open external ports, no remote login, no unsigned programs. The school network is the perimeter. | Exposed SSH, a public API |
| Maintainable over elegant | A standard stack and comments in Spanish, so a junior developer can fix a problem in the field. | Bleeding-edge frameworks |
Excerpt of the SIDER TDD v1.0, 20 March 2026. The hardware is a Raspberry Pi 4 with an SSD, a read-only root partition, two identical system partitions for updates (A and B) and one data partition.
Product management and development skills shown on this page
Each skill points to the place in the documents where it can be checked.
| Skill | Where it shows |
|---|---|
| Prioritising with RICE, MoSCoW and release horizons | Seven initiatives scored on reach, impact, confidence and effort in person-months. The USB export is a Should for months 2 and 3 and the update system a Could for months 4 to 6, so the first release does not wait for the hardest part. |
| Business case and unit cost | A server validated 25.6% below the baseline price, with the saving moved to the part that fails most, and a cost target per equipped school. |
| Defining success metrics | Eight criteria with a target and a way to measure each, written before the pilot started. |
| Writing acceptance criteria that can be tested | Every requirement above ends in a number or something observable: 30 seconds, 200 ms, 500 MB, 1,000 power cuts. |
| Scoping | The PRD lists what is out of the pilot: satellite internet, devices for homes, a native app, adaptive AI and third-party login. |
| Designing for a non-technical operator | A rule of no command line for the teacher, traffic-light status colours and a USB drive as the whole interface for exports and updates. |
| Planning a field pilot | A pilot execution plan (V5) and a logistics automation architecture (V6) followed the PRD. |
| Offline-first architecture | A service worker cache and a queue in the browser on each tablet, and a SQLite database in WAL mode on the school server. |
| Updates that survive failure | Signed updates written to the idle partition, a 30-second health check after boot and an automatic rollback. |
| Data model and a local API | Four tables (students, sessions, modules and sync log) and an API that runs on the school network and calls nothing outside it. |
| Privacy by design | Student IDs are hashes, and the exported logs contain no names. |
“In the Peru Hub, Andres has contributed to the development of SIDER and supported Monitoring & Evaluation processes. … He has demonstrated a good ability to translate operational needs into practical solutions and collaborate across different teams.”
Gonzalo Davila NovoaRegional Manager, Latin America, FutureSense Foundation