The Kula story: how four years of removing friction became Kula Ops

People often ask us how Kula got here. How did a team that started out paying yoga teachers end up building software that a print company and a property developer want to talk to?

This post is our answer. It's the creation and build story of Kula, written down in one place: what we built, what didn't work, what we learned, and how each step became a core part of what Kula is today. We're writing it partly for you, and partly for us, because it's easy to lose the thread when you're building fast.

Fair warning: this is a long one, about a 20-minute read. It covers four years of building, and in the end a lot more than that. Settle in with a coffee, or skim the headings and come back to the parts that matter to you.

It starts with a problem every business has.

It's 2am at a 24-hour gym. A member is standing at the door and their fob won't work. Somewhere, a manager's phone rings and wakes them up. They sort it out, half asleep, then lie awake for an hour.

It's 4pm at a studio. The 6pm class has four bookings. Someone has to decide whether to cancel it. Is it raining? Is it a regular teacher's class? Did three of those four people drive in from an hour away? Nobody has written down the rule because there isn't really one, so the decision lands on whoever is on shift, and it gets made differently every time.

Every business has a hundred of these. They were never worth building software for. They need a bit of judgement, so a simple trigger can't handle them, and fixing them by hand costs too much. So they get treated as a fact of doing business, and they quietly take up the time and headspace of the people who keep the place running.

This is the story of how we ended up building for those people. It took us four years, a payments platform that got shut down, a dashboard nobody needed, and a lot of being wrong about what the real problem was.

But none of it was wasted. Each step built a core part of what became the final product. Looking back, every one of those early builds was doing the same thing: removing a piece of friction that people had learned to live with. That's why they keep coming back.

Every business has a factory

The way most businesses grow hasn't changed much in a century. You sell more, and push more through the factory. When the factory is full, you add capacity: more space, better machines, a faster line. That capacity is easy to measure, so it gets funded.

The factory looks different in every industry. In a gym it's the floor and the membership system. In a pub it's the bar and the kitchen. In a builder it's the site. In a software company it's the product team. In each case it's the high-volume part, with hard data and clear rules, and that's where all the software investment goes.

What nobody adds capacity to is the people around the factory: the managers, the ops team, the front desk, the person who rings the supplier and covers the sick teacher. When the business grows, the plan is to hire more of them and train them up. Their capacity is the real ceiling on growth, and almost nobody measures it.

Look at the tools those people are given. There are general-purpose tools like spreadsheets, documents and email, and there are tools built for the factory, like project management software. None of them is built for the work of managing. The manager is expected to pull it all together and make it work for their own situation, and they become the glue holding the business's systems together.

We didn't start out knowing any of this. We started by fixing the factory, again and again, until we noticed where the pain kept coming from.

Before the beginning: seven days

Phil and I have worked together since 2018. We come at business from opposite ends, and that's most of why this works.

Phil came to studios from economics and derivatives trading, and ran BodyMindLife, a multi-site yoga studio group, for 25 years. He has lived the job this whole story is about: the late calls, the covers, the decisions made on the fly, the jobs that quietly lapse. I've spent more than 30 years building enterprise software, mostly for small businesses.

Phil sells and runs the business, and I build. But we both build. Either of us will put together a proof of concept, and the other pulls it apart to make sure a real business could run on it. People say we're like an old married couple, interrupting each other to make the story better. Nothing is off the table, and every idea in this story has been through both of us.

When you push each other, the result is always better. There's a moment in Bohemian Rhapsody, the Queen film, when Freddie Mercury comes back to the band just before Live Aid. His point is that on his own, nobody pushed back, and that the band made what it made because they pushed each other to make it better. That's how Phil and I work.

When COVID hit, Phil rang me. The studios had to get online or lose $750,000 a month. Seven days later, there were 40 classes a week running online. From there we built an online yoga platform that paid teachers around the world for views of their classes. Later, I rebuilt the studios' software stack off Mindbody, which took system costs from around $4,000 a month to about $500 and roughly halved the payment fees.

That stretch taught us something we've leaned on ever since. When you sit inside a real business, you see problems no vendor ever sees.

2022: the teacher's pay packet

The first problem we went after properly was paying teachers. For studios, it's one of the most stressful, thankless jobs of the week. For teachers, who are mostly contractors, it's worse. They wait to be paid, chase invoices, and lose access to their own records when a studio closes.

So we came at it from a different angle. If a teacher has taught the class, they've earned the money. Why not pay them then and there? We built a real-time payment model on a private stablecoin. It handled more than the payment itself: invoice creation, super, the split payments teachers wanted, and the studio's cash flow. It took a year to build and refine, and it won awards.

