← Blog

Creating a tenant is an INSERT

Contents
  1. Three swings at the same problem
  2. The maintenance math
  3. Didn't Studio already teach us SMEs won't self-serve?
  4. What I'm watching

In our old setup, standing up one new customer kicked off a sixteen-step orchestration. A database, a deploy, a repo cloned from the template, an LLM gateway key, a storage bucket, DNS records, a staging environment. Sixteen steps, each one a thing that can fail, each one a thing we own forever.

In Volty, the platform we're building now, creating a tenant is an INSERT statement.

That one-line difference is most of our product strategy for 2026, and it took us three products to earn it.

Studio to Vobase to Volty: who does the adapting, and what scales STUDIO · 2025 SME builds, from a blank canvas died: cold start VOBASE · 2026 we build for them, AI does 80% one deploy per tenant scales with engineers VOLTY · in build SME configures a running product one pooled deploy tenant = INSERT same problem each time: who does the adapting, and what has to scale for growth Studio: the owner (too hard) · Vobase: our engineers (too linear) · Volty: the owner again, but configuring, not building

#Three swings at the same problem

The problem hasn't changed since we started: SMEs in Southeast Asia need software that adapts to how they actually operate, and they won't get it from rigid SaaS or from hiring developers. I've written about why I think that's structural. What's changed, three times now, is our answer to who does the adapting.

Studio was the first answer: give SMEs a no-code builder and let them build it themselves. It didn't work. Owners can't describe an app from a blank canvas. The cold start problem ate us.

Vobase was the second answer: fine, we'll build it for them. An app framework tuned so AI coding agents generate 80% of each build and humans finish the rest. This one worked, in the ways that matter. 100+ SME accounts live, 230K+ AI interactions a day, and agents that learn from staff corrections instead of repeating the same mistake every week.

But it worked in a way that was quietly eating us too.

#The maintenance math

Every Vobase customer is their own deploy. Own database, own repo, own infrastructure, the sixteen steps. That's a fine shape when you have ten customers and you're still finding the product. It's a treadmill when you have dozens and you're still building core features, because every improvement has to be backported across single-tenant deploys one at a time.

The honest version is that Vobase consumed too much of our own dev power. Engineer weeks were going into keeping projects alive rather than making the product better. Growth was linear in engineers, and we want exponential. Those two lines never meet.

So the team made two calls.

First, pooled multi-tenancy. One deploy, every org in the same instance, isolation enforced in the database rather than by infrastructure. Roughly half of our old control plane simply stops needing to exist. The provisioning orchestration, the per-tenant environments, the fleet of deploys to babysit: all of it collapses into a row in a table.

Second, self-serve. Volty is aimed at the smaller end of the market, the businesses that were never going to pay for a bespoke build. They get a working agent-native helpdesk on WhatsApp, and they shape it themselves.

#Didn't Studio already teach us SMEs won't self-serve?

This is the part I had to argue with myself about. Studio died because SMEs wouldn't build. Volty bets they'll configure. From a distance those look like the same bet.

I don't think they are. Studio handed owners a blank canvas and asked them to describe software into existence. Volty hands them something that already works, an inbox with an agent already answering messages, and the shaping is closer to managing a new hire than building an app. Tell it what it's responsible for. Correct it when it gets something wrong. An agent is staff, not magic, and most owners already know how to manage staff.

When Studio failed the lesson I took wasn't "SMEs won't touch software". It was that pointing at something running and saying "this should work differently" is a different cognitive act from describing what should exist. Volty is that lesson productised. Whether it's enough is, genuinely, the open question.

#What I'm watching

Volty hasn't gone live yet. The first customers are being invited onto it as I write this, so this is a strategy post written before the result is in, which feels like the more honest time to write it. Anyone can write the retrospective after.

The thing I'll be watching in the data is whether owners actually shape their agents, or whether our team quietly ends up doing it for them anyway. That was Studio's failure mode and it would be Volty's too, just better disguised. The eval side of my work is what will surface it first: who is proposing the changes to each agent's behaviour, the owner or us.

If the self-serve bet misses, pooled tenancy still pays for itself in maintenance alone. If it lands, the economics of the whole company change shape. Long term the plan is to fold Vobase back into Volty, so the bespoke builds become the top tier of one platform instead of a separate product line we maintain by hand. Too early to say if that's right. Ask me again when the first cohort has been live for a quarter.