Learning platforms that hold up when an entire cohort logs in at once
Willowark builds the systems behind education and training products: content pipelines that publish reliably to multiple formats, integrations with the LMS and student information systems your customers already run, scheduling and cohort logistics, applied simulations and training games, and the telemetry that shows whether anything was learned. What we remove is the engineering work between your content and the institutions that consume it on their own terms.
We work as contract engineers on bounded pieces of that stack. Integration starts from a canonical internal model with per-customer adapters, so LTI launches, roster sync, and SCORM or xAPI packaging stop being reimplemented per deal. This is territory we have shipped in: AI operating software for Jaguar Land Rover's training schedulers, plus a training video game built for their trainers.
A first engagement with an EdTech team is usually tied to a date on the academic calendar: the LTI integration a district contract depends on, the content pipeline that has to publish a new edition before term, or the load work after a bad first week. We plan backward from that date, ship the integration behind a flag so it can be tested against the customer's sandbox early, and leave the platform team with adapters they can extend. Small teams with a large content surface need engineering that reduces per-customer effort, not another bespoke build.
Reviewed
Sound familiar?
If you've said any of these, we should talk.
“Every new customer wants us to integrate with a different LMS or SIS.”
We build that layer once instead of per deal: a canonical internal model for courses, sections, enrollments, and results, with per-customer adapters and mapping configuration around it. LTI 1.3 launch, roster sync, grade passback, and SCORM or xAPI packaging become supported capabilities rather than bespoke projects.
“The platform buckles in the first week of the term.”
We model the real load shape rather than an average, because a term start is a spike concentrated into hours. That means load testing against the actual concurrency pattern, caching the read paths that dominate it, moving enrollment processing onto queues with backpressure, and pre-warming capacity ahead of known dates.
“Our customers want hands-on practice, not another video course.”
We build applied simulation and training games: scenario engines with real state and consequence, scoring and feedback models developed with your instructional designers, and browser delivery so nothing needs installing on a locked-down machine. We built exactly this kind of training game for Jaguar Land Rover trainers.
“We report completions and clicks. Customers keep asking for evidence of learning.”
That gap is a data modeling problem, not an analytics tool problem. We design the telemetry deliberately — meaningful learner events, xAPI or Caliper statement design where a standard applies, stable identifiers across sessions — then pipe it into a warehouse with cohort, progression, and mastery models on top.
“Procurement wants accessibility documentation and a student data privacy agreement before they will even pilot.”
Both are engineering questions dressed as paperwork. We build accessibility into the component layer — keyboard paths, semantic markup, captions and transcripts in the content pipeline — and test with assistive technology so the documentation describes what the product actually does. For student privacy, we design data minimization, retention, and deletion paths that match the terms your legal team signs.
How this industry actually runs
The operation as we usually find it.
EdTech companies are usually content-heavy and engineering-light: a large instructional design group, a small platform team, and a release calendar set by the academic year or a corporate training cycle rather than by sprints. Everything must land before term start or an annual compliance window, and then traffic arrives all at once instead of ramping. Every customer brings a different environment — Canvas, Moodle, Blackboard, an enterprise LMS, a state SIS — expecting LTI 1.3 launches, deep linking, roster sync, and grade passback that matches their gradebook exactly. Procurement adds accessibility documentation and student privacy terms on top.
Product, integrations, and the AI feature behind them
Components:
- Your product (web, mobile, API)
- Backend services (queues, jobs, evals)
- AI feature (retrieval, review gates)
- Data & integrations (warehouse, third parties)
Connections:
- Your product to Backend services (API)
- Backend services to AI feature (structured calls)
- Backend services to Data & integrations
What we build
Starting projects that fit EdTech & Training Platforms.
- LTI 1.3, SCORM, and xAPI or cmi5 integration, plus roster sync and grade passback
- Content pipelines with versioned sources, automated transforms, staged publish, and rollback
- Scheduling and cohort logistics across instructor, room, equipment, and session constraints
- Applied training simulations and browser-based games built with instructional designers
- Learner telemetry: event schema design, warehouse pipelines, and cohort and mastery analytics
- Load engineering for term-start spikes, including queueing, caching, and capacity pre-warming
- AI features for content support, adaptive sequencing, and assessment assistance with human review
- Accessibility engineering and student data privacy controls: retention, deletion, and consent handling
Capabilities we bring
Working in EdTech & Training Platforms?
Tell us the line.
What runs by hand, what is not connected, what you are trying to build. An engineer replies within one business day with whether and how we would approach it.
Common questions
What EdTech & Training Platforms teams ask first.
Have you built training software before, or just general platforms?
Both. We built AI operating software for Jaguar Land Rover's training schedulers that removed manual scheduling and logistics work and saved hundreds of hours a year, plus a training video game for their trainers. The work covered full-stack development, cloud architecture, and distributed systems across the JLR ecosystem.
Can you build a simulation or training game without a game studio?
For applied training, yes. The value sits in the model underneath — accurate scenario logic, real consequences, and scoring your instructional designers trust — not in production art budgets. We build these on web technology so they run in a browser on managed devices.
Can you integrate with LMS platforms we do not control?
That is the normal case, and it is why the standards exist. LTI 1.3 handles launch, identity, deep linking, and grade services against any conformant LMS, and rostering standards cover enrollment sync. Where a customer's environment deviates, we write an adapter behind the same internal interface.
We have to ship before the term starts. Can you work to a hard date?
We can plan to one, and we are honest early about whether the scope fits. The academic calendar does not move, so the variable is scope: we typically split the work into what must be live on day one and what can follow behind a flag in the first weeks of term, and we test against the customer's LMS sandbox as soon as credentials exist rather than at the end. If the date and the scope do not fit, you hear that in the first conversation, not the last.
Can we add AI tutoring or grading features without putting student data at risk?
Usually yes, if the data handling is designed before the feature. That typically means keeping student identifiers out of prompts, routing to providers whose terms exclude training on your data, retaining nothing beyond what the feature needs, and giving instructors review and override on anything that affects a grade. We build the evaluation set from your own content first so quality is measured against the curriculum rather than a generic benchmark. The privacy terms your customers sign set the limits; the engineering enforces them.
Strategy. Software. Systems.
Engineering for EdTech & Training Platforms.
Describe the problem in your own words. An engineer reads it — not a sales script — and tells you plainly what it would take.