1.000 Apps bauen und betreiben: Technische Einsichten aus „How to build and maintain 1.000 Apps“ von Michael Schöndorfer (hello again GmbH)

Kontext und Zielbild: Viele individuelle Apps, ein skalierbares Produkt

Bei DevJobs.at haben wir die Session „How to build and maintain 1.000 Apps“ von Michael Schöndorfer (CTO, hello again GmbH) verfolgt. Sein Team ist „ziemlich auf halbem Weg“ zu diesem Ziel – und denkt bereits über den nächsten Meilenstein hinaus. Der Kern der Herausforderung: hunderte bis tausend eigenständige Kunden-Apps, jeweils individuell angepasst, aber auf einer gemeinsamen Architektur und Codebasis laufend.

hello again entwickelt Kundenbindungs­lösungen (häufig als mobile App) mit Bonus- und Punkte­systemen, Gamification und Messaging. Ein zentraler Unterschied zu Wettbewerbern: „Jeder Kunde bekommt seine eigene, angepasste Lösung“ – keine gemeinsame Mega-App mit geteilten Daten. Die Datenhoheit bleibt in den Händen der jeweiligen Kund:innen, und es entstehen eigenständige Communities rund um Marken, Händler oder Städte.

Die Bandbreite der Kund:innen reicht von Einzelhandel und Online-Shops über Dienstleister (ein prägnantes Beispiel im Talk: Friseurbetriebe) bis hin zu wirtschaftlichen Regionen und Städten. Die Community-Größe variiert stark – von wenigen Tausend bis zu mehreren Millionen Nutzer:innen. Aus Engineering-Sicht führt diese Streuung zu einem massiven Spannungsfeld: Features, die für eine kleine Community gebaut werden, müssen zugleich so ausgelegt sein, dass sie auch in einer Zwei-Millionen-User-App zuverlässig skalieren.

Produktumfang: Loyalty, Feedback, Integrationen, Messaging und Analytics

Der Feature-Umfang der Apps ist entsprechend groß:

• User-Management
• Loyalty-Mechaniken mit Gamification (z. B. Punkte für Käufe, Einlösen von Rewards)
• Feedback-Formate wie Umfragen, Ratings und Formulare; optional Chat
• Integrationen mit Drittanbietern (z. B. Buchungstools für Friseure)
• Sharing-Funktionen (z. B. Facebook, WhatsApp)
• Zahlungen
• Messaging (Push und E-Mail), inklusive automatisierter Aktionen (z. B. Geburtstagsgrüße mit Punkten)
• Analytics & Reporting

hello again liefert die mobilen Apps und eine Web-App (eine „abgespeckte“ Version der mobilen App), übernimmt Tests, managt die Releases in den App Stores pro App und stellt ein CRM bereit – inklusive Marketing-Automation und Statistik-Dashboard. Darüber hinaus entwickelt das Team nicht nur den Server, sondern betreibt auch die Infrastruktur und die Wartung. Dieser Full-Stack-Ansatz erhöht die Komplexität, ermöglicht aber eine enge Verzahnung aller Bausteine.

Die Engineering-Herausforderung: Update-Flut, Komplexitätsmanagement, Regressionen

Das Multi-App-Modell bringt besondere Aufgaben mit sich:

• Viele individuelle Apps müssen aktualisiert und in die App Stores ausgeliefert werden.
• Die Komplexität wächst mit Feature-Umfang, Branchenvielfalt und Kundengrößen.
• Regressionen drohen: Eine Änderung für App A kann unerwartete Effekte in App B auslösen.
• Optimierungen müssen für kleine und extrem große Communities gleichermaßen funktionieren.

Diese Rahmenbedingungen erzwingen eine klare Architektur, konsequente Automatisierung und ausgereifte Teststrategien.

Architektur-Überblick: Multi-Tenant-Backend plus modulare App-Plattform

