They asked for a payment button. We looked at what they actually had.

A music school in Minneapolis came to us with a simple request: add online payments to the website. That's a reasonable thing to want. Most schools do their accounting in some combination of spreadsheets and memory, and online payments feel like the obvious first step toward something better.

We said we'd take a look first.

The school was using an off-the-shelf CRM. The problem with off-the-shelf CRMs is that they're built for an average business, and no actual business is average. This one had been built for something more like a gym or a clinic, where clients come in on fixed schedules and pay regular amounts and don't cancel much. A music school isn't that. Most lessons are private, one-on-one, and the schedule moves constantly: reschedules, extra sessions, cancellations, teacher availability changes. The platform couldn't accommodate any of this gracefully, so the director was doing it all by hand instead.

When we looked at the data the school was keeping in the CRM, we found something worth noting: most of it wasn't useful. There were fields for information nobody ever read, categories that didn't map to how the school actually thought about its students, and structures imported wholesale from whatever template the platform provided. The school wasn't describing itself in its own system. It was describing itself in someone else's system, badly.

The payment button wasn't the problem. The data underneath it was.

We built a CRM on Directus, designed around the school's actual processes rather than the assumptions of a generic appointment platform.

The first decision was what to keep and what to remove. We went through the school's data with the director and mapped what information was actually used: which fields were checked, which reports were run, which numbers mattered at the end of the month. We kept those. Everything else went. The result is a system that describes this school, not a theoretical school that uses the same software category.

The data model is built around three things: students, teachers, and lessons. Payments are tied to specific lessons and specific students. Paid, pending, and overdue statuses are calculated automatically at the end of each period. The number that tells the director whether last month was good or not is there when they open the dashboard, without anyone having to count.

The scheduling system is a weekly calendar with a teacher filter. The director can see the whole school's week at a glance, or filter down to one teacher's day. Adding a lesson, rescheduling one, or marking a cancellation takes two taps. It doesn't require a phone call. It doesn't require the director to be the one who does it.

Three roles, each with their own view of the system. The administrator sees everything: upcoming lessons, pending approvals from parents and teachers, payment alerts, recent activity across both locations. The teacher sees their own day, their student list, and their own availability settings. A teacher who needs to mark themselves unavailable for a day can do that without calling anyone. The parent sees their child's lessons, their payment history, and a three-step booking form. A parent who wants to add a session requests it directly. The request arrives in the administrator's approval queue. Nobody has to send a message.

The booking form is worth describing because it's the piece that changes the most for parents. Pick a child, pick a duration, pick a time. The request goes to the administrator. When it's approved, the lesson appears on the parent's calendar and the teacher's schedule simultaneously. The parent doesn't have to wonder if the message got through.

Payments are linked to lessons from the moment a lesson is created. When a lesson happens, the payment status updates. When a period ends, the total for that period is calculated. The director doesn't tally by hand anymore. The number is there.

The system is built on Directus, which means adding a new field, a new report, or a third location doesn't require switching platforms or calling a developer. The school's processes will change. The system is built to change with them.