All work

Light — my own product, 2019–2022

A calendar for
private tutors


Light keeps a private tutor’s schedule and payments in one place. I co-founded it, designed it and ran it as a series of experiments.

Product co-founder — two of us: we shaped the product together; my co-founder led engineering, I led design, growth and the experiments.

Product
Schedule + payments
Users
4,000+ paying users daily use, 6+ months
Role
Co-founder product, analytics, growth
Constraint
No outside money

The 10-second version

It was 2019, early in my career. I’d worked on established products and wanted to know what it takes to build one from zero. So I built one. On a tiny budget Light reached thousands of paying tutors who used it daily for at least half a year. We worked in fast iterations and let the numbers decide what to build next.

Light App Store panel showing schedule and payment tracking. Light App Store panel showing how to add lessons. Light App Store panel showing income planning. Light App Store panel showing payment balances.
The App Store listing, as it shipped.
01Discovery

Finding the tutor problem

The problem

An average tutor has up to 20 students

  1. 01 Irregular payments

    Lessons run week after week while payments arrive in uneven blocks: a large one upfront, nothing for weeks, then a catch-up. MONEY IN LESSONS GIVEN, WEEK BY WEEK PAID AHEAD PART CATCH-UP

    Students pay in chunks: a block upfront, then a catch-up after missed lessons. It is hard to know what has actually been paid.

  2. 02 Constant churn

    Each student is a bar over the year: some stop early, some join late, so the client base never stays the same. ONE STUDENT, ONE BAR STOPS JOINS STOPS JOINS

    Some students enrol while others stop, so the client base is always shifting.

  3. 03 No clear income

    Four months of earnings, each a different height, with no reliable figure to plan against. WHAT I EARN IN A MONTH ? SEPOCTNOVDEC

    Tutors can’t say with confidence what they earn, which makes planning their finances close to guesswork.

Research

Fifty emails, then fifteen interviews

I quickly built a simple landing page, ran cheap ads at it, and collected 50 emails from tutors who wanted the thing to exist. Then I ran 15 interviews, mapping how they actually work and how they feel about the money side of it.

The problem held up. Every tutor described the same mess in slightly different words, and none of them had solved it.

Research synthesis

Three tutor personas

  • Vicky Beginner tutor

    A student who tutors part-time: 4–6 lessons a week, 2–3 students. She keeps no records and relies on memory. Students sometimes pay ahead, sometimes owe her lessons, and after a lesson they ask how much is left. She pays for apps that clearly help, and has two or three subscriptions running.

    Does

    • Tries to remember the schedule and who has paid.
    • Puts lessons in her calendar along with everything else.
    • Digs through chat history and her banking app when a student asks.
  • Maria Part-time tutor

    Around eight students and other income besides. She expects students to keep track of their own payments, so she doesn’t worry about it much; the tutoring money blends into everything else she earns. Her schedule lives in a free calendar app, one colour per student.

    Does

    • Runs the schedule in a colour-coded calendar app.
    • Leaves the counting of lessons to the students.
    • Checks the banking app when something doesn’t add up.
  • Michael Professional tutor

    Five-plus years in, and his students refer their friends. He tried Excel and calendar apps to keep track of who had paid, found them too much hassle, and went back to a notebook where everything is visible at once. Money arrives unevenly: some pay ahead, others fall behind, so his savings are hard to plan.

    Does

    • Writes schedule and payments into a paper notebook.
    • Sits down every so often to add up the month.
    • Tried the spreadsheet route and abandoned it.
02MVP

Building in weeks

A clickable prototype in front of tutors in the first week; an MVP they used every day, bugs and all, within three weeks. This was 2019 — years before AI assistance made that pace ordinary.

The solution

Schedule and payments, together

The whole product was one idea: schedule and payments together. Add your lessons, forecast income, track what each student has paid — in a single, light app.

Light interaction model for adding lessons.
01 Add lessons
Light interaction model for forecasting weekly income.
02 Forecast income
Light interaction model for tracking student payment balances.
03 Track payments
From the landing page.
The constraints

Build only what daily use could prove

We held to three principles: simplicity (bright, light, minimal), speed of development (with few resources, build only what’s necessary), and constant contact with users (surveys, interviews, a community).

Speed meant something specific here: every screen was designed and coded from scratch, and a feature cost weeks rather than hours. Early ads confirmed the interest. Tutors wrote back that this was exactly what they’d been looking for.

The launch

How the launch landed

3 weeks

From idea to an MVP tutors used daily.

48%

Install → activation (10 lessons added), first phase.

41%

7-day retention, first phase.

03Experiments

Turning it into experiments

The app had been free. To see if tutors would pay, we added a subscription: $1.50/mo or $12/yr, with a free month. From there we moved in quick, measured iterations — each experiment aimed at the next bottleneck in the launch metrics, and later at the price itself.

Experiment 01

Onboarding

18%started a trial

The subscription was two weeks old.

It was the biggest lever in the funnel we could pull.