Im Zentrum steht der Server von hello again. Mehrere Instanzen laufen „multi-tenant-fähig“, d. h. ein gemeinsamer Backend-Stack bedient viele Mandanten. Das erleichtert die Skalierung – etwa in Peak-Phasen wie Cyber Monday oder Black Shopping Week – und wird über Google-Cloud-Services automatisiert.

Die Architektur integriert Kommunikations-Gateways (E-Mail, Push etc.), liefert das Dashboard für Kund:innen sowie die Frontends: pro Kund:in eigenständige mobile Apps und eine Web-App-Variante. Damit entsteht ein Plattform-Setup, das zentral skaliert und doch auf der Frontend-Ebene individuell pro Marke ausgeliefert wird.

Skalierungsstrategie: Multi-Tenant, modulare Apps, JavaScript-first und viel Automatisierung

Wie gelingt es, so viele kundenspezifische Lösungen ohne „10.000 Entwickler:innen“ zu bauen und zu betreiben? Schöndorfer skizzierte mehrere Kernentscheidungen:

• Multi-Tenant-Server statt Einzelinstanzen: Ein Backend-Update liefert neue Funktionen global aus. Der Nachteil: Jede Serveränderung betrifft potentiell alle Apps – umfangreiche automatisierte Tests sind Pflicht, und Downtime ist tabu („wir können auch keine Downtime haben“).
• Kein On-Premises: Die Plattform wird nicht beim Kunden betrieben. Das reduziert Variationen und vereinfacht Releases – erfordert aber klare Absagen, wenn On-Prem gefragt ist.
• Modulares App-System: Ein zentrales Framework plus Erweiterungen („Extensions“) und Konfigurationen erzeugen pro Kund:in genau die App, die benötigt wird – nicht mehr und nicht weniger.
• React Native: Eine gemeinsame Codebasis für iOS und Android. Das Team setzt stark auf JavaScript – Entwickler:innen können flexibel zwischen Komponenten wechseln.
• Automatisierung & Continuous Delivery: Vom App-Aufsetzen über Build-Pipelines bis hin zu Store-Submissions wird so viel wie möglich automatisiert.
• App Builder: Ein internes Werkzeug, mit dem sich viele App-Varianten „ohne eine einzige Zeile Code“ erstellen lassen – auch für Nicht-Entwickler:innen im Projektmanagement.
• CodePush: JavaScript-only-Updates können den App-Store-Prozess umgehen; kritische Fixes und Iterationen werden beschleunigt.
• Einfache Integrationen: Über z. B. Webhooks können sehr kundenspezifische Anforderungen ausgelagert – etwa an Partner oder die Kund:innen selbst – und dennoch sauber in die Plattform integriert werden.

Diese Entscheidungen sind die Grundlage, um aus einer Plattform viele eigenständige Produkte zu generieren – bei handhabbarer Entwicklungs- und Betriebslast.

Das modulare App-Framework im Detail

hello again strukturiert die Apps über ein Basis-Framework, eine Ebene von Erweiterungen und darüber liegende Konfigurationen.

Basis und Extensions

• App-Framework: Gemeinsames Fundament aller Apps.
• Extensions: Funktionspakete, die je nach App eingebunden werden.
• Häufig immer dabei: Authentifizierung.
• Sehr oft: Loyalty-Extension.
• Optional: Chat, weitere Features, kundenindividuelle Extensions.

Kundenspezifische Extensions sollen „andere Codebereiche nicht beeinflussen“. So lassen sich neue Anforderungen isoliert implementieren, ohne Kollateralschäden im globalen Framework zu riskieren.

Konfiguration statt Forks

Auf die Extensions folgt eine starke Konfigurationsschicht. Beispiel Authentifizierung: Login per E-Mail/Passwort oder Telefonnummer – das Verhalten kann zwischen Apps deutlich variieren, ohne Code zu forken.

Saubere Schnittstellen über Redux

