Before ClassQuill existed, it was a tutoring company with a scheduling spreadsheet, a separate invoicing tool, a manual payroll process, and a stack of hand-marked homework on a desk. That company is EquateIt, and the three of us running it — Brandon, Will and Ruchir — were the ones doing the marking, chasing the invoices, and reconciling tutor pay by hand every week.
The operations were a grind, but that wasn't actually the hard problem. The hard problem was that we could tell a parent their child had shown up to a session. We couldn't tell them whether their child was actually learning anything. Attendance isn't a result. We didn't have a way to prove one.
That's the problem ClassQuill was built to solve, and it's also why we built it the way we did.
There's no shortage of software built for tutoring businesses — scheduling and invoicing tools that are genuinely good at scheduling and invoicing. We looked at several. What we found is that they all solved the operations half of the problem and stopped there. None of them touched the part we actually couldn't solve with a spreadsheet: proving a student was improving, not just attending.
So the decision wasn't "buy tutoring software instead of building it." It was narrower and more specific: the ops tools on the market solved a problem we could already solve, badly, ourselves. The problem we couldn't solve at all — a learning platform tutors would actually teach in, with homework that's set once and marked automatically, reviewed by a real tutor — didn't exist as a product we could buy. So we built the platform we wished we had: scheduling, billing and payroll in one place, plus that learning layer, in one login instead of five tools.
Once we'd built it, we didn't sell it. We ran EquateIt on it.
That's still the rule today. ClassQuill is our own reference build — EquateIt runs on the same platform, the same version, that every other tutoring business runs on. Every feature has to earn its place in a real centre, with real tutors, real students and real parents who'd notice if it broke, before it ships to anyone else.
That's not a marketing line, it's an operating constraint, and it changes what actually gets built. It's easy to design a feature that looks complete in a product spec or a demo. It's much harder for that same feature to survive a Tuesday afternoon where three sessions overlap, a parent is asking why an invoice hasn't arrived, and a tutor needs to mark twelve pieces of homework before dinner. Features that only work in the demo version of the world get caught immediately, because we're the ones who'd be stuck using the broken version on Wednesday.
For anyone building vertical SaaS — software for one specific kind of business, not a horizontal tool for everyone — this is the part that's worth stealing, whatever you're building.
A normal SaaS roadmap gets prioritized by what customers ask for, what competitors ship, and what looks good in a sales demo. All three of those are reasonable inputs, and all three can be wrong in the same way: they optimize for what's visible from the outside, not for what actually holds up under real, repeated use.
Running your own business on your own product removes that gap, because you can't fake it to yourself. If a scheduling feature saves fifteen minutes of admin, we feel that fifteen minutes every week, at EquateIt, before a single customer ever sees it. If an auto-marking rule is slightly wrong, we're the ones a tutor complains to. There's no test account standing between the decision and the consequence.
That's the actual argument for dogfooding, and it's stronger than "eat your own dog food, it's good practice." It's this: if you can't point to a real, ongoing business that depends on your product working, you're optimizing for what your product looks like, not what it does. For a niche operational tool — tutoring, or anything else with a specific, unglamorous daily workflow — that gap is exactly where a good demo and a good product part ways.
On scheduling, billing and payroll, ClassQuill is now at parity with the established tutor-management incumbents — multi-tutor scheduling in one calendar, invoices that auto-draft on session completion with Stripe payment links and Xero sync, and tutor payroll through Stripe Connect. None of that was the differentiator, and none of it was meant to be; it needed to be there so the rest of the platform had something to sit on.
The actual difference is the built-in learning platform none of the ops-only tools have: a curriculum-aligned question bank a tutor can assign from in a couple of clicks, an LMS that auto-marks the work the moment it's submitted and lets the tutor add their own review on top, and an AI tutor chatbot students can go to between sessions — not to do their homework for them, but to work through the specific thing they got wrong last time, instead of sitting with it until the next lesson. Results are visible to the tutoring business and the parent throughout. That's the part that answers the question EquateIt actually had — not "did the session happen," but "is this student improving." It's also the part that only exists because a real tutoring company needed it badly enough to build it.
Build on your own version of it first, if you possibly can. Not a sandbox account, not an internal demo — an actual business with actual customers who'd notice if it broke. It's slower, and it means shipping fewer features that only look good in a spec. It also means the features that do ship have already survived contact with reality, because you were the first ones who had to live with them.
If you're curious what came out of running a real tutoring company on our software, you can find ClassQuill at ClassQuill.