Product engineering
The systems under the product: the platform itself, the integrations around it, and the unglamorous plumbing that has to keep running while people are mid-lesson.
- Platform architecture
- Internal tooling
- API design
- Reliability
/ Technology
Six disciplines, all pointed at software we own. Nobody hands a decision over at a boundary here, because there is no boundary to hand it over at.
/ The stack
- 01Product engineering4 areas
- 02Applied AI4 areas
- 03The browser as the runtime4 areas
- 04Built for the devices people have4 areas
- 05Product design4 areas
- 06New bets4 areas
01 02 Applied AI
Models doing real work inside the product — a tutor that answers in thirteen languages, retrieval across our own curriculum, and the evaluation that tells us whether any of it actually helped someone learn.
- Retrieval & RAG
- Tutoring agents
- LLM integration
- Evaluation
03 The browser as the runtime
Everything runs in the browser, including the playgrounds. No installs, no setup evening, nothing to configure before the first lesson — which is where most people give up on learning to code.
- Web applications
- In-browser runtimes
- Performance budgets
- Accessibility
04 Built for the devices people have
A phone on a patchy connection is the normal case, not the edge case. The product is designed against small screens, slow networks and interrupted sessions first.
- Mobile-first
- Low-bandwidth
- Resumable sessions
- Cross-platform
05 Product design
Interfaces designed against the states we actually hit — empty, slow, half-finished, wrong — rather than the happy path in a mockup.
- Interface design
- Design systems
- Prototyping
- Accessibility
06 New bets
A narrow first version, put in front of real users, then kept or killed on what they do with it. Most ideas do not survive that. That is the point of doing it early.
- Prototypes
- Narrow first versions
- Usage evidence
- Kill criteria
011 / 4 Find the problem
Every product starts with something that keeps going wrong — usually for us first. We sit with it long enough to know whether it is worth years, because that is the commitment a product actually is.
022 / 4 Build the narrow version
One slice of the idea, built properly rather than sketched. Real code, real data, deployed — small enough to throw away if it turns out we were wrong about the problem.
033 / 4 Put it in front of people
Usage settles the argument. We watch what people do with it, not what they say about it, and we cut the parts nobody touches — including the ones we liked.
044 / 4 Keep it alive
Launch is where the work starts being useful. Monitoring, fixes, and the changes that only make sense once people have shaped their week around the thing.