Intern kommunizieren Extensions via Redux. Diese Entscheidung „zwingt uns, sehr gute interne APIs zu haben“. Das Resultat: klare Event- und Datenflüsse sowie testbare Komponenten. Extensions können:

• Screens liefern
• Redux-Actions bereitstellen
• native/React-Native-Dependencies bündeln
• auf Events lauschen und generische oder kundenspezifische Aktionen auslösen

Wichtig: Abhängigkeiten werden strikt modularisiert. Beispiel Facebook-Login: Die Facebook-SDK wird nur eingebunden, wenn die entsprechende Extension benötigt wird – andere Apps bleiben davon unberührt, und die Build-Größe bleibt schlank.

Build-Prozess: Nur, was gebraucht wird

Beim Bauen der App werden die benötigten Extensions und deren Konfigurationen abgefragt. Der Build nimmt nur das auf, was für eine konkrete App erforderlich ist. Ergebnis: weniger Ballast, schnellere Builds, optimierte App-Größen und klar getrennte, wartbare Kundenspezifika.

Konfigurationsschichten: Build-Time, Runtime und dynamischer Content

Schöndorfer unterscheidet klar zwischen Konfigurationen auf verschiedenen Ebenen:

• Build-Time (in der App „eingebacken“):
• Navigationsstruktur
• Theming
• Start-/Splash-Screen
• Runtime (Server):
• Punkte für Registrierung
• Anzahl Check-ins für den Erfolg einer Challenge
• Runtime (App/UI):
• Inhalte der Tutorial-Slides
• Anzahl der Slides (oder gar keine)
• Maintenance-Mode
• Felder im Sign-up-Prozess
• Dynamische Inhalte:
• Rewards, News, Artikel, Events

Alle Apps sind vollständig übersetzbar, um weitere Individualisierung auf Sprach- und Markenebene zu ermöglichen – ohne dafür spezifische Codepfade einzubauen.

Release- und Test-Realität: Automatisieren, wo es weh tut

Eine Kernaussage aus dem Talk:

hello again hat entlang des gesamten Wegs von Entwicklung bis Auslieferung pragmatische Lösungen aufgebaut.

App-Store-Hürden: 2FA, Lizenzen, manuelle Schritte

Besonders anschaulich: Apple verlangt in gewissen Abständen die Zustimmung zu Lizenzbedingungen – mit Zwei-Faktor-Authentifizierung auf Kundenseite. „Wir müssten sonst jedes Mal beim Kunden anrufen.“ Die Antwort des Teams: ein eigenes System mit physischen Telefonen, die 2FA-Anrufe entgegennehmen und manuelle Arbeitsschritte automatisiert abbilden. Das ist keine „schöne“ Aufgabe – aber eine, die im Massengeschäft entscheidend Zeit spart.

Testkanäle für Kund:innen

• Firebase App Distribution ermöglicht frühe Tests der App durch Kund:innen.
• Wer kein geeignetes Testgerät hat (z. B. nur iPhone statt Android), nutzt einen App-Simulator direkt im Dashboard. So erhalten Stakeholder schnellen Einblick in die aktuellste Version ihrer App.

Automatisierte App-Tests für Variantenvielfalt

hello again investiert „stark“ in ein eigenes App-Automation-Framework, um die vielen Varianten automatisiert zu testen. Dazu kommt „hohe Code-Coverage“ bei automatisierten Tests, um Server-Releases ohne flächendeckende manuelle Tests fahren zu können.

Sicherheit: Externe Penetrationstests

Regelmäßige externe Penetrationstests sind fester Bestandteil. Bei der Vielfalt an Use Cases ist es „entscheidend, dass externe Teams tief graben und Backdoors aufspüren“, die man selbst nicht antizipiert. Für eine Multi-Tenant-Plattform mit vielen Integrationspunkten ist dieser Blick von außen Gold wert.

