Japonics / EDTECH

KOTORI

A multi-language learning platform connecting courses, spaced repetition, listening, speaking, language-school operations, and content workflows across any language, not just one.

System design Development AI/ML
KOTORI preview
Client: Japonics Year: 2026

Local-first language-learning architecture

Where the project started

Kotori connects spaced-repetition learning, active practice, and AI with language-school operations in one domain model, where learning works locally and AI/cloud extend the product instead of gatekeeping it.

Starting point

Language learning is split across flashcard apps, courses, notes, online lessons, and separate school systems.

Direction taken

Kotori connects learning and language-school domains without mixing responsibilities. Content is versioned, exercises have a lifecycle, SRS has a separate planning model, and schools get an operating panel for groups, teachers, and progress.

Business / Product

Problems and solutions

Each tile connects a real product tension with the decision that clarified the domain, UX, or operations.

Problem

Language learning is split across flashcard apps, courses, notes, online lessons, and separate school systems.

Solution

Design a platform that connects a learning engine, content, SRS, and school operations in one model.

Outcome Full EdTech domain map
Problem

The scope could easily become a feature list without one product, data, and ownership model.

Solution

Kotori connects learning and language-school domains without mixing responsibilities. Content is versioned, exercises have a lifecycle, SRS has a separate planning model, and schools get an operating panel for groups, teachers, and progress.

Outcome SRS and content authoring as separate domains
Problem

The project needed decisions that would stay readable after the first version: for users, the team, and further delivery.

Solution

SRS and content authoring as separate domains. Listening/speaking prepared for AI feedback.

Outcome Clear content lifecycle model

Roles and competencies

The competencies this build required

Competencies are shown as ownership roles: CTO, Tech Lead, engineering, DevOps, cloud, security, and AI where they were part of the work.

01

Fractional CTO

Connecting the product thesis, domain risk, and priorities so technology supports business decisions instead of becoming a separate workstream.

Open competency
Scope
  • Product category and positioning
  • Scope priorities and risk
  • Decisions ready for founder or CTO review
Applied experience
  • Product thesis translated into technical priorities.
  • Risks framed in a language stakeholders can review.
02

Tech Lead

Shaping responsibility boundaries, domain modeling, and architecture decisions so the project can grow without drifting into an accidental monolith.

Open competency
Scope
  • Bounded contexts and ownership
  • Readable technical decisions
  • Roadmap without implementation chaos
Applied experience
  • Domain boundaries and decisions that remain reviewable after MVP.
  • Ownership model readable for later delivery stages.
03

Software Engineer

Turning the domain into screens, APIs, flows, and maintainable implementation with focus on clarity and post-MVP evolution.

Open competency
Scope
  • Backend and application contracts
  • UX surfaces ready for iteration
  • Code and maintenance model
Applied experience
  • Implementation tied to the real product workflow.
  • Contracts and code prepared for post-launch iteration.
04

DevOps Engineer

Designing delivery, observability, and operations so release, diagnostics, and recovery are part of the product.

Open competency
Scope
  • CI/CD and release readiness
  • Observability and production signals
  • Operations without manual rituals
Applied experience
  • Release, diagnostics, and recovery designed as product capabilities.
  • Production signals ready for maintenance without guessing.
05

Cloud Engineer

Choosing cloud, data, and integration foundations so scale, cost, and reliability are not added after the fact.

Open competency
Scope
  • Google Cloud and managed services
  • Data, events, and storage
  • Cost and operational control
Applied experience
  • Cloud choices tied to cost, scale, and data responsibility.
  • Integrations and storage treated as foundations, not add-ons.
06

Security Engineer

Access to content and learner data is controlled at the library and profile level, and the local-first learning model limits what ever needs to reach the cloud in the first place.

Open competency
Scope
  • Controlled content access via library API keys
  • Per-profile isolation of learner progress and preferences
  • Local-first design as a deliberate cloud-exposure reduction
Applied experience
  • Privacy, roles, and auditability built into the product model.
  • Security visible in domain decisions, not only around the UI.
07

AI/ML Engineer

Treating AI as a product capability: with context, constraints, versioned signals, and a clear boundary between facts and interpretation.

Open competency
Scope
  • LLM as a controlled capability
  • Signal and projection quality
  • Responsible product constraints
Applied experience
  • AI constrained by context, signals, and product responsibility.
  • Boundary between facts and interpretation preserved in architecture.

Stack by competency

Tech stack

The stack is grouped by competency so it shows both technology and responsibility: software, leadership, DevOps, cloud, security, and AI.

Software Engineer
  • .NET / ASP.NET Core
  • TypeScript
  • .NET MAUI mobile client
  • Angular web client
  • Domain logic engines
  • PostgreSQL
Tech Lead
  • Domain modeling
  • Offline-first domain model
DevOps Engineer
  • OpenTelemetry
  • Cloud Logging
Cloud Engineer
  • Object storage
Security Engineer
  • Privacy architecture
  • Local-first data minimization
  • Scoped content access control
AI/ML Engineer
  • LLM orchestration
  • AI feedback loops
.NET / ASP.NET Core .NET MAUI mobile client Domain logic engines Domain modeling OpenTelemetry Object storage Local-first data minimization LLM orchestration .NET 8 LLM feedback Angular Scoped API keys per library .NET / ASP.NET Core .NET MAUI mobile client Domain logic engines Domain modeling OpenTelemetry Object storage Local-first data minimization LLM orchestration .NET 8 LLM feedback Angular Scoped API keys per library .NET / ASP.NET Core .NET MAUI mobile client Domain logic engines Domain modeling OpenTelemetry Object storage Local-first data minimization LLM orchestration .NET 8 LLM feedback Angular Scoped API keys per library
TypeScript Angular web client PostgreSQL Offline-first domain model Cloud Logging Privacy architecture Scoped content access control AI feedback loops SRS engine .NET MAUI Local-first sync Per-profile isolation TypeScript Angular web client PostgreSQL Offline-first domain model Cloud Logging Privacy architecture Scoped content access control AI feedback loops SRS engine .NET MAUI Local-first sync Per-profile isolation TypeScript Angular web client PostgreSQL Offline-first domain model Cloud Logging Privacy architecture Scoped content access control AI feedback loops SRS engine .NET MAUI Local-first sync Per-profile isolation