Building and running 1,000 custom apps: Technical lessons from “How to build and maintain 1.000 Apps” by Michael Schöndorfer (hello again GmbH)

The challenge: hundreds of tailor-made apps, one scalable platform

At DevJobs.at we sat in on “How to build and maintain 1.000 Apps” by Michael Schöndorfer, CTO at hello again GmbH. The team is “pretty much halfway through” their 1,000-app goal—and already eyeing the next milestone. The premise is bold: deliver and operate hundreds to a thousand separate customer apps, each customized, powered by a common architecture and codebase.

hello again’s product is customer loyalty—often in the form of a branded mobile app with point systems and gamification. A defining decision sets their approach apart: “every client gets their own customized solution.” There is no single mega app where all data is shared. Instead, each brand, retailer, service provider, or city gets its own community, with data remaining in the client’s hands.

Customers span retail and online stores, the service sector (a clear example in the talk: hairdressers), and even economic regions such as cities. Community sizes range widely—from a few thousand to a few million users. For engineering, that means features built for a small community must also be robust enough to run under millions of users without rework.

Product scope: loyalty mechanics, feedback, integrations, messaging, analytics

The app feature set is extensive:

• User management
• Loyalty mechanics with gamification (e.g., points for purchases, redeeming rewards)
• Feedback via polls, ratings, forms; optional chat
• Integrations with third-party services (e.g., booking tools for hairdressers)
• Sharing features (e.g., Facebook, WhatsApp)
• Payments
• Messaging for push and email, including automated actions (e.g., birthday points + push notification)
• Analytics and reporting

Beyond building the mobile app(s) and a trimmed-down web app, hello again handles testing, per-app App Store release management, and provides a CRM for customer teams—including marketing automation and a statistics dashboard. They also develop the server, manage the infrastructure, and take care of maintenance. It’s a full-stack, operations-included approach—and it raises the complexity bar substantially.

Engineering reality: update blast radius, complexity management, regressions

The multi-app setup produces a particular set of pains:

• Many individual apps must be updated and submitted to app stores.
• Complexity scales with feature breadth, industry diversity, and customer sizes.
• Regressions lurk: a change for one app can ripple into others.
• Optimizations must serve small and very large communities with the same code path.

All of this calls for a crisp architecture, rigorous automation, and well-thought-out testing.

Architecture: multi-tenant backend and a modular app platform

At the center sits the hello again server. Multiple instances run in a multi-tenant setup, so one backend stack serves many clients. Scaling is straightforward—especially for peak events like Cyber Monday or Black Shopping Week—leveraging Google Cloud services to scale automatically.

The system plugs into communication gateways (email, push, and customer-specific services), provides the dashboard for client teams, and powers the customer-facing frontends: standalone mobile apps for each client and a trimmed-down web app. The result is a platform that scales centrally while shipping highly individualized frontends per brand.

Strategy to scale: multi-tenant core, modular apps, JavaScript-first, heavy automation

How do you build that many customized apps “without 10,000 developers”? Schöndorfer highlighted several decisions:

• Multi-tenant server over per-customer instances: one backend update ships to all. The downside: any server release affects every app—so you need lots of automated tests, and “we can’t have any downtime.”
• No on-premise: the platform is not hosted on customer infrastructure. That reduces variation and simplifies releases—but requires saying no when on-prem is requested.
• Modularized app system: a core framework plus extensions and configurations produce just the app a client needs—no more, no less.
• React Native: one codebase for iOS and Android. The team leans into JavaScript to let developers move easily between components.
• Automation and continuous delivery: from project setup to build pipelines and store submissions, as much as possible is automated.
• App builder: an internal tool to assemble app solutions “without having to code a single line”—usable by non-developers in project management.
• CodePush: JavaScript-only updates can bypass the app stores to accelerate fixes and iteration.
• Easy integrations: via webhooks, very client-specific requirements can be outsourced to partners or customers while staying cleanly integrated into the platform.

Put together, these decisions enable a product platform that can produce many independent, high-quality apps without linear growth in engineering headcount.

The modular app framework

hello again structures mobile apps with a base framework, a layer of extensions, and configurations on top.

Base and extensions