Abhängigkeiten managen: Drittanbieter-SDKs

Ein knallhartes Realitäts-Beispiel: Wenn „Google eine bestimmte SDK-Version jetzt voraussetzt“, müssen alle Apps kurzfristig aktualisiert werden. Die Architektur hilft, das kontrolliert zu bewältigen – aber die Pflicht bleibt: „Wir müssen jede App updaten.“

Trade-offs: Warum man öfter Nein sagen muss

Das System skaliert – aber nicht ohne Preise:

• Kleine Änderungen können schwer umzusetzen sein. „Es zwingt dich, manchmal Nein zu sagen.“
• Die Komplexität steigt exponentiell. Jeder Codechange könnte wechselwirkend andere Apps beeinflussen.
• Trotz Automatisierung: Jede App muss individuell aktualisiert werden; gewisse Setup-Aufgaben bleiben.

Diese Ehrlichkeit ist erfrischend. Skalierbarkeit ist kein Freifahrtschein; sie verlangt diszipliniertes Produkt- und Technik-Management.

Stärken des Ansatzes: JavaScript-only, ein Server, gemeinsame Verbesserungen

Den Trade-offs stehen klare Vorteile gegenüber:

• „Wir brauchen keine Native-Developer.“ Die Frontend-Codebasis ist JavaScript-only (React Native).
• „Kein Bedarf, mehrere Serverinstanzen zu betreiben.“ Updates erfolgen zentral; Ressourcen werden effizient geteilt.
• App-Builds bleiben code- und größenoptimiert, weil nur benötigte Extensions gebündelt werden.
• Jede Bugfix- oder Performance-Verbesserung in einer App „profitiert allen anderen Apps“.
• Interne APIs werden gezwungenermaßen klar – gut für Architekturqualität und langfristige Wartbarkeit.

Unterm Strich: Plattformdenken zahlt sich aus, wenn man konsequent modularisiert und testet.

Praktische Leitlinien für Engineering-Teams

Aus der Session lassen sich konkrete Handlungsprinzipien ableiten, die auch außerhalb von hello again funktionieren:

1. Multi-Tenant ernst nehmen

• Zero-Downtime als Designziel.
• Automatisierte Tests als Gatekeeper für Releases, die alle Tenants betreffen.
• Strikte Trennung von kundenindividuellen Anpassungen (Extensions) und Plattformkern.

1. Modularisierung bis zur letzten Abhängigkeit

• Jede externe SDK nur dann bündeln, wenn die Funktion wirklich gebraucht wird.
• Kundenindividuelle Logik isolieren; keine Cross-Coupling-Effekte riskieren.

1. Konfiguration vor Code

• Build-Time vs. Runtime differenzieren.
• Möglichst viel Verhalten serverseitig oder per UI-Config steuerbar machen.
• Dynamische Inhalte als eigene Schicht modellieren.

1. Test- und Release-Automation pragmatisch aufbauen

• „Automation ist hart“ – also dort investieren, wo Wiederholarbeit und Fehlerquellen am größten sind (z. B. App-Store-Workflows, 2FA-Ketten, Distributionskanäle).
• Kundenfreundliche Testwege bereitstellen (Firebase App Distribution, Dashboard-Simulator).
• Hohe Code-Coverage anstreben, um Server-Updates ohne Full-Manual-Regression zu ermöglichen.

1. Drittanbieter-Abhängigkeiten aktiv managen

• Frühzeitig auf SDK-Deadlines reagieren.
• Architektur so halten, dass Mass-Updates planbar sind.

1. Sicherheits-Realismus kultivieren

• Externe Penetrationstests als Pflichtprogramm im Lifecycle verankern.

1. Bewusstes Produktmanagement betreiben

• Nicht jede Anfrage annehmen. „Nein sagen“ schützt die Plattform vor Erosion.
• Komplexität transparent machen – intern wie gegenüber Kund:innen.

