One codebase, 200 separate apps
Onespot builds custom-branded mobile apps for schools. Every school gets its own standalone app in the iOS and Android app stores, complete with its own icon, name, splash screen, bundle identifier, and store listing. Under the hood, all of those apps run on a single React Native and Expo codebase, backed by a single Firebase project.
That shared codebase is a gift for iteration speed. Fix a bug once, and it's fixed everywhere. But it turns a simple question, which app am I deploying to, into a bottleneck the moment you're managing hundreds of them at once.
What deploying used to look like
Before automation, shipping a change to a single app meant updating that app's config files (bundle IDs, slug, credentials), running it locally to confirm nothing was broken, opening a terminal on a personal laptop to run Expo's publish or build command, waiting for it to finish, and, for store builds, uploading the result and submitting it for review. Then doing it again for the next app.
At an estimated 2 to 3 minutes per app for config and kickoff, Onespot's team calculated that rolling out one simple update across 200 apps this way would take on the order of 7 to 10 hours. That's not a workflow a small team, or a solo developer, can sustain every time a fix needs to go out.
Turning "which app" into a data problem
Onespot's fix started with a single JSON registry, apps.json, that acts as the source of truth for everything that varies between builds: names, slugs, bundle identifiers, EAS project IDs, store IDs, backend identifiers, and version numbers. Once that data existed in one place, a Python script (onescript.py) could take an app ID, or a batch of them, and generate every config file a build needs: a standalone config module consumed by app.config.js, an eas.json for CI, an updated google-services.json, an app-images config pointing at the right icon and splash assets, and a .easignore file.
That last file matters more than it sounds. With hundreds of apps' worth of icons and splash assets sitting in one repository, skipping an ignore strategy makes every single build or update slower, since EAS has to sift through assets it will never use.
Because Expo config is just code, Onespot's app.config.js reads whichever app's generated config is active and maps it into standard Expo config fields. Switching which app you're building for becomes a matter of updating one file, standalone/config.js, rather than a manual checklist.
Publishing, building, or submitting from there is a one-line EAS CLI command inside onescript.py, including web builds via expo export --platform web plus a hosting deploy for the apps that also ship as websites.
The implementation
Onespot moved deployments into GitHub Actions, triggered by a repository dispatch that can execute any function inside onescript.py remotely. From there, they added an authenticated /trigger-onescript endpoint to their own API, using GitHub's REST API to kick off that same workflow from anywhere, including from inside their own apps. That opened deployment up to the whole team, not just the people comfortable in a terminal: anyone, including non-developers, could trigger an update, a build, or a store submission without waiting on the CEO.
What one tap looks like now
Sean Cann, Onespot's co-founder and CEO, described the result plainly: he deployed an update to more than 200 web and mobile apps by tapping one button on his phone.
That single tap sits on top of guardrails, not in place of them. Triggering CI is treated as a privileged action, locked behind server-side authentication and never exposed directly to end users. Store submissions and large batch updates still require human review before the workflow proceeds, so speed didn't come at the cost of oversight.
The engineering lesson: deployment is a data problem, not a checklist
Onespot's team frames the shift simply: once which app am I deploying became a data lookup, and how do I deploy became an API call, everything else followed from there. CI stopped being something you babysit and started being infrastructure you trust.
Sources
Automating OTA Updates: How Onespot deploys to 200+ apps without touching a laptop (2026-02-20)