• App framework: the foundation shared by every app.
• Extensions: feature modules to include as needed per app.
• Almost always: authentication.
• Very often: loyalty.
• Optional: chat, other features, and fully client-specific code as isolated extensions.

Client-specific extensions “should not interfere with any other code.” That isolation is how the team avoids collateral damage and keeps the platform maintainable as features multiply.

Configuration over forks

A strong configuration layer shapes extension behavior without forking code. For instance, authentication can look very different: choose email/password or phone number login as the situation demands—purely via config.

Internal contracts enforced by Redux

Internally, extensions communicate through Redux. As Schöndorfer put it, this “forces us to have very good internal APIs.” Extensions can:

• Provide screens
• Expose Redux actions
• Bundle native/React Native dependencies
• Listen to events and trigger generic or customer-specific actions

Dependencies are strictly modularized. Example: the Facebook SDK is only bundled if a client actually needs Facebook login. If not, it remains out of the build—reducing app size and keeping dependency trees clean.

Build only what you need

At build time, the system fetches the list of required extensions and their configurations, then produces a build that contains only what’s necessary. The result is an app that’s optimized in both code and size and free of unrelated client-specific branches.

Configuration layers: build-time, runtime, dynamic content

Schöndorfer distinguishes between several configuration levels:

• Build-time (baked into the app):
• Navigation structure
• Theming
• Startup/splash screen
• Runtime (server):
• Points awarded for registration
• Number of check-ins required to complete a challenge
• Runtime (app/UI):
• Text and number of tutorial slides (or none)
• Maintenance mode
• Fields included in the sign-up process
• Dynamic content:
• Rewards, news, articles, events

Every app is fully translatable, which further individualizes the experience per customer without diverging the codebase.

Release and testing: automate the pain points

One of the talk’s central lines:

hello again’s approach is pragmatic and end-to-end.

App store reality: 2FA, licenses, manual steps

A concrete example: every few months, Apple requires accepting updated license agreements—guarded by two-factor authentication tied to the customer’s account. “We would have to call the client every time.” The team built a system with physical phones that receive the 2FA calls and perform manual labor steps automatically. It’s not glamorous work, but at scale it’s invaluable.

Customer-friendly test channels

• Firebase App Distribution lets customers test pre-release builds.
• If a customer lacks a device (e.g., only has iPhone, no Android), a built-in app simulator in the dashboard allows testing the latest app version right there.

Automation for combinatorial app variants

The team is investing “heavily” into an app automation framework tailored to their needs, so they can automatically test the many variations of their apps. On top, “high code coverage” is a priority, enabling server releases without exhaustive manual testing.

Security: regular external penetration tests

Given the variety of use cases, “you cannot think of every scenario on your own.” Regular external penetration tests help uncover backdoors and harden the system—particularly important in a multi-tenant, integration-rich platform.

Managing third-party dependencies

There’s no escaping external changes. If “Google says a certain SDK version is required now,” every app must be updated—in short order. The architecture helps, but the obligation remains: “we have to update every app.”

Trade-offs: the discipline to say no

Scaling a platform this way has costs:

• Even small changes can be hard to implement—sometimes “it forces you to say no.”
• Complexity grows exponentially; every change must be considered for cross-app effects.
• Despite automation, each app still needs to be updated individually; some setup tasks remain.

There’s clear-eyed honesty here: scalability isn’t a shortcut; it’s a commitment to discipline across product and engineering.

Strengths: JavaScript-only frontend, one server, shared improvements

The benefits are equally clear:

• “We don’t need any native developer.” The entire frontend is JavaScript-only (React Native).
• “No need to run several different instances of the server.” One multi-tenant backend, updated centrally, with better resource sharing.
• Per-app builds are code- and size-optimized by bundling only needed extensions.
• Any bug fix or improvement in one app “benefits all other apps.”
• Clear internal APIs become a necessity—and that leads to better architecture and long-run maintainability.

In short, platform thinking pays off if you modularize aggressively and test extensively.

Practical guardrails for engineering teams

From the session, we pulled a set of principles that are broadly applicable:

1. Treat multi-tenant as a first-class constraint

• Design for zero downtime.
• Make automated tests the release gate for changes that hit all tenants.
• Keep client-specific logic strictly separated in extensions.

1. Modularize down to dependencies

