Jordach MakayaOperations leader · Backend & systems engineeringCasablanca · FR / EN
Back to selected work
Case study · Product design & engineeringCommercial projectIn development

Simuligne

A multi-organisation B2B SaaS in which employees practise professional conversations with an AI-simulated customer, then receive a traceable evaluation against explicit criteria.

My role
Product design and software architecture, end to end.
Target stack
TypeScript strict · Next.js · NestJS · PostgreSQL (RLS) · OpenFGA · Authentik · LiveKit · Stripe
Status
Design phase largely complete. Implementation planning next.
Target screen of Simuligne: live call, adviser view with timer and timestamped transcript
Live call · adviser viewTarget screen · platform in development, not a deployed feature
01 · The problem

Customer advice, service, telesales and insurance all run on conversation, and the skill is built through practice. My operational experience showed how limited the usual options are.

  • Peer role plays tie up trainers, are hard to repeat identically and hard to measure.
  • Evaluation depends on the evaluator, with no explicit criteria or evidence tied to the exchange.
  • Managers lack a structured view of progress by employee, team or site.
  • Training content is rarely versioned or governed.
02 · What I am building

Simuligne lets companies train employees on realistic conversations with AI-simulated customers, assess skills against explicit criteria and track progress within a structured training path. Three engines form the core.

Business scenarios
Structured, versioned training content. A scenario is a validated business object, never a raw prompt.
Voice conversation
Real-time spoken exchange with the simulated customer on an assigned scenario.
Evaluation
Post-call analysis on a grid of observable criteria. Every conclusion points to specific evidence in the transcript.
03 · Eight roles
AdviserTrainerManagerDirectorQuality leadObserverOrganisation adminPlatform super-admin

Each role is limited to its own scope. Observers access through a signed link, without an account.

04 · Typical journey
  1. 01A trainer writes a scenario.
  2. 02A quality lead validates it, and it is assigned to an adviser.
  3. 03The adviser takes up to three successive calls, confirming they have read the report between each one.
  4. 04The report links each criterion to its evidence, and managers track progress.

What I produced

150traced architecture decisions
87screen specifications, for a registry of 92 views
184documented API endpoints across 5 domains
58relational tables, isolated per organisation
53numbered security requirements
7type contracts (TypeScript, Zod validation)

Architecture

Client
Web application
Next.js
→ API
↔ voice runtimes
Backend · NestJS
API /api/v1
Zod contracts
Guard chain
identity → tenant → role & scope → entitlements → action
Async workers
evaluation · imports · outbox
Data
PostgreSQL
RLS per organisation
Convex
live call state
OpenFGA
authorisation projection
Authentik
identity
Real-time voice · VPS
LiveKit Agents
STT → LLM → TTS
Hume EVI
speech-to-speech
Same evidence contract for both. Provider switch by feature flag, frozen for the duration of a call.

Every request passes through the same server-side guard chain. Tenant isolation is enforced by the database, so a forgotten application filter cannot leak data. The LLM proposes, policy decides.

Decisions that shaped the work

  1. 01Make the scenario, not the language model, the centre of the training experience.
  2. 02Keep recordings and transcripts reviewable so coaches can inspect a simulation rather than rely only on a summary.
  3. 03Separate conversation infrastructure from scenario design and training evaluation.

Technical choices

Each choice follows one template: X over Y because requirement R matters more than cost C, to be revisited if assumption A changes.

ChoiceOverReason
TypeScript strict, Zod contracts, no anyJavaScript, loose typesA typed contract supports a developer and an LLM alike, with runtime validation at the boundaries.
PostgreSQL + RLSApplication-level filtering onlyIsolation between organisations is a security invariant, not a convention.
Authentik + OpenFGAIn-house auth and authorisationLib-first: do not reinvent identity or the permission engine. Data ownership is explicit.
Two voice runtimes behind one contractA single providerThe commercial choice depends on a real benchmark. A scenario never depends on a provider.
Stripe, billing module inside the backendBilling microserviceBilling sits on the guard chain's critical path. A remote service would add a network call to every check.
Finite retention of voice dataUnlimited retentionGDPR compliance on sensitive data: audio kept 90 days by default, six months maximum.
Gallery
Target screens · platform in development, not deployed features
01 / 06Live call · adviser view

Live project progress / GitHub milestones

The build, in motion.

A direct view of the project plan. Milestone titles and issue counts come from the private Simuligne repository; only this progress summary is published here.

Loading project progress…

Evidence and references

Project overview
Related work:ShipsetShokunin
Project status and limits

The platform is in development. Do not interpret illustrations, target scoring screens or scenario concepts as evidence of customers, deployed features or training outcomes.

A project worth discussing?

Engineering opportunities, technical collaboration, or a challenging problem worth exploring.

Discuss this work GitHub profile ↗← Back to selected work