Code push isn't new. React Native developers have shipped over-the-air fixes for years, and Flutter has a serious standalone option today. So when I decided to build it, the honest question wasn't "can this be done" — it was "why build it again, as part of a backend, instead of as its own tool?"
Here's the answer I landed on.
An update isn't an isolated event
The standalone model treats a code update as a self-contained thing: you have a tool, it has a dashboard and a CLI and its own credentials, and its whole job is to get new code onto phones. Clean, focused, does one thing well.
But an update to your app is never actually isolated. Shipping one touches a dozen things that already live somewhere else:
- Which environment is this going to — staging or production?
- Which app version is it compatible with?
- Who's allowed to push to production, and is there a record of who did?
- What do your feature flags say about whether this new behavior is even switched on?
- What are your users doing right now, and does an analytics event tell you the update landed?
Every one of those already lives in your backend. Environments, versions, identity, flags, audit, analytics — that's not code-push stuff, that's backend stuff. And when code push is a separate tool, you end up duplicating all of it: two systems with their own notion of "production," their own list of who can do what, that don't know about each other. You push code in one place and manage the flag that gates it in another, and you're the integration layer holding them together in your head.
When it's one platform
Put code push next to the rest and the seams disappear. The same auth that guards your database guards who can push code. The same environments your data lives in are the environments you push to. The same version enforcement that gates old clients gates which builds an update can target. The same audit trail covers a data change and a code update. A push stops being a separate act in a separate tool and becomes just another thing that happens inside the project you already have.
That's the whole idea. Not more features — less surface area.
The honest version of the pitch
Code push is the wedge. It's the reason to show up, because it's the one primitive you can't get from any other backend right now. But it isn't meant to be the entire relationship. Once your updates flow through Koolbase, having your auth and data there too isn't a lock-in trick — it's just fewer vendors, fewer dashboards, fewer credentials, fewer things wired together with tape.
And the counter-case, because it's real: standalone tools have a genuine advantage. They're focused, and you can adopt one without moving your backend. If you love the backend you're on, bolting a dedicated code-push tool onto it is the lower-friction choice, and I'd tell you to do exactly that.
Koolbase is a bet in the other direction: that mobile developers would rather have one platform that knows about itself than a best-of-breed constellation they have to keep in sync by hand. That's a bet, not a law of nature. But if you've ever felt the tax of stitching five services together just to ship one app, you already know which side of it you're on.