Original onboarding opening screen.
Original onboarding explaining the calendar.
Original onboarding explaining client balances.
Original subscription screen with the trial details in dense copy.
Where the old flow lands: the Calendar tab, an empty week.
Redesigned onboarding opening with the product promise.
Redesigned onboarding connecting schedule and payments.
Redesigned onboarding naming what is paid ahead.
Redesigned trial screen with the cancellation rule in one line.
Redesigned paywall with plans and the free month.

The onboarding at that point

It had been built to walk a demo group through the interface. The subscription shipped after it, and nobody touched it.

Whatever the channel was bringing in, it was mostly tutors. On that base, 18% looked low.

I thought we would get to 50%. I have always been an optimist about numbers — bad for forecasts, good for actually building things.

Install → trial

60–70%of installs used the app before the subscription existed

18%started a trial at launch

22%the baseline by the time the redesign was measured

Three hypotheses about the drop-off

  1. Trial value. A month with Light is worth having on its own. Show what the product is good for, not what it does.
  2. Understanding the trial. People don’t know they can cancel and still use the month to the end. Say it plainly: it’s paid, the first month is free, cancelling is one line.
  3. Jobs, not features. What if we stop explaining how to use it and say what it’s for?

What the flow was actually selling

Not a feature list. What it is like to run your week this way for a month: the schedule and the money in one place, and less to keep track of.

Its goal was the other one: not how the app works, but what it is worth.

Install → trial

22% 30%

Eight points. The next bottleneck was activation.

Try a month of not keeping it in your head.

The promise, as bulletsinstalls

How the calendar works

How balances work

The decision18% started a trial

Where the flow lands

Opens with what a tutor gets, not what the app has

Your week, and what it has earned

Who owes you, and what is already paid ahead

Experiment 01

Onboarding

18%started a trial

The subscription was two weeks old. It was the biggest lever in the funnel we could pull.

It had been built to walk a demo group through the interface. The subscription shipped after it, and nobody touched it. Whatever the channel was bringing in, it was mostly tutors — on that base, 18% looked low. I thought we would get to 50%. I have always been an optimist about numbers: bad for forecasts, good for actually building things.

60–70%

of installs used the app before the subscription existed.

18%

started a trial at launch.

22%

the baseline by the time the redesign was measured.

The promise, as bullets installs
How the calendar works
How balances work
The decision 18% started a trial
Where the flow lands

Three hypotheses about the drop-off

  1. 01

    Trial value. A month with Light is worth having on its own. Show what the product is good for, not what it does.

  2. 02

    Understanding the trial. People don’t know they can cancel and still use the month to the end. Say it plainly: it’s paid, the first month is free, cancelling is one line.

  3. 03

    Jobs, not features. What if we stop explaining how to use it and say what it’s for?

Opens with what a tutor gets, not what the app has
Your week, and what it has earned
Who owes you, and what is already paid ahead

What the flow was actually selling

Not a feature list. What it is like to run your week this way for a month: the schedule and the money in one place, and less to keep track of.

Its goal was the other one: not how the app works, but what it is worth.

Install → trial

22% 30%

Eight points. The next bottleneck was activation.

Try a month of not keeping it in your head.

Experiment 02

The next bottleneck was activation

We later doubled the price and install-to-trial settled around 25%. Still healthy, so I turned to activation. I found the “aha” moment was creating 10 lessons: after that, about 70% of users subscribe. The question was how to get more people there cheaply.

I interviewed community members about their first-use experience, then built a simple web guide and added an in-app modal linking to it. The guide's job was narrow: push toward those first 10 lessons, with real examples of how good it feels once Light is actually set up.

10 lessons

The “aha” moment: reach it, and ~70% subscribe.

45% → 52%

Trial → activation, after the modal and the guide.

~45%

of people who saw the modal opened the guide.

Light in-app modal inviting a new user to open the setup guide.
Top of the plain-language Light setup guide. Continuation of the Light setup guide with practical examples.
04Outcome

Growing, then stopping

Community-led acquisition

The channel

The community became the channel

I built an Instagram community for tutors and worked out the content categories together with them. The bet was that tutors would help make the content, and they did: in “Light Stories” they told how they started tutoring, or how they work with children and with adult students.

The community opened the door to tutor influencers. And it worked in the off-season: tutoring goes quiet in July and August, so we acquired users then and activated them in September, when everyone comes back.

Instagram post explaining the colour-coding feature in Light. Light Stories post: a tutor on impostor syndrome. Light Stories post: how I started using Light. Community post: how to motivate students. Community post: how tutors can save money.
From the Light Instagram.
The outcome

A real product, a small market

The market was too small for the business model we wanted, and it was hard to make it attractive to investors. So we tested three pivots: getting into the tutoring-platform market next to Preply, selling something to students, and translating the app to run experiments in other countries. None of them reached sustainable numbers.

I made about 10 pitch decks along the way, and we passed the first selection round at the Ukrainian Startup Fund. Then the war began. We stopped working in the Russian market, the Ukrainian one shrank, and we chose to wind down active work.