ilevar

A language lesson usually lives in pieces: the call in Zoom, the material in a PDF, the quiz in Kahoot, the notes in Notion. Around that sit the problems school owners describe in almost the same words. Teachers spend Sundays building lessons. Rescheduling happens on WhatsApp. Online classes turn into video calls students only watch. Nobody practises between lessons. When a teacher leaves, what the student covered leaves too. And students who cannot see progress cancel.

ilevar started as a marketplace where students found teachers. It is now built for the people who live with these problems: school owners and independent teachers, who need one place to teach and to run the school.

The bet behind ilevar is that AI should do the preparation and a person should do the teaching, and that what connects them is context: the AI works from what this class actually covered. My job is to make that bet usable. I work on it as a UX Engineer, which here means there is no handoff. The person who maps the flow also draws the component, ships it, reads the ticket when it confuses someone, and watches the recording to see why.

1. 01

   Figma

   Tokens, components and full screen patterns, each with its real states: default, empty, saving, error.

2. 02

   Build

   The same structure in code: atoms, molecules, organisms. Dependencies only point downwards.

3. 03

   Code

   Next.js, React and TypeScript in production, including the live classroom and the billing flows.

4. 04

   Support

   An in-product help widget with guides, a changelog and tickets that reach me with context attached.

5. 05

   Experience

   User flows, states and edge cases mapped before screens, and revised with what support and recordings show.

6. 06

   Clarity

   Microsoft Clarity heatmaps and recordings, loaded only after the visitor consents.

Before drawing screens I mapped the product as a single loop seen from two sides. The teacher's path and the student's path only truly meet in one place, the live room, so every other screen is judged by one question: does it get this person into the room prepared, or does it carry something useful out of it?

Mapping it this way exposed where context was being dropped. The lesson summary, the homework and the notebook all sit after the room, and all three are built from what happened inside it. That is why homework is generated from the lesson that just ended and not from a generic bank, and why each lesson becomes a page in the student's notebook that the next teacher can open.

The full map lives in the repository as a document with flowcharts for every role (visitor, student, teacher, school owner, admin), the screen inventory, and a confidence level for each part: what is confirmed by routes and guards, and what still has to be checked in a browser.

A room link gets shared, bookmarked and opened at the wrong time. Most of the experience of a live product is decided in those moments, so I designed the states before the happy path: a lesson is scheduled, live, completed or cancelled, and each visitor to a room link gets an answer that makes sense for where the lesson is and who they are.

The rule behind the table is that nobody lands on a dead end. A finished lesson leads to its summary; a student who is early is told the room is not open yet; someone who does not belong is taken to something that is theirs.

The teacher gives a topic, a level and a duration, and the AI assembles a timed plan. The decision that shaped the screen was what happens next. A generated lesson that goes straight to students would save the most time, and it would also remove the teacher's judgment from the one place it matters. So the result lands as editable steps, each with its type and minutes, under a line that reads "Lesson ready. You review it and decide what stays."

ilevar.com/dashboard/trail

The Figma file is organised the way the product is built: Foundations, Icons, then Atoms, Molecules and Organisms, then Patterns, where components are combined into real screens. The colour collection holds 134 tokens, and every one carries the CSS variable it maps to, so a swatch in Figma and a class in the codebase are the same thing with the same name. Aliases are marked, so it is visible that the focus ring is the primary blue and not a second blue that happens to match.

I keep the file honest by reconciling it against the code, not the other way round. The stylesheet is the source of truth; when the two disagree, the inventory in the repository says which token is real, and the Figma variable is fixed to match. The cover of the file carries the date of the last reconciliation.

Patterns are drawn with their states, not just the happy path. A table has its empty state next to it; a dialog has its saving and error versions. That is what makes the file useful to build from: the awkward cases are already decided.

Open the design system in Figma (opens in a new tab)

In code the system is 32 atoms, 14 molecules and 12 organisms, with one rule about direction: organisms may use molecules, molecules may use atoms, and nothing in those layers imports feature code. The tokens live in a single stylesheet, which is the source of truth for both the app and the Figma file.

The accessibility rules are enforced by tests. Every colour pair the interface renders is checked against WCAG AA, calculated from the real stylesheet. The brand blue, #0563A8, carries white text at 6.26:1 and is dark enough to work as text on a light surface too, so it needs no separate ink token. When a token changes and a pair fails, the fix is to change the token, not to lower the threshold.

32 · 14 · 12

atoms, molecules, organisms

113

design-system assertions in 5 test files

6.26:1

contrast of white on the brand blue

26

end-to-end specs covering the main flows

Teachers and school owners have a help widget inside the product with three things: short guides, a changelog of what shipped, and a ticket form. A ticket goes to one of four queues (technical, pedagogical, financial or feedback) with a severity, and it automatically carries the page the person was on and their browser. I do not have to ask "where were you when it happened?".

Because I am also the one who answers, the ticket and the fix sit with the same person. A confusing screen is something I can redraw and ship, not a request I pass along. The public site makes the same promise to schools: every issue is followed through, and they are told when the fix is live.

Microsoft Clarity runs on the product, loaded only after a visitor accepts analytics in the cookie banner; someone who picks "essential only" is never recorded. In the last 30 days it logged 386 sessions from 77 people, with 6.5 pages and 5.2 active minutes per session. Two of the signals are good news and two are work to do.

clarity.microsoft.com

The same questions were already on my list from mapping the flows, which is what makes the numbers useful. These are the ones I am validating next:

• Whether teachers understand the difference between Library, Lessons and Templates without being told.
• Who confirms a pending booking, and whether both sides can tell pending from confirmed at a glance.
• Whether the single onboarding screen is enough for a new teacher. I built a guided tour and removed it two days later; the question it was answering is still open.
• The full class-group path on mobile: group, members, lesson, attendance, summary.

Framework

Next.js 16 (App Router), React 19, TypeScript

Interface

Tailwind CSS 4, shadcn/ui, Motion

Data

PostgreSQL on Supabase, Prisma, 57 models

Auth

Auth.js (NextAuth v5)

Live video

WebRTC for 1:1, Cloudflare Calls for class groups

AI

OpenRouter for lesson and homework generation

Payments

Stripe: subscriptions, add-ons and Connect payouts

Quality

Vitest and Playwright; 26 end-to-end specs

The repository has more than 2,500 commits and 680 merged pull requests since May 2026. I use Claude Code as a pair for refactors and for keeping token usage consistent across the codebase; the design decisions and the review are mine.