What is Emofy?
The product, the people it serves, and the single idea the entire architecture is built around.
Emofy is a child-development and education platform. It started in early childhood (daycares, kindergartens, activity and sports/art centers, ages 0–6) and extends toward K-12. Unlike a generic workspace or school-management tool, every feature is judged against one question: does this serve a child's development and education?
Three audiences, one platform
Emofy creates value at three levels at once.
| Audience | What they get |
|---|---|
| Parents | A continuous, portable record of their child's growth — the development passport — plus daily visibility into what happened at the institution. |
| Institutions | One operational platform replacing the WhatsApp-and-spreadsheet sprawl: communication, attendance, billing, scheduling, and more. |
| Developers | An ecosystem. Domain-specific features ship as EMAs (Embedded Mini Apps) through an app store, so the platform grows without the core growing. |
The parent is the primary long-term user; institutions pay for operational efficiency and parent engagement; developers extend the surface area.
The one idea: the child development passport
The product thesis — and the reason the architecture looks the way it does — is the child development passport: a growth record that is owned by the parent and travels with the child between institutions.
This drives the dual-ledger model (ADR-020): the same child activity is recorded in two places.
Institution operations Parent-owned passport
(org-scoped, institution-owned) (portable, follows the child)
│ │
│ teacher logs a daily report │
▼ ▼
org operational ledger ──projection──▶ passport ledger
(deleted if the child (persists across
leaves the school) institutions, consent-gated)When a child changes schools, the operational data stays with the old institution, but the passport follows the parent. This is also why permissions are relationship-based (ADR-021): access to a child's data is the intersection of role, active enrollment, and consent — so a teacher's access ends when the child leaves, while the parent's does not.
Core vs. EMA: the rule that keeps the platform small
The second load-bearing decision is EMA-first (ADR-003):
- Core holds only institution-agnostic interaction channels: the feed, messaging, tasks, timeline, and notifications.
- Everything domain-specific — attendance, gradebooks, behavior tracking, library lending, transport — ships as an EMA: an isolated JavaScript bundle, loaded in a sandboxed iframe, granted scoped permissions, and able to write back to core only through feed cards, messages, and tasks.
This is what lets a daycare and a high school run on the same core with different EMA sets. Read more in The EMA ecosystem.
How a day flows through the product
A concrete loop makes the pieces click:
- A teacher opens the consumer app, scoped to their institution, and posts a daily report (a photo + activity note) to the feed.
- The platform fans out a notification to the linked parent.
- The parent opens the app, sees the report, and replies in messaging.
- The activity is projected into the child's passport, which grows over time and persists across institutions.
Every step in that loop is a core channel; the institution-specific machinery around it (which class, which curriculum, which attendance record) is EMA territory.