Pilot readiness is less about features and more about operational trust
A useful pilot is not the same thing as a long demo. The current readiness work in the repo keeps forcing the same discipline: we need enough product to create learning value, but we also need enough reliability, security, and visibility that a class and a set of families can use it without engineering babysitting every session.
Key takeaways
- The pilot target is concrete: one class of about 30 students plus 10 families.
- Readiness depends on launch success, grade passback, latency, crash rate, and supportability, not just feature count.
- The repo already tracks real checklist items across infrastructure, LTI, adaptive learning, Roblox, dashboards, and compliance.
- Several bars are still explicitly unresolved, especially real LMS credentials, E2E coverage, and live operational measurement.
Why this is worth writing down
It is very easy to tell ourselves that we are almost ready because the product surface looks broad. That is not the same as being pilot-ready. Schools and families do not care that a feature exists in isolation. They care whether launches work consistently, whether grades post back, whether students can finish sessions without friction, and whether adults can understand what happened when something goes wrong.
The pilot-readiness material in the repo is valuable because it refuses to let readiness stay vague. It turns the question into something operational and measurable.
What the pilot bar actually is
The current target is intentionally narrow: one school class of roughly 30 students and 10 family accounts. That scope matters because it is large enough to expose real operational weaknesses but small enough that we can still observe the system closely.
The checklist and roadmap material define a practical bar: production builds must work, core tests need to pass, LTI launch and grade passback have to function, account linking has to exist, dashboards need to answer basic adult questions, and the core safety and consent flows have to be in place.
- LTI login, launch callback, JWKS, and claims parsing are tracked as explicit readiness items
- Grade passback, session lifecycle, and account linking are already represented as implemented capabilities
- Teacher and parent dashboards are part of the pilot bar, not a later nicety
- Go/no-go criteria include launch success, grade passback success, latency, and crash rate
Where the repo is honest about the gaps
One thing I like about the current readiness documents is that they do not pretend unknowns are solved. Platform registration still needs real Canvas or Moodle credentials. Some E2E flows are still marked as pending. Launch success, grade passback reliability under real use, latency under load, and crash rate are still measured as TBD rather than quietly assumed.
That honesty is useful because a pilot does not fail only when code crashes. It also fails when a team convinces itself that staging confidence equals classroom readiness.
What this changes for how we build
The implication is simple: every major feature needs to be legible in operational terms. If we add a new student or teacher capability, we should also know what success looks like, what alerting exists, what failure mode is most likely, and how much manual support it would require during a pilot week.
That pressure is good. It keeps us from mistaking feature motion for pilot progress.
Follow the build
We'll keep adding posts here as the games, curriculum graph, teacher tools, and family experience get closer to pilot shape.