Billing software for independent tutors — session logging, automatic invoicing, and SMS payment follow-up that runs under the tutor’s own name.
Billing software for independent tutors — session logging, automatic invoicing, and SMS payment follow-up that runs under the tutor’s own name.
I did not set out to build billing software. I set out to understand why every independent tutor I spoke to was doing unpaid administrative work after 9pm, and why none of them had solved it with the tools already sitting on their laptop.
The thing that bothered me was not that invoicing is hard. It is that the tools which claim to solve it solve the wrong half. A spreadsheet will happily produce an invoice. Every invoicing product will produce a nicer one. None of them will send the second message — the awkward one, two weeks later, to the parent of a kid you like and teach every Thursday. That message is the actual work, and it is the part every tool leaves to the person least able to send it.
So the thesis was narrow: the product is not the invoice. The product is the follow-up. Everything else exists to make the follow-up possible without the tutor ever having to author it.
Cheers,
C.D.
A tutor with eleven sessions a month, two rates and one cancelled Tuesday rebuilds the same document from their calendar every single month. Sessions get missed — taught, never written down, never billed, and never noticed.
Four sessions at $60 is $240. One invoice that quietly never gets paid costs more than a year of the software. That figure is what reframed the problem for me: this is not a convenience product, it is a leakage product, and the leak has a number attached to it.
The obvious build is a no-reply payment blast from a company address. It is easier, it is safer, and it would have failed. A parent who gets billing spam from an unfamiliar brand does not pay faster — they ask their tutor what it is.
So every message goes out under the tutor’s own name, in their wording if they change it, and parents can reply to it as a real conversation. That constraint made the messaging layer considerably harder to build and it is the only reason the thing works.
Next.js and Postgres for the app, Stripe Connect for payments, Twilio for the SMS layer. Sessions price themselves from a per-family rate — including travel time, which every competitor treats as unbillable and every tutor treats as work.
Money moves into the tutor’s own Stripe account, not ours. Slate never holds funds and never takes a percentage of tuition — pricing is flat, from $9 a month. That decision cost the obvious revenue model and it is the sentence that closes the most sign-ups.
Slate assumes a tutor teaching recurring students at known rates. Agencies, group classes and one-off workshops are not modelled well, and the cancellation policy engine is deliberately simple — it handles credit-or-waive, not the long tail of real arrangements.
SMS deliverability is the operational risk I am least in control of. Carrier filtering decisions are opaque and a message that silently does not arrive is worse than no reminder at all, because the tutor believes the follow-up happened.
The spreadsheet is free until it isn’t. It will write you a perfect invoice and it has never once chased anybody — and chasing, it turns out, was the whole job.