"No-code" sounds effortless. Configure your app in a browser, hit publish, done. And that is exactly how it should feel, for one app, seen from the outside. Keeping thousands of no-code apps alive and published, for years, is another job entirely. This post opens the machine room: hosting, push delivery, store submissions, and the maintenance treadmill running underneath.
Quick context: GoodBarber is a no-code app builder running since 2011. Customers configure an app in a web back office; the platform compiles native builds (Swift for iOS, Kotlin for Android) plus a PWA, and operates everything those apps need at runtime. That last clause is the subject here.
What "at scale" means for a published app
The demo problem and the production problem are different problems. Any stack can produce one app that works today. A published app is a longer commitment: a binary sitting in two stores behind two review processes, a backend it calls every day, push credentials that expire, an OS release every year and store policies that move under your feet.
Scale, in our case, as of mid-2026:
- thousands of live apps in production;
- one download every 4 seconds across the fleet, about 20,000 a day and 8 million a year (measured over 29 days in April 2026);
- paying customers in 152 countries;
- a platform running since 2011, so "long-term" is measured in OS generations, not in sprints.
The operative definition of scale is multiplication. With one app, a store policy change costs you an afternoon. With thousands, every external change becomes a fleet event: whatever Apple or Google decides this quarter, multiply it by every app in production. The entire architecture below exists to make that multiplication survivable.
The infrastructure nobody sees
Hosting. GoodBarber is its own hosting provider. We rent rack space in large European datacenters and run our own machines there: several racks of hardware, not a tenancy on someone's hyperscaler. The backend is multi-tenant: thousands of apps share the platform's services, each with its own content, configuration and API surface, and the CDN in front of it moves several terabytes a day. Running the hardware ourselves keeps the data question short (one company, one jurisdiction, servers in Europe) and puts capacity planning where it belongs: on us, once, instead of on thousands of individual app owners.
Push, at volume. The platform delivers several million push notifications a week. The app owner's view of that sentence: write the message, pick the audience, send now or schedule. Everything else is ours:
- fan-out to APNs and FCM, with per-app credentials provisioned and rotated;
- device-token hygiene: tokens die constantly (uninstalls, device restores, OS reinstalls), so delivery responses have to be consumed and dead tokens pruned, or delivery rates rot silently;
- payload limits, throttling, retries, and the scheduling queue that turns thousands of "send at 9am" campaigns into synchronized bursts of individual deliveries.
Reliable push is a data-hygiene problem at least as much as a throughput problem. The throughput is bursty and predictable; the token decay never stops.
Store submissions, handled by people who do it all day. A dedicated publication team submits and maintains apps in the App Store and Google Play. The baseline that team works against: Apple rejects approximately 42% of first submissions (measured across the submissions our team handled over the last 12 months; that is Apple's baseline, not our failure rate). The team recovers 91% of those first-submission rejections. On updates, upstream prevention work makes rejections rare in the first place. App review is not an API call that returns 200; it is a negotiation with guidelines that shift, and it goes measurably better when it is somebody's full-time job.
The treadmill: what a platform absorbs
An app left alone degrades. Not because its code changes, but because everything around it moves. A sample of what "around it" has meant, with dates:
- Every year: Google Play raises the required target API level. Miss the deadline and you cannot ship updates; fall further behind and the app is hidden from new users.
- April to December 2020: Apple stopped accepting new apps, then updates, still using UIWebView. Every app embedding web content had to move to WKWebView.
- March 2021: APNs dropped its legacy binary protocol. Push senders had to migrate to the HTTP/2-based API or stop delivering.
- July 2022: Google Play's Data safety form became mandatory for every listing.
- May 2024: Apple began enforcing privacy manifests and "required reason" API declarations, including for third-party SDKs.
Add the annual rhythm on top: new iOS and Android majors every fall, Xcode and Gradle toolchains that move, SDKs that deprecate.
On a platform, each of these is absorbed exactly once. The fix lands in the shared codebase, the apps are rebuilt, and the fleet rolls forward through regular app updates. That is also why we advise owners to update regularly even when nothing visible changed: the update is the vehicle that carries those fixes into production, and the stores themselves are hostile to dormant apps (Apple periodically sweeps apps that have not been updated in years; Google buries apps targeting outdated API levels). An app that ships updates stays current, visible and installable. Most of our owners experienced the events above as a release note, if they noticed at all.
The bill, itemized
Strip the platform away and here is what one production app makes you own, permanently:
- one target API level raise per year, so at least one rebuild and resubmission per year;
- OS beta season: test every summer, fix before every fall;
- your dependencies' CVEs, deprecations and license changes;
- push infrastructure: credentials, token hygiene, delivery monitoring;
- store policy watch: new forms, new manifests, new review guidelines;
- monitoring, and someone reachable when it breaks.
None of these is hard in isolation. All of them are permanent, and they compound. What a no-code platform actually sells is not the editor; it is amortization. One team absorbs that list once, and thousands of apps inherit the result with their next update.
Our own receipts are public: an engineer is on call year-round, and the platform status page is at goodbarberstatus.com.
Questions in the comments. happy to go one layer deeper on any of this, from colocation choices to the push pipeline to review stories.