What it is
Explicaki connects students with tutors. A student searches by subject, level and tutor, requests a session, pays through mobile money, and talks to their tutor in the app. Around that core there are subject communities where questions that do not justify booking a session can be asked in public.
It was the flagship product of Kudondza Solutions, an education technology startup I co-founded, incubated at the Eduardo Mondlane University. I was the technical lead, which in a startup of that size means I was the engineering department.
Why it looked different from the tutoring apps I studied
I looked at the competitors operating locally and internationally, and the gap was not features. It was payments and connectivity.
Card payments are not how most Mozambicans pay for anything. If the checkout assumes a card, the product is unusable for the majority of its market regardless of how good the matching algorithm is. So M-Pesa integration was not a nice-to-have to schedule for version two, it was a precondition for version one.
The same logic applied to notifications. A tutoring request is time-sensitive, and you cannot rely on a tutor having the app open on a stable connection. Push notifications through Firebase Cloud Messaging were structural rather than decorative.
The general lessonWhen building for a market, the parts that look like integrations are often the parts that decide whether the product works at all. I now treat “how does money move here” and “how do people actually get notified here” as design questions, not implementation details.
What is in it
- Session requests and management: a student requests, a tutor accepts, the session gets scheduled and tracked.
- Profiles for both sides: students and tutors, with subjects, levels and availability.
- Search and filtering by level, subject and tutor.
- Subject communities: posts, comments and likes, organised per subject.
- Real-time chat, scoped to active tutor and student pairs rather than an open messaging system. This was a deliberate constraint: unrestricted messaging in a marketplace invites people to take the transaction off-platform.
- M-Pesa payments through the official SDK.
- Push notifications with Firebase Cloud Messaging.
How it is built
Django with a REST API, Vue 3 and Quasar on the frontend, PostgreSQL underneath, hosted on PythonAnywhere. Designs were done in Figma before implementation, which for a two-sided marketplace saved a lot of rework.
Quasar mattered here for a specific reason: it targets mobile and web from one codebase, and the realistic device for a student in Maputo is a phone.
What went wrong
The payment integration was the schedule. Everything else was estimable. Integrating with a mobile money SDK, testing it, and handling the failure cases (timeouts, partial confirmations, a user who pays and closes the app) took far longer than the feature list suggested. If I were estimating this again I would double whatever I thought payments would cost, and then start with them.
Two-sided marketplaces are a cold-start problem, not an engineering problem. The platform worked. Getting enough tutors and enough students onto it simultaneously is a business challenge, and no amount of good code solves it. This is the clearest lesson I took out of the whole venture.
Hosting on a shared platform was fine until it was not. PythonAnywhere is excellent for getting something live cheaply. It is less pleasant when you want background workers and control over the runtime.
Status
The platform is no longer hosted, so there is no live link. The startup is registered and the codebase exists, but the product is not currently running. I keep it listed because it is the project where I learned the most about building for the market I am actually in, and because payments and real-time features are genuinely hard-won experience.