• Only ship third-party SDKs with apps that actually need them.
• Isolate client-specific code to avoid cross-coupling.

1. Prefer configuration over code

• Separate build-time and runtime configuration.
• Move as much app behavior as possible into server/runtime config.
• Model dynamic content as its own layer.

1. Automate where it hurts

• Accept that “automation is hard,” and invest where the repeat pain is highest (App Store flows, 2FA chains, distribution channels).
• Provide customer-friendly testing paths (Firebase App Distribution, dashboard simulator).
• Aim for high code coverage to enable frequent server updates without manual regression sweeps.

1. Manage third-party constraints deliberately

• Anticipate SDK deadlines and plan mass updates.
• Keep the architecture friendly to sweeping, repeated updates.

1. Take security seriously, from the outside in

• Bake regular external penetration tests into your lifecycle.

1. Product discipline matters

• Be ready to say no. Guardrails protect the platform from erosion.
• Make complexity and trade-offs transparent internally and to customers.

Platform components at a glance

Summarizing the pieces named in the talk:

• Mobile apps: one per client, modularly built, React Native, JavaScript-only, with optional extensions (authentication, loyalty, chat, and more).
• Web app: a trimmed-down frontend variant.
• Multi-tenant server: scales via Google Cloud, integrates communication gateways.
• CRM and dashboard: user management, marketing automation, statistics/reporting; includes an app simulator for testing.
• Messaging: push and email, including automated actions (e.g., birthday points with push notification).
• Integrations: booking tools, social sharing (Facebook, WhatsApp), payments; extensible via webhooks.
• App builder: a no-/low-code tool enabling project managers to assemble app variants.
• Delivery pipeline: continuous delivery, CodePush for JavaScript-only updates, App Store release management (including 2FA automation via physical phones).
• Test infrastructure: Firebase App Distribution, a custom app automation framework in the works, high automated test coverage, regular external pen tests.

What stood out to us

• “Every client gets their own customized solution”—this is the foundational product choice. It preserves data ownership and brand communities but raises the engineering stakes. hello again meets that with a highly configurable, modular system and serious automation.
• Redux as an internal communication layer enforces clean APIs between extensions—a winning pattern for large multi-app setups.
• The team invests in unglamorous but high-leverage automation (App Store 2FA, license acceptances). These are the friction points that don’t scale manually.
• Clear separation of build-time, runtime, and dynamic configuration enables change without roundtripping through App Store releases.
• A multi-tenant server plus CodePush enables fast global rollouts—backed by testing rigor.

Conclusion: A resilient pattern for scalable B2B app platforms

“How to build and maintain 1.000 Apps” lays out a pattern relevant to many platform teams: a modularized frontend, a multi-tenant backend, strong configurability, and aggressive automation across build and release. It comes with conscious product boundaries (no on-prem) that keep the platform coherent.

Schöndorfer’s straight lines—“automation is hard,” “we can’t have any downtime,” “we have to update every app”—aren’t disclaimers; they’re operating principles. Embrace them, and you can turn one platform into hundreds of high-quality, individualized products—stable, repeatable, and improving with each bugfix.

A note on hiring from the session

Michael Schöndorfer closed with a call for talent: hello again GmbH is hiring—team leads for server and frontend development, backend developers with Python, and frontend developers skilled in JavaScript, React Native, and Vue.js. If the principles above resonate, you’ll likely find the right kind of scale challenges there.

• 

  

  Integrating hundreds of different systems

  Markus Gasplmayr von hello again zeigt in seinem devjobs.at TechTalk den Weg, wie das Devteam hunderte verschiedene Systeme in die eigene Loyalty Solution integriert hat.

  Watch now

• 

  

  Sebastian Auberger, CIO bei hello again

  Der CIO bei hello again Sebastian Auberger redet im Interview darüber, was neue Devs erwartet – aus technologischer und aus persönlicher Perspektive – und welche Möglichkeiten zur Weiterentwicklung es gibt.

  Watch now

• 

  

  Malith Thilakarathne, Mobile Developer bei hello again

  Mobile Developer bei hello again Malith Thilakarathne erzählt im Interview über seinen Einstieg in das Entwickeln von Mobile Apps, was seine aktuelle Arbeit besonders macht und gibt Tipps für Neueinsteiger.

  Watch now