For years, ZeltaCode had a good answer when clients needed a mobile app: Siberian CMS.
We weren’t just users of it — we were part of the ecosystem. ZeltaCode built custom Siberian modules (including modules like E-Sign, distributed through the Siberian marketplace), delivered white-label apps on the platform, and served clients who needed mobile apps at budgets custom development could never touch. Siberian gave a small London agency the ability to say yes to app projects, and we’re genuinely grateful for what that ecosystem made possible.
The wall we hit
But by 2024–2025, we were spending more and more of our time fighting the platform instead of building on it.
Siberian’s foundation is a previous generation of hybrid app technology — a Cordova-based stack from an era when webview apps were the standard. That aging foundation created two problems that got worse every year:
- Apple kept raising the bar, and the stack struggled to follow. Through 2024 and 2025, Apple’s evolving App Store requirements — newer SDK minimums, privacy rules, tighter review of hybrid apps — became increasingly difficult to satisfy on the old stack. Client app submissions that used to be routine turned into unpredictable battles, and we depended on platform release cycles we didn’t control to fix them.
- Modern app expectations outgrew the technology. Clients compared their apps to the apps they used every day. Matching that experience on a legacy hybrid foundation meant workarounds on top of workarounds.
The pressure became practical, not philosophical: to keep delivering apps that reliably passed review and felt genuinely native, we had to start building them manually in Flutter. And we did — we delivered many client apps that way. The apps were excellent. The economics were not: every manual Flutter build meant weeks of work per client, and we were back to the custom-development cost problem that platforms like Siberian had originally solved.
We didn’t want to abandon the platform model. We wanted the platform model on a modern native stack — and that tool didn’t exist.
Building the tool we needed
So we built it. The concept was direct: keep the CMS-driven, module-based discipline we knew from years in the Siberian ecosystem, but put it on a Flutter engine — one codebase producing genuinely native iOS and Android apps, with content, modules, and branding configured per client rather than re-developed per client.
The first version was rough and entirely for our own use. But it changed our agency economics immediately. Apps that had become weeks of manual Flutter work became deliverables we could scope in days — and they moved through app store review cleanly, because the output was native from the ground up. Modules we built once — menus, booking, push notifications, loyalty cards, document vaults — became reusable across clients in completely different industries.
Key takeaway: one native Flutter engine, modules built once, reused across every client industry — that’s what changed the economics.
One of the earliest real deployments was TruckerConnect, a logistics app — followed by booking and media apps for other clients. Different industries, same engine, same dashboard. That was the moment we realised the internal tool had become the product.
In 2025 we productised it as AppMinCMS — a no-code mobile app builder and CMS where businesses, agencies, and resellers build native iOS and Android apps from modular building blocks: e-commerce, appointments, radio streaming, events, document vaults, and a growing module library.
What we deliberately did differently
Because AppMinCMS was born inside an agency that had spent years building on someone else’s platform, some decisions were non-negotiable for us:
A modern native stack we control
Flutter output, kept current with Apple’s and Google’s requirements as a first-class priority — because we know exactly what it costs an agency when a platform falls behind the app stores.
Account-level economics, not per-app punishment
Agencies manage many apps; the pricing had to make a ten-client book viable from early on, not only after scale.
White-label all the way down
Not just the client’s app — the dashboard, the brand, the whole delivery experience. That became the white-label app builder side of the platform, which today is how other agencies and resellers use AppMinCMS under their own name, at their own prices.
One platform, every vertical
The same account that runs a restaurant client runs a salon, a gym, a radio station. Module composition, not separate products.
Honest stage, honest claims
AppMinCMS is a young platform. We’d rather grow with a smaller number of well-supported agencies and founding resellers than pretend to be something we’re not yet. That’s the same principle we’ve run ZeltaCode on for years.
What this means for ZeltaCode clients
ZeltaCode continues as a development agency — custom work is still what we love. But when a client’s app need fits the platform, we now deliver in days what used to be an impossible quote, and the client keeps a system they can update themselves without calling us for every text change.
And when other agencies ask us how we handle mobile — which happens more and more — we finally have a better answer than “with difficulty.”