Who gets to control a child’s money?
Earlybean began as a financial-literacy product for children and evolved into a family-finance and school-payments ecosystem. I co-founded the company and led product direction and hands-on design across the parent, child, school and merchant experiences.
A financial-literacy app was not enough
Earlybean started with lessons, savings goals and a child-centred experience. It taught the mechanics of saving, but gave families limited ways to apply them with real money.
What parents and schools actually needed
Across school conversations and repeated parent feedback, the same tensions kept surfacing. Parents did not want another standalone banking relationship: they wanted to fund children from accounts they already used, retain control, and understand how money was being used. Schools wanted oversight inside their own environments. Children needed safe, practical places to save, spend and transfer real money.
Each of those tensions belonged to a different party, and none of them could be resolved inside a child-facing app. That is what turned a product question into an architecture question.
Reframing the product around relationships
The product stopped being only a child-facing app. It became a system connecting a parent’s authority, a child’s bounded financial identity, a school’s oversight and operating role, and a merchant’s ability to receive and manage money. Trust, permissions and money movement became the architecture; the interfaces followed from that model.
Those three relationships do not run in the same direction. Money enters from a parent’s existing bank and leaves to an approved merchant or a validated account; authority runs from the parent over the child’s controls; oversight runs from the school across its own environment and no further. Reading them as one diagram is what makes the boundary visible.
| Over the child’s money | Parent | Child | School | Merchant |
|---|---|---|---|---|
| Fund the account | Yes, from an existing bank account | No | No | No |
| Set limits and block spending | Yes, per rail | No | No | No |
| Approve a request or release a reached goal | Yes | Can request | No | No |
| Spend by card or tag | No | Within limits, approved environments only | No | Receives, cannot initiate |
| Transfer to an Earlybean ID or bank account | Yes | Within limits | No | No |
| See activity | Everything | Own balance, goals and requests | Its own environment, per linked student | Its own takings |
| Approve which merchants a tag works at | No | No | Yes, inside the school | Applies |
Giving parents authority without another banking app
Parents needed distinct controls for funding, approvals, limits, visibility and blocking. The product treated the parent as the authority over a child account rather than a customer expected to adopt a new bank, so parents could fund children from accounts they already used while retaining control over what happened next.
Keeping those five controls separate is the whole design. Collapsing them into one “parental controls” screen is what makes products in this space unusable: a blocking switch and a spending limit are different decisions, taken at different moments, and a request from a child is not a notification to be dismissed.
Making money behave differently by purpose
Money in a savings goal was locked and not spendable. Money loaded onto a card or wristband could be spent with approved merchants inside school environments or curated events. Transfers ran on a separate rail through Earlybean IDs or validated bank accounts. The product had to make those states and rails legible because each carried different risks, permissions and expectations.
Turning schools into safe financial environments
Schools needed more than a fee-payment endpoint. The product direction covered onboarding, monitoring, school payments, ancillary payments and oversight across school-owned and third-party merchants. Direct spending stayed restricted to approved school environments, giving schools control over merchant acceptance and reducing the risk around children carrying spendable money.
The tap, and the decline that explains itself
Everything else in the system exists to serve one moment: a child taps at a canteen till with a queue behind them. A decline there cannot be an error code. It has to name the rule that stopped it and who can lift it, because a child at a till cannot debug a permission model, and a short school-break rush is no time to be working one out.
What shipped, what remained directional
Shipped: parent-controlled child accounts, savings goals, card and wristband spending, Earlybean ID and bank transfers, school onboarding and monitoring, and the merchant application. Directional, and not presented as shipped: advanced school messaging, the complete school money OS, deeper school-owned and third-party merchant management, revenue-share or rental tracking, and the broader ancillary-payment operating model.
Recognition
Selected for the Techstars / Anjal Z Founder Catalyst and named a top-three finalist at Web Summit Qatar PITCH.