Ein Blick auf Kernkomponenten der Plattform

Damit das Bild rund wird, fassen wir die Bausteine zusammen, die in der Session genannt wurden:

• Mobile Apps: pro Kund:in eigenständig, modular gebaut, React Native, JavaScript-only, mit optionalen Extensions (Auth, Loyalty, Chat, u. a.).
• Web-App: abgespeckte Frontend-Variante.
• Server (multi-tenant): skaliert über Google Cloud, integriert Kommunikations-Gateways.
• CRM & Dashboard: Benutzerverwaltung, Marketing-Automation, Statistiken/Reporting; App-Simulator für Testzwecke.
• Messaging: Push/E-Mail, inklusive automatisierter Regeln (z. B. Geburtstags-Points mit Push).
• Integrationen: Buchungstools, Social-Sharing (Facebook, WhatsApp), Zahlungen; erweiterbar per Webhooks.
• App Builder: No-/Low-Code-Werkzeug, mit dem Projektmanager:innen App-Varianten erzeugen können.
• Delivery-Pipeline: Continuous Delivery, CodePush für JavaScript-Only-Updates, App-Store-Release-Management (inkl. 2FA-Automation).
• Test-Infrastruktur: Firebase App Distribution, eigene App-Automation, hohe Testabdeckung, externe Penetrationstests.

Was wir besonders mitgenommen haben

• „Jede App ist eigenständig“ – diese Entscheidung ist grundlegend. Sie schützt Datenhoheit, schafft Markenräume, erhöht aber die technische Komplexität. Das Team begegnet dem durch ein durchkonfigurierbares, modulares System und hohe Automatisierung.
• Redux als interner Kommunikationsbus zwingt zu klaren Schnittstellen zwischen Extensions – in großen Multi-App-Setups ein Erfolgsfaktor.
• Das Team investiert bewusst in unglamouröse Automation (App-Store-2FA, Lizenzannahmen). Gerade diese Stellen skalieren schlecht manuell und verursachen sonst Flaschenhälse.
• Die klare Trennung von Build-Time-, Runtime- und dynamischen Konfigurationen erhöht Änderbarkeit ohne App-Updates und hält Releases frei von unnötigen Roundtrips.
• Multi-Tenant-Server plus CodePush schaffen schnelle, globale Rollouts – aber nur, weil Testing und Observability ernst genommen werden.

Fazit: Ein belastbares Muster für skalierbare B2B-App-Plattformen

„How to build and maintain 1.000 Apps“ zeigt ein Muster, das für viele Plattform-Teams relevant ist: Ein durchgängiges, modularisiertes Frontend, ein multi-tenant-fähiger Server, starke Konfigurierbarkeit und aggressive Automatisierung von Build- und Release-Prozessen. Dazu gehören bewusste Produktgrenzen (kein On-Prem), auf die man sich intern ausrichtet.

Schöndorfers nüchterne Punkte – „Automation ist hart“, „Wir können keine Downtime haben“, „Wir müssen jede App updaten“ – sind keine Einschränkungen, sondern Arbeitsprinzipien. Wer sie verinnerlicht, kann aus einer gemeinsamen Plattform sehr viele hochwertige, individuelle Produkte generieren – stabil, reproduzierbar und mit jeder Bugfix-Runde ein bisschen besser.

Recruiting-Hinweis aus der Session

Zum Schluss betonte Michael Schöndorfer: Das Team sucht Unterstützung – Teamleads für Server- und Frontend-Entwicklung, Backend-Developer mit Python sowie Frontend-Developer mit JavaScript, React Native und Vue.js. Wer sich in den oben beschriebenen Prinzipien wiederfindet, dürfte bei hello again GmbH an genau den richtigen Herausforderungen arbeiten.

• 

  

  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.

  Jetzt ansehen

• 

  

  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.

  Jetzt ansehen

• 

  

  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.

  Jetzt ansehen