A Choice About Who We Build For
Every website is assembled from a stack of quiet decisions about how it is put together. Most of them are invisible to the people using the site, but together they settle something that matters a great deal: who can actually open the page, and how fast. When we built ImpactMojo, we made those decisions with one group in mind — development professionals across South Asia, often working on older phones, on unreliable connections, sometimes on data plans where every megabyte has a cost.
So we kept things deliberately plain. ImpactMojo is built from ordinary web pages — the same simple ingredients the web has used since its early days — rather than the heavier machinery that powers many modern apps. That machinery can be genuinely useful. But it asks a lot of the visitor: a capable phone, a strong signal, and patience while a large parcel of code downloads before anything appears on screen. For our audience, that is a cost we did not want to pass on.
A page that appears in about a second on a weak connection is not just a technical nicety — it is a question of fairness. If a programme officer in a district town has to wait half a minute for a training page to load, or gives up before it does, the quality of what we wrote is beside the point.
What “Simple” Actually Means Here
Every page on ImpactMojo is a self-contained file. Our games, for instance, are single files that hold everything they need to run. One practical consequence is that anyone — including a motivated non-engineer — can open a page, read how it is put together, and change it. We have tried to make the barrier to contributing as low as it can go.
A small number of features do need something more than a plain page: keeping track of a learner's progress, issuing certificates, receiving messages sent through a form. For those we lean on open-source tools — software whose inner workings are public, free for anyone to inspect and build on — and on hosting we do not have to babysit. We would rather spend our hours writing courses than tending servers.
When we change something, the updated pages are copied out to computers around the world within minutes, so a reader in Kathmandu or Kochi sees the new version almost as quickly as we do. None of this asks the reader to install or set up anything. They open a link, and it works.
"The best technology for an educational platform is the technology that stays out of the way of learning. For us, that means plain files, fast loading, and nothing for the reader to configure."
Why Not the More Elaborate Tools?
Skipping the heavier machinery is the choice that most puzzles other technologists, so it is worth explaining. Three things drove it.
The first is longevity. The popular tools for building web apps change quickly; what is standard this year is often half-replaced within a few, and projects built on them need steady upkeep just to keep working and stay secure. A plain web page written five years ago behaves exactly the same today, and will in another five. For a platform that means to keep serving the same content for years, that durability is worth a great deal.
The second is accessibility. Plain web pages are the most universally readable thing on the internet. They work with screen readers, on very old devices, and over slow connections without any special effort. The same can be achieved with fancier tools, but it takes deliberate work and expertise that many small teams do not have. For us, accessibility is the starting point rather than something we have to bolt on afterwards.
The third is who can contribute. We want development professionals — not only software engineers — to be able to add material to ImpactMojo. Asking a monitoring and evaluation specialist to first learn a whole software toolkit before they can share a handout on sampling would put the work out of reach. Asking them to edit a plain page does not.
The Craft in the Content
Because each game is a single, self-contained file, it can be downloaded and played offline — an essential feature for anyone working where the connection comes and goes. The Indian folk art that runs through our game illustrations (Warli, Madhubani, Gond, and other traditions) is drawn with lightweight code and simple shapes rather than heavy image files. That keeps pages quick to load while celebrating South Asian artistic heritage instead of reaching for generic stock imagery.
Trade-offs and Honest Limitations
No choice like this comes free. Staying plain means some things are genuinely harder for us to build: real-time collaboration, content that reshapes itself for each learner, the kind of rich interactive simulation that the heavier tools handle well. And as the platform grows, looking after hundreds of individual pages by hand becomes a real chore. We manage it with small helper scripts and shared styling, but it is an honest limitation, not a hidden strength.
The wider point is that decisions like these should follow from context — who your readers are, what your team can maintain, what kind of content you are serving — rather than from whatever is currently in fashion. For a larger engineering team the balance might tip the other way. For ImpactMojo, serving the readers we serve, simplicity is not a compromise. It is a feature. Everything this approach exists to deliver is in the course catalog, free to use and reuse.