Then regulation changed, interest was low, and AI arrived. We shut it down.

It didn't feel like a lesson at the time, but it was the first one. Start with a mundane, painful job that nobody else wants to fix. That's where trust comes from.

The payments work didn't stay shut down, either. Paying people, splitting money and managing cash flow are friction in every business, and contractors feel it most. So we're going back to it: paying contractors as the work is done. Not just teachers this time, but tradies, extras on a film set, and anyone else who does the work and then waits to be paid.

2024: writing down 2030

As we closed the payments work, the first wave of AI was landing. In September 2024 we wrote a thesis on what business would look like in 2030, The Future of Business Transformation. We published it on our old website with a short video. Its core claim was that AI would change how businesses are run, not only what they sell.

Reading it today, most of it has held up. What we got wrong was the order things would happen in.

November 2024: the first agent

Our first real AI build was small. Members pausing and resuming memberships was a heavy, manual, thankless job for the front desk team. Every request needed someone to check the rules, check the history, make a call and update the system.

We built an AI agent to handle it. It took a month, and AI wrote about half the code. The impact was immediate. The task came off the team's plate and stayed off.

That was the moment the journey really started. It wasn't a big platform. It was one annoying job, done properly, that people could feel the difference from.

It also set the pattern every Kula agent still follows. Know the rules, check the history, act, and only ask a person when the call is genuinely unclear.

2025: the dashboard nobody needed

Encouraged, we spent the first half of 2025 on what seemed like the obvious next step: making gym and studio data usable for AI. By month six we had an "Action Board" that showed retention actions, and we demoed it at an industry event.

People loved it. And then they told us the truth. Their real driver was new revenue, and most operators didn't actually know where their business stood.

So we built that next: a whole-of-business snapshot, sold online. Three people bought it.

That was the most useful failure we've had. Operators don't want data. They want to run better. A dashboard is one more thing to look at, for people who already don't have time to look at things.

Even so, both pieces are still in the product. The Action Board's retention signals now drive the at-risk members Kula raises for the team to act on. And the snapshot became the first step of Kula Ops: before Kula does anything, it builds a view of the whole business.

Early 2026: it's a relationship business

In late January 2026, after a long conversation with one of our advisors, we tore up the core and rebuilt it around a simple idea. Gyms and studios aren't transaction businesses that happen to have people in them. They're relationship businesses. Members stay because of teachers, friends, habits and places. Staff stay, or leave, for the same reasons.

We built a context graph that holds the relationships around every person, built on years of real data. Phil and I wrote up the maths behind it in an academic paper on quantifying relational capital. AI's jump in coding ability let us build far faster than we could have a year earlier. We ran it with four studio and gym businesses sharing their data, and built Tribe, the teachers' app, alongside it.

We also learned the hard way why this foundation matters. Point AI at siloed data and it gives you confidently wrong answers. Six systems with six ways of naming the same member don't join up on their own. The data underneath is the product. Everything else sits on top of it.

The job list that told the truth

Around then, Phil pointed AI at BodyMindLife's entire 24-year job history: handover documents, position descriptions, process files. It found 102 recurring management jobs.

Fifty-two kept running. Nine had stopped outright. Seven had run for a while and then quietly lapsed. One never stopped but had stayed broken. The rest couldn't be pinned down from the records. And it happened across six studios and about 20 staff, so headcount wasn't the thing that made the difference.

The jobs that survived all had a forcing function: payroll every fortnight, the Monday sales report, the Friday newsletter. The jobs that lapsed had nothing making them happen. When a manager left, the job often left with her, because a handover document is really just a list of pointers to whoever currently remembers how things work.

That was when the problem came into focus. Management was never a process. It's hundreds of small decisions made in the moment, on whatever information is to hand. "Fixing the process" never sticks, because there wasn't a process there to fix.

AusFit 2026: the brick wall

By August, a pattern was showing up in how people used Kula Intelligence. They weren't asking it for reports. They were using their own AI, through Kula, to get work done.

At AusFit 2026 we saw the rest of the picture. Every vendor on the floor was focused on the factory: bookings, payments, member apps, AI that answers the phone. Nobody was building for the people running the business around it.

We got pushback on "every business is a factory". We still hold that line, because the factory has never been short of software. The work around it has never had any built for it.

Giving the business hands

In September 2026 we changed how Kula Ops works. We'd been thinking of it as a "second brain" for the manager. We moved to a different model: a digital twin of the business, with the ability to act.

