I'm Building Kalicube Pro the Way I Built UpToTen: One Place for the Data, Built Never to Break, and a Single Source of Breakage When It Does
Published · Written by Jason Barnard
I spent the summer of 2026, July and August, rebuilding Kalicube Pro to be robust, to the standards I'd built the UpToTen and Boowa and Kwala infrastructure to back in the day. While I was doing it, I realized how little we actually had at Kalicube in the way of any kind of system for extracting information from the company: harvesting the information and data our own work produces. That's what I'm building Kalicube Pro towards now, and it's the UpToTen story all over again.
UpToTen served a billion page views in a single year from one centralized system
In 2000 we moved the company from Paris to Mauritius, because everyone was saying you could build the internet from anywhere, and we thought, okay, let's see. By 2007 UpToTen, the children's site where I was the voice of Boowa the blue dog, had 60 million visits and a billion page views in a single year, built with 2000-era infrastructure on an island, and all of it ran from one place: one system, one set of games, one way of doing things.
Boowa and Kwala's games never broke, because I spent years and nights making sure they wouldn't
We set out to make Boowa and Kwala games that never broke. Working out how took years and nights and obsessive work, and UpToTen's output was bug-free. That same obsession is what later drove me to solve Google, and it's what I brought back to Kalicube Pro this summer.
"I don't care what your system is, as long as you have a system" is the rule I learned in Mauritius
In Mauritius I had employees who did everything ad hoc, and I told them: "I don't care what your system is as long as you have a system. If it's a rubbish system, at least when we need to correct it we can correct it en masse." I call that a single source of breakage: when something goes wrong, it goes wrong in one place, and you fix it once for everybody.
Kalicube runs on the same flywheel I'm building Kalicube Pro for: fulfill, harvest, convince, and back to fulfill
Kalicube fulfills for clients, harvests what that work proved, and convinces search engines, AI assistants and agents that we're the best solution to their users' problem, and they send us the next client. I've written about that cycle in The Kalicube Flywheel.
I'm building Kalicube Pro to do for every business what I'm doing for mine. Most business owners who build their own AI system, inside and outside the business, will find they're maintaining a whole system they aren't qualified to run, when their time is better spent running the business and finding clients.
My team weren't following my AI, so I decided to centralize all of Kalicube's data in Kalicube Pro
I made the decision to implement AI a long time ago, and I've been doing it for two or three years now. Then I realized my team weren't following. So I've made a new decision: centralize all the data in Kalicube Pro, and get everybody using the same agents, agents I can build and they can help improve. With one central source of data, people and AI stop contradicting each other across the business. That's the one decision that's going to define this business: it won't make the flywheel run in and of itself, but it builds the system that's going to allow the flywheel.
I describe Kalicube as a wedding cake made of lots and lots of cupcakes, all connected. Everybody's job is a cupcake, every project is a cupcake, and the problems live between them: the cross-cupcake communication, the conflicts and the contradictions. Centralizing the data and the agents is how the cupcakes start talking to each other. The bit I love is that Kalicube Pro is itself a cupcake in the Kalicube wedding cake, and it's going to be the cupcake that runs the wedding cake, which is deeply, deeply delightful.