What the first design-partner studio is teaching us

I built the first version of IGNIFY mostly from my own head. I had read enough, talked to enough owners, and run enough spreadsheets to feel like I understood how a class-based studio works. Then I sat down with our first design-partner studio, a music academy, watched the owner run a single Tuesday afternoon, and realized how much I had been guessing.

That afternoon reset the whole project. Not because anything dramatic happened, but because the small, ordinary friction of running a studio turned out to be the actual product. I want to write down what building alongside one real studio has taught me so far, because if you run a studio, I suspect you will recognize yourself in some of it.

One caveat: this is a single studio. I am not going to pretend a sample of one is a trend. But it is real, and it has taught me more than a year of theorizing.

Lesson one: the unglamorous problems are the whole job

I came in excited about the parts of the product that are fun to build. Clean scheduling. A nice family view. The lesson reports I had spent so long thinking about. Those things matter. But they are not what the owner, who I will call Maya, was losing time to every week.

She was losing time to makeups. A kid gets sick, misses a Thursday, and is now owed a lesson. That single fact spawns a chain of work: find an open slot with the right teacher at the right level, make sure the family is not billed twice, and remember weeks later that the debt is still open. My first build treated a makeup as a new booking. Maya treated it as a promise she had made to a family. Watching her track those promises on a notepad next to her keyboard told me my model was wrong.

The other quiet time-sink was families with more than one kid, spread across different classes, teachers, and days, all on one account, one card, one stressed parent trying to keep it straight. I had built around the student. She needed me to build around the family. That sounds obvious written down, but it was not obvious until I watched her toggle between three views to answer one parent's simple question about their week.

None of this is glamorous. No one writes headlines about makeup tracking. But it is the difference between a tool a studio tolerates and one that takes real work off their plate.

Lesson two: "under a minute" is a real spec, not a slogan

The thing I am proudest of is the lesson report, and it is also where Maya pushed back hardest, which I am grateful for.

My early reports were thorough, and I thought thorough meant valuable. Maya read one, paused, and told me she would never send it: not because it was wrong, but because it was long and she has back-to-back lessons. A report that takes five minutes does not get sent on a busy day, which is every day. And the report that never gets sent is worth nothing.

So we set a blunt target together: a teacher should be able to read the draft, change a word if they want, and send it in under a minute. That one constraint changed a lot. It made the reports shorter. It pushed me to draft in the teacher's plainer voice instead of a tidy house style she would have to rewrite, and to build the whole flow so the teacher reviews and approves rather than composes from scratch. "Under a minute" is not marketing language. It is a spec I test against, because Maya showed me anything slower quietly fails.

Lesson three: the hardest part is leaving the old tools

I underestimated how heavy switching is. Maya was not starting from nothing. She had a booking tool, a spreadsheet, a payment app, and a group chat, all duct-taped together, and all holding real information about real families. The fact that her setup was frustrating did not make it easy to leave. It was the system that kept her studio running, flaws and all.

What I learned is that the burden of proof is on me, not her. Every week I ask her to move one more piece of her operation into IGNIFY, that piece has to be clearly better and lose nothing she depends on. So we have moved slowly, one workflow at a time, rather than ask her to leap and watch something break mid-term, when a dropped detail means a confused family and a refund conversation. Switching is not a one-day event. It is a careful migration, and respecting that has made the product more honest.

What "building with, not for" actually looks like

Day to day, this is less romantic than it sounds and better than it sounds. It means I do not ship the feature I find interesting. I ship the thing that unblocked Maya this week. It means a lot of short messages: a screenshot, a "would this have saved you time on Tuesday," a call when I got something wrong. She has real influence over what gets built next, and she has used it to point me at the boring, load-bearing problems again and again.

It also means I am keeping the founding cohort small on purpose. I can only build this closely with a handful of studios at once. Let in too many voices before the core is solid and I will end up building for an average studio that does not exist. Small is not scarcity marketing. It is the only way I know to keep the feedback loop tight enough to matter.

The invitation

So here is the honest pitch, no pressure attached. I am opening a small founding cohort of studios to build IGNIFY alongside. You would get direct access to me and the product, a real say in what ships next, and lifetime founder pricing for trusting an early thing. In return I get what Maya has given me: the truth about how your studio actually runs.

We are pre-launch and intentionally small, so this is not for everyone, and that is fine. But if you are running a class-based studio on a pile of tools that mostly works and quietly drives you a little crazy, and shaping the thing that replaces them sounds good rather than exhausting, I would like to talk. No demo theater, just a conversation about your Tuesday afternoons.