Read-to-Earn EdTech Case Study

A platform that pays teenagers to read aloud to their younger siblings. They record a session, upload it, and once an admin approves it they earn coins towards a gift card.

I led the product from the idea through to a defined MVP: research, competitor analysis, the role model, the flows, and the interface across a desktop web app and a mobile one.

The idea is simple to say and hard to build: pay a minor for work you cannot fully verify, in a household where the person signing up may not be the person reading.

Every hard part of this product is a constraint rather than a feature: consent, review, and the tax rules around paying someone under eighteen.

I looked at how reading apps hold a young reader's attention and how allowance and chore apps handle money moving to a minor. The two categories solve halves of this problem and neither solves both.

The question the analysis had to answer was narrow: what makes a teenager come back for a second session, when the reward is real money but the effort is a quiet twenty minutes with a sibling.

Scoping sessions to draw the line around an MVP that could actually ship, and to separate the rules that were ours to choose from the rules that were not.

We agreed three roles: reader, admin and super admin. Review of every recording stayed human rather than automated, and payment stayed manual. For a first release, a person in the loop is cheaper and safer than a system that has to be right.

Paying a teenager cash creates two problems at once: an annual reporting threshold that caps what anyone can earn, and a reward that feels like payroll rather than something worth chasing.

The design answers both with coins. A session earns coins, sixty coins convert to a fifteen-dollar gift card, and the ceiling lives in the currency rather than in a warning about tax. The rewards screen states the rule in the reader's own terms: you need at least sixty coins to redeem. A claim is confirmed rather than instant, because a person still releases it.

A parent or a teenager registers, consent is captured, and an admin approves the account. The reader records a session between fifteen and sixty minutes, uploads it, and waits. An admin reviews it. Approval turns into coins, coins turn into a gift card, and a super admin releases it.

Consent is not a checkbox here. It is a signed parent or guardian form with an audio release for a minor, carrying the teen's profile and the guardian's details side by side, because the thing being collected is a child's recorded voice.

The reader's surface is built around one action and one number: upload a session, watch the balance grow. The upload rules sit on the button, not in an error message after a failed upload: fifteen minutes minimum, sixty maximum, under sixty megabytes. A teenager on a phone will not survive losing a twenty-minute file.

Because every recording is reviewed by a person, the recordings table is the honest part of the product: each session carries its duration, its size and its status, and a rejection is shown in plain red rather than quietly dropped. The empty state says so too: no coins yet, and what to do about it. Mobile carries the same model rather than a cut-down version of it.

The reader experience is designed across a desktop and a mobile web app: onboarding, consent, recording, rewards and profile, with four roles and the whole path between them: registration, consent, recording, upload, admin review, coins, gift card, and super-admin release. Consent shipped as a signed parent or guardian form with an audio release rather than a checkbox, because the thing being collected is a child's recorded voice.

The admin and super-admin consoles are specified but not yet drawn, so this stopped short of a finished product rather than at a launch. Converting the payment into coins is the decision the rest of it hangs from, it turned a compliance ceiling into a game mechanic. There is nothing measured to report yet; the first number that would matter is review-queue latency, which is the thing the design already expects to break first.

Converting the payment into coins was the decision that made the rest of the product possible. It turned a compliance ceiling into a game mechanic, and it let the interface talk about earning without ever talking about tax.

What I would watch: every recording being reviewed by a person is right for a first release and will not survive success. The queue is the thing that breaks first, and the design should make that failure visible early rather than quietly slow.