Why we built skeditor: the case against self-booking apps for service businesses

Most scheduling apps got it backwards. They hand the booking link to the customer. That works in an office, where every meeting is interchangeable. It breaks down the moment your day involves a car. Here’s the case for inverting the model, and the paper notebook that started it.

Skeditor started in a kitchen, with a paper notebook.

My partner runs a small business teaching swim lessons. For years the schedule lived in that notebook (names, addresses, cancellations, times), copied each weekend onto the next page. Reminders went out by text, manually, sometime around 9pm the night before. Payments came in by Venmo, cash, and “I’ll get you next time.” Cancellations were bad days. Double-bookings were terrible ones.

I’m a software developer. I kept suggesting tools: Calendly, Acuity, Square Appointments, the usual suspects. None of them stuck.

I assumed at first this was a tool-fit problem. The wrong app for the wrong person. I’d find the right one and convince her to switch. I tried showing her three of them in detail. She tolerated the demos, then went back to the notebook.

Eventually I started to see what was actually going on. It wasn’t a tool-fit problem. It was a model-fit problem.

What every scheduling app assumes

Every popular scheduling app on the market (Calendly, Acuity, Cal.com, Square Appointments, the swim-school-specific ones, all of them) is built on the same foundational assumption:

The customer should be the one booking the appointment.

It’s such a deeply embedded assumption that nobody questions it. The product surface is built around it: a public link, an embeddable widget, a list of available time slots, a click that reserves one.

And it’s a perfectly reasonable assumption when the operator is anchored to a desk. A sales rep at a SaaS company taking back-to-back demo calls. A therapist with one office. A coach booking consults via Zoom. These users’ appointments are interchangeable from a logistics standpoint. Every meeting is at the same place (or no place). All the customer needs to do is pick a time that fits both their schedule and a slot the operator marked free.

Self-service booking, in that world, is a strict win. The customer gets a smooth experience. The operator stops playing email tag. Both sides save time.

The world where this breaks

Here’s the world where the model breaks: the operator’s appointments are NOT interchangeable. They’re anchored to specific physical locations, scattered across a metro area, and the operator is the one driving between them.

Swim instructors. Music teachers. Tutors. Dog groomers. Personal trainers. Anyone who travels to their client’s home (or to a specific pool, or studio, or park) instead of pulling clients into their office.

For these operators, here’s what happens when you put a self-booking link in front of their customers:

• The customer can’t see your route. They open the form, see “Tuesday 2pm” is open, and book it.
• Nobody tells them, because nothing in the booking flow has the information, that you’re finishing a lesson at 1pm across town. Now you’re driving 40 minutes between two appointments that’re each only an hour long. That’s an unpaid hour.
• Nobody tells them that the kid one neighborhood over has a 1:30pm slot you wish you’d sequenced before driving the other way.
• Multiply this across a 10-appointment week and you’re losing somewhere between 3 and 8 hours of unpaid drive time.

Customers don’t do this maliciously. They have no way to know. The app didn’t tell them. The app couldn’t tell them, because the app doesn’t know about routes. It knows about time slots.

What we tried building

The fix, when you see it, isn’t a feature. It’s a structural inversion.

Stop asking customers to pick the time. Let the operator sequence appointments themselves, around the route they’re already planning. Send the customer a confirmation, not a booking form.

That’s the entire idea behind skeditor. We built the simplest possible expression of it:

• You book appointments, in order, on your schedule. Customer addresses live in their profile.
• Between any two back-to-back appointments at different addresses, we show the real drive time. If it’s tight, you see a warning before you commit.
• Customers receive a confirmation email (and a 24-hour reminder the day before) with the lesson time, location, and a one-tap Venmo/Zelle link to pay you.
• Recurring appointments (weekly lessons being the obvious case) are set once. Eight weeks of bookings appear instantly. Cancel a single week without breaking the series.

That’s the whole product. There’s no “public booking page.” There never will be, at least not as the default. Some advanced operators may want to let returning customers self-book (we’re thinking about how to make that route-aware), but the core flow stays: operator sequences, customer confirms.

The argument I expect to push back

Two objections show up consistently when I explain this:

“But what about saving the operator’s time? Self-booking exists because answering ‘when’ emails is annoying.” True. But there’s a third option beyond “customer self-books” and “operator answers every email manually,” and that’s the model skeditor uses. The operator books in a single sitting (15 minutes for an entire week of recurring lessons), then automated confirmations and reminders go out from there. The customer never has to answer “when works for you?” emails because they were never asked the question.

“What if customers want to change their slot?” They reply to the confirmation email. The operator picks a new time that fits the route. This is exactly what already happens in real life. Customers text or email the operator. We’re just not pretending the customer should never have to do this. They were always going to. We just stopped putting the burden of route knowledge on them.

Who this is and isn’t for

Skeditor is built for solo service providers who travel to clients. The specific niches we’ve built landing pages for so far are swim instructors, music teachers, tutors, dog groomers, and personal trainers. But the model applies to anyone running a one-person (or one-and-a-half-person) service business where appointments live at different physical locations.

It is not for:

• Sales teams or anyone running discovery calls (use Calendly).
• Multi-staff studios with shifts and complex availability rules (use Mindbody).
• Anyone who wants their customers to self-book; that’s a different product philosophy.
• Anyone whose primary appointment surface is a public booking page (try Cal.com).

If you fit the “solo, mobile, recurring” pattern though (and you’ve been kludging your way through Google Calendar, Acuity, or a paper notebook), this is the model you’ve been looking for. The thing that finally fits how your business actually runs.

What’s next

We launched skeditor with the basics (recurring scheduling, drive-time alerts, pay links, customer reminders) for $14/month, single tier, no upsells. Pricing exists because we charge for the product, not because we ran out of features for the “Pro” tier.

On the roadmap: a route-aware public booking page for advanced operators who want to let returning customers self-schedule (but only into slots the routing algorithm has approved), mileage tracking for tax purposes, multi-user accounts for two-instructor teams, and direct card processing alongside the existing Venmo/Zelle pay-link flow.

We’re a small operation. We’re going to stay small in scope. The goal isn’t to become the next billion-dollar scheduling SaaS. It’s to be the quiet, dependable tool that lives on your home screen and earns its $14 a month by giving you back your evenings.

If that sounds like the right tool for you, the 14-day trial is the best way to find out. No credit card. Add one only if you decide to keep it.

Signed,
David, founder