I Tried to Build AI-Native Software. I Ended Up Building a Dance Studio Platform.

I didn’t aim to build software for dance studios. My goal was to build an AI-native product from the ground up. I was very interested in it, but I didn’t get what it actually means in practice. I learn mostly by building; I have a visual memory and that helps, so building stuff has been the way I’ve learned over the years.

What does AI-native software actually mean these days? For sure it’s not another ChatGPT wrapper inside another chat window. In my mind it was a system that would predict and understand what the user is trying to achieve. It would understand the core business the software is built for. All of this would happen somewhere behind the scenes and the user should only see the final result, or be helped in the process. The best software should be invisible and take the least time possible while giving you the most value. That is, of course, if you’re not building social media, where the goal is quite the opposite.

Right, so how do you even build such software? First a problem, then a solution people use, then the data they create by using it, and only then AI. How do you replace paper, WhatsApp, Telegram, Excel and Notes while running a dance studio? There are other solutions on the market, some of them quite decent, but none of them has actually looked at the process through the lenses of the dance studio owner, the receptionist, the staff, the dancer and the parent. There are a lot of stakeholders involved and each has their own goals and needs. That’s how Lumo came up. It was a solution to a specific problem.

Now I’ve got the problem, let’s put AI to solve it :)) Not so fast. First we need data, and in order to get data we need to unify all the studio processes, bring them under the same UI, make sure it’s easy enough from a UX perspective, make sure it beats the five tools it replaces, all at once, and finally collect as many data points as you can, so you can actually use AI in a meaningful way.

Before

The first prototype

After

What it became

Cool. One year later, one MVP and one rebuild, I solved that problem. The MVP broke on money. I assumed one dancer means one invoice. In reality one dancer may take multiple classes, some get discounts, some pay in parts, late, or even ahead of time, and one parent may have several children. On top of that, I’ve found so far three different ways a studio is run: class based, membership based, or a combination of the two. None of that fits in one invoice per dancer. This is where the ledger idea came to life and solved all of it. And since I was about to rebuild anyway, I fixed the parts of the UX that were not simple enough, and I realised that if I was going to touch everything I might as well build it to serve many studios from one deployment, in any language and any currency.

Now what? Turns out one dance studio barely scratches the surface, so you need more studios to get enough data for meaningful results. A couple of months later: three different studios, almost 300 dancers, 10k event logs. Still a very small sample, but only now does the AI-native idea start to have a meaning. Now the real work I intended one year ago starts. The first goal is simple: to know when a student will stop coming to classes before the owner realises it.