1. Why bespoke beats off-the-shelf
Generic learning management systems are designed for the average classroom that doesn't exist. The schools and tutors we work with already have a pedagogy that works - what they need is software that protects it instead of forcing them to compromise. A bespoke build lets you encode your assessment style, your reporting rhythm and your parent-communication tone directly into the product.
The trade-off is real: bespoke software costs more up front and you own the roadmap. That's a feature, not a bug, when learner outcomes are on the line. Browse our published iOS and Android apps to see how we ship product around real classroom workflows rather than feature checklists.
2. Scoping a project that actually ships
The single biggest predictor of an edtech project failing is a scope written without a teacher in the room. Before estimating, we run a discovery sprint that produces three artefacts: a user-journey map for every role (learner, teacher, parent, admin), a data model with retention rules already attached, and a thin-slice MVP that one cohort can use end-to-end in term one.
Cut anything that doesn't survive the question "would a teacher notice if we removed this in week one?". Park it on a phase-two list. Schools fund what they can see working; they rarely fund features they were promised eighteen months ago.
3. Child privacy: POPIA, GDPR-K and COPPA
Education software almost always processes children's data, and that pulls in three regimes at once: South Africa's POPIA, Europe's GDPR (with the under-16 carve-out commonly called GDPR-K), and the US Children's Online Privacy Protection Act (COPPA) the moment your app is available in the US App Store or Google Play.
Practical baseline we apply to every Conda build:
- Verifiable parental or school consent before any account is created for a learner under 13.
- Data minimisation: collect only what the lesson plan actually needs, and put a TTL on everything else.
- No advertising SDKs, no behavioural tracking, no third-party analytics that build per-child profiles.
- A documented sub-processor list and a working data-deletion route - see our privacy policy for the live commitments.
4. Accessibility you can defend
WCAG 2.2 AA is the floor, not the ceiling, for anything a child is required to use. Build with semantic HTML, real focus states and captioned media from day one - retrofitting accessibility into a finished product costs roughly three times what it costs to build it in. The same engineering discipline that helps a learner using a screen reader also helps the teacher projecting the app on a low-contrast classroom display.
5. Passing the Play Console and App Store reviews
Both stores tightened their education and children-directed policies in 2024–2025. Reviews now fail for the same handful of reasons every time:
- The developer website's domain doesn't match the contact email on the developer account.
- The privacy policy URL 404s, is generic, or doesn't disclose every SDK actually present in the build.
- No working account-deletion route - Google Play has required this since 2024 for any app with sign-in.
- Target-audience and content rating questionnaires answered inconsistently between the two stores.
Lock these in before you upload the first build. If you need help, our support team can review your store listing against the latest policy checklist and flag anything likely to fail.
6. Budget, timeline and ownership
A useful planning anchor: a single-platform MVP for one role (say, a learner-facing iOS reading app) is a 10–14 week build with a small team. A multi-role platform with learner, teacher and parent surfaces on both iOS and Android is a 6–9 month commitment. Anyone quoting much less is either underscoping or handing you a template.
On ownership: insist on holding your own Apple Developer and Google Play accounts, your own domain, and your own cloud tenancy. Your delivery partner - us included - should be a collaborator on your accounts, never the owner of them.
7. Launch, support and iteration
Launch is the start of the project, not the end of it. The first term in the wild is when the real product backlog gets written, by the teachers and learners who now depend on it. Plan for a fortnightly release cadence, a public changelog and a named human on the other end of every support request.
See our support commitments and response times for the SLAs we hold ourselves to, and the apps catalogue for examples of products we've taken from scoping to store.