Kula Intelligence is the twin. It knows who people are, what's happened, and what's allowed. Kula Ops is the hands. It runs on a phone, voice first, because the people who run these businesses are rarely at a desk. Most of what they ask for is simple organisational stuff. Order more toilet rolls. Remind Jill to check the towel rack every morning. Approve Debbie's cover. Kula checks what was done before, acts within the business's rules, and asks the first time it isn't sure.

It's for the whole team, not just the manager, with access set by role. The 2am door problem is the same pattern. An agent works out what's wrong, takes the action it's allowed to take, handles the intercom if needed, and only wakes someone up when it genuinely can't solve it.

Why not just give everyone a general AI app? Because a general AI app doesn't know who anyone is, what the business has already decided, or what each person is allowed to see and do. Without that, it's the spreadsheet again with another name.

Going back to the stopwatch, without the stopwatch

To work out where the time actually goes, I went back to my own training. I studied production and industrial engineering in New Zealand in the early 1980s, including operations research and time and motion study, and I spent eight years programming CNC lathes. Operations research has mapped how work runs in most industries for more than 100 years. The fundamental rules are well known.

What used to need someone with a clipboard and a stopwatch, AI can now model. We built a digital twin of a five-site, 10,000-member gym: every role, every duty, every system the staff use. Then we mapped where time and stress are lost. Much of it is walking to the desk, to the office, or to find a person, to do something that could be done from a phone. We wrote that up in We Timed the Walk to the Desk.

The model shows about a 12% workload saving for the operations team. We're careful with that number. We aren't going to ask busy people to log their own time; it doesn't work, and it adds to the problem. We judge the real result from how fully a team moves its work into Kula Ops.

A small team that builds like a big one

None of this would have been possible for a team our size even a few years ago.

The payments platform in 2022 took a year, built the old way. The pause/resume agent in November 2024 took a month, with AI writing about half the code. By the time we rebuilt the core in early 2026, AI's jump in coding ability had changed what a small team could take on. AI now does much more of the writing, and my time goes into the shape of the system: the data model, the rules, what each piece is allowed to do, and checking the work.

The way Phil and I work has sped up with it. Either of us can now put together a working proof of concept in days and hand it to the other to stress-test against how a real business runs and where Kula is going. Ideas that would once have sat in a backlog for a quarter now get built, tried, and either kept or thrown away.

It's also how the research gets done. For the gym twin, AI found the studies, built the model and ran the simulations, with me steering. That's the same pattern we're building for managers: AI does the heavy lifting so a person can make the calls.

We run Kula as an AI-native business, with a core team of two and a handful of close collaborators. That isn't a constraint we're working around. It's proof of the thesis. If two people with the right system underneath can build and run all of this, a manager with the right system can run their business with far less friction.

It has also changed what being wrong costs. When building took months, one wrong turn could sink a year. Now we can afford to be wrong, as long as we admit it quickly and let AI help us redo it another way. We build a proof of concept in days. A detailed design document or analysis takes a day. We stress-test it, rebuild the proof of concept the next day, and test it again. AI lets us learn fast, fail fast and find the right path quickly.

We do it that way for our customers. By the time something reaches them, it has already been through the wringer. And shipping isn't the end of it. When feedback comes in, we feed it to the AI and have a new version ready the next day, often within hours.

Over time that loop will get faster still. The real game is software that changes as it's used: the system adjusting to what's happening in the business as the AI learns, but always inside guardrails the business sets.

What the factory frame gets wrong

The natural assumption is that if you free up the managers' time, you use it to push more through the factory. That's the wrong way round.

You don't speed up the line. You free up the people around it, and the line runs better as a result: less downtime, fewer handovers dropped, fewer mistakes. Throughput goes up as a by-product.

Mistakes are where the real money goes. Take building. Studies of residential projects put rework at around 3% to 5% of total project cost. At 5%, that's $20,000 on a $400,000 house, or $2 million across 100 homes. And research consistently points to information as a major cause: miscommunication is linked to about a quarter of all rework, and bad or inaccurate information to another 14% to 22%. That's management capacity showing up as a line item.

The trap of quick wins

Everyone is selling AI quick wins right now. You need them. They're how people come on side. But stopping there is the trap a lot of companies and consultants fall into. You get some nice demos and nothing about how the work gets done really changes.

The real game is rethinking how management work happens. People outside software won't see the 5x to 10x jumps software engineers are seeing. We expect operators to get back somewhere around 10% to 15% of their time, with far less stress, and the headspace to actually make things happen. For a team that has been running flat out for years, that's a big deal.

Here's a simple way to see where Kula fits. Put every management task on two scales: how much judgement it needs, and what it costs to leave it as it is, in stress, mistakes and after-hours calls.

• Low judgement, high cost: traditional software already handles these.
• High judgement, high cost: this is the gap. These are the jobs that were "too expensive to fix" and got accepted as part of business. It's where Kula works.
• High judgement, low cost: these stay with people.
• Low judgement, low cost: not worth worrying about.

Most businesses don't know that second group can be fixed at all.

It was never about fitness

Fitness is where we started and it's still our core. A five-club gym group goes live on Kula Ops this month, the first full gym team to run on it. But the conversations have changed.

Phil leads most of our conversations with businesses, and lately he keeps hearing the same story outside fitness. A 140-person print company came to us with exactly the same problems as a large gym: a building that takes five minutes to walk from end to end, a team losing hours to chasing and fixing, and managers who are the bottleneck to growth. Since then we've been talking to a property developer, where the cost of bad information is measured in rework on every house.

Every one of those conversations comes back to the same thing. Everyone else is going after the services budget. We're going after the management budget, the work of keeping the factory fed, aligned and adjusted, which has always been done by people with no tools built for them.

Nothing was wasted

When we lay the four years side by side, every step is still in there:

• Teacher payments taught us how money moves through a business, and they're coming back as real-time pay for contractors of every kind, from teachers to tradies to film extras.
• The pause/resume agent set the pattern for every agent Kula runs: rules, history, action, and a person only when it's needed.
• The Action Board became the retention signals behind the at-risk members Kula raises each day.
• The whole-of-business snapshot became step one of Kula Ops: see everything before you act.
• The relationship rebuild became Kula Intelligence, the twin that knows who people are and what's allowed.
• Phil's job audit became the loops in Kula Ops: recurring jobs with their own forcing function, so they keep happening when people move on.

At the time, each of these looked like a separate product, and some looked like dead ends. They weren't. Each one took a piece of friction out of how a business runs. Kula Ops is where they finally come together.

What we'd tell anyone starting out

Four years in, this is what we've learned:

1. Fix one painful, mundane job first. The pause/resume agent did more for us than any platform pitch.
2. People don't want data. They want to run better. Build for the action, not the report.
3. The data underneath decides whether AI can be trusted. Get the substrate right before the agents.
4. Jobs without a forcing function lapse. Software that runs on its own schedule keeps them alive when people move on.
5. Management isn't a process. Don't try to fix it like one. Give the people doing it a system that knows the whole picture and can act.
6. Quick wins open the door. Changing how work gets done is the actual job.
7. Nothing built to remove friction is wasted. If it fixed something real, it comes back.
8. Being wrong is cheap if you admit it fast. AI lets us build, test, throw away and rebuild in days, not months.

Same journey, different sides

Looking back at ourselves through this new view of the work, Phil and I both saw something we hadn't expected. We'd been on this journey a lot longer than four years.

For me, it started with the first software I wrote, on an Apple ][+. I was programming CNC lathes, and every toolpath needed complex trigonometry, worked out by hand on a TI programmable calculator. I wrote the software to replace the calculator and do those calculations for me. It was a fix for a piece of friction on the factory floor. I've been doing versions of that ever since: ERP, legal tech, communications and cyber security. Each time I was removing friction where the technology of the day allowed it. AI is the first time I can see how to fix the parts that were always out of reach.

Phil was on the other side of the same problem. For 25 years he was building products for his yoga business, and hiring people as he needed them, always looking for ways to make the business run better. He was living the friction while I was building tools to remove it.

Same journey, from different sides. That's why the two of us can do what we're doing now.

Where that leaves us

We kept being asked to fix the factory. It took us four years to see that the real problem was the people around it, and that nobody had ever built anything for them. That's what we're building now.

It's also why we now say no to factory fixes. The software that runs the factory should do that job. Our job is to make the factory run well, and our pricing is moving to reflect that: part of what we earn is linked to how well the business runs.

And we've built Kula as a repeatable platform, not a bespoke system a consultant builds and walks away from. It grows and develops on its own as it learns each business. Because our revenue is tied to our customers' success, we have every reason to keep improving it and to keep talking to them. If they aren't running well, we earn less.

Every business wants profit, and not for its own sake. Profit is what lets you take risks and grow further in a world that doesn't sit still. Helping businesses get there, by giving the people who run them their time and headspace back, is what Kula is for.