App-Entwicklung: Wovon die Kosten abhängen

Wie wir solche Fachanwendungen planen und umsetzen, steht auf unserer Seite zur Webentwicklung.

Ein einzelner Ablauf kann minimalistisch aufgebaut sein: Für die GESIBA erzeugt eine interne Web-Anwendung aus Adressdaten druckfertige Karten. Die Software deckt exakt diesen einen Prozess ab. Eine Plattform wie konerio muss hingegen Online-Kurse und Präsenztermine verwalten, Zertifikate an Bedingungen knüpfen und Mandantendaten strikt trennen. Beide Produkte sind Web-Anwendungen – ihr tatsächlicher Entwicklungsaufwand lässt sich an der Benutzeroberfläche jedoch nicht ablesen.

Der Aufwand steckt in der Geschäftslogik hinter dem Frontend

Ein Prozess beginnt mit einer Eingabe und endet mit einem validierten Ergebnis. Dazwischen liegen Prüfregeln, Berechtigungen, Ausnahmeszenarien oder API-Aufrufe. Ein Bestellformular ist technisch keineswegs trivial, nur weil es auf einem einzigen Screen Platz findet.

Beim Bestell- und Kassensystem yoorda bestellen Gäste per QR-Code am Tisch. Hinter der Oberfläche müssen Bestellung und Kassensystem in Echtzeit synchronisiert, Speisekarten digital eingelesen und automatisiert übersetzt werden. Bei jukeep liegt die technische Tiefe an anderer Stelle: Unternehmensdaten werden strukturiert durchsuchbar gemacht; Antworten müssen auditierbar aus eigenen Dokumenten stammen und exakte Quellennachweise enthalten.

Die wesentlichen Kostentreiber lassen sich daher über die Systemarchitektur beschreiben:

Je mehr Abhängigkeiten ein Workflow aufweist, desto weniger korreliert der Entwicklungsaufwand mit der Anzahl der sichtbaren Frontend-Ansichten.

Rollenkonzepte und Datenstrukturen prägen die Architektur

Eine Anwendung für ein einzelnes Nutzerprofil benötigt kaum Berechtigungslogik. Eine B2B-Plattform, auf der Kunden, Mitarbeiter und Administratoren unterschiedliche Rechte besitzen, erfordert dagegen ein durchdachtes Sicherheitskonzept. Rechte betreffen nicht nur das UI – sie bestimmen auf Datenbankebene, welche Datensätze abgefragt und verändert werden dürfen.

Das wird kritisch, wenn mehrere Unternehmen dieselbe Instanz nutzen (Multi-Tenancy). Hier reicht es nicht, Daten in der Benutzeroberfläche zu filtern. Bei konerio erfolgt die Datentrennung direkt in der Datenbankarchitektur und wird gegen unbefugte Abfragen abgesichert. Dieser Aufwand ist im Frontend unsichtbar, für die Datensicherheit jedoch essenziell.

Ähnliches gilt für die Datenmigration. Ein strukturierter Datenbestand mit eindeutigen Schemata lässt sich zügig importieren. Gewachsene Tabellen mit uneinheitlichen Feldtypen erfordern dagegen umfangreiche Transformationsskripte. Der Aufwand entsteht nicht beim Importieren selbst, sondern beim Vorbereiten und Validieren der Daten.

Schnittstellen bestimmen das Systemdesign

Neue Software entsteht selten auf der grünen Wiese. Meist muss sie als Baustein mit bestehenden ERP-, CRM- oder Buchhaltungssystemen kommunizieren. Wie aufwendig das wird, hängt von der Qualität, Dokumentation und Bereitstellung dieser Schnittstellen (REST, GraphQL, Webhooks) ab.

Fehlt eine nutzbare API, muss ein individueller Datenaustausch entwickelt oder der Prozess angepasst werden. Auch Zahlungsdienstleister oder KI-APIs bringen eigene Schnittstellen und Latenzen mit sich. Ein Projekt kann visuell minimalistisch wirken und im Hintergrund dennoch ein Dutzend Systeme orchestrieren.

Einmalige Entwicklung vs. laufender Betrieb

Eine transparente Kalkulation unterscheidet zwischen einmaligen Projektkosten und wiederkehrenden Betriebskosten:

Für die Wahl der Plattform ist die Bereitstellung entscheidend: Eine Progressive Web App (PWA) läuft direkt im Browser und benötigt keine App-Store-Freigabe. Für native Veröffentlichungen fallen Gebühren an: Das Apple Developer Program schlägt mit 99 US-Dollar pro Jahr zu Buche, die Google Play Console erfordert eine einmalige Registrierung von 25 US-Dollar. Bei digitalen Verkäufen über In-App-Käufe greifen zudem die aktuellen Provisionsmodelle der Store-Betreiber.

Ein fokussierter Erst-Release (MVP) reduziert das Projektrisiko

Umfangreiche Systeme müssen nicht im Ganzen gebaut werden, bevor die ersten Nutzer damit arbeiten. Es ist meist wirtschaftlicher, zuerst einen zentralen Kernprozess als Minimum Viable Product (MVP) umzusetzen. So lassen sich Datenmodell, Performance und Schnittstellen unter realen Bedingungen validieren.

Die Grundarchitektur sollte spätere Rollen, Datenstrukturen und Skalierungsschritte von Beginn an berücksichtigen. Der erste Release muss bereits einen vollständigen Kernprozess abbilden – klickbare Prototypen ohne echte Datenlogik reichen dafür nicht aus.

Checkliste vor der Angebotseinholung

Je präziser die technischen Anforderungen vorliegen, desto verlässlicher ist die Aufwandsschätzung. Diese sechs Punkte klären die Ausgangslage:

1. Abläufe definieren: Kernprozesse von der Eingabe bis zum Ergebnis dokumentieren (nicht nur Seiten skizzieren).
2. Rollen festlegen: Wer liest, wer schreibt, wer gibt Daten frei?
3. Schnittstellen listen: Welches Drittsystem muss mit welchen Daten angebunden werden?
4. Datenbestand prüfen: Welche Altdaten existieren und in welcher Qualität liegen sie vor?
5. Plattform wählen: Reicht eine Web-Anwendung im Browser oder ist eine Store-App zwingend notwendig?
6. Betrieb klären: Wer übernimmt Hosting, Monitoring, Backups und Wartung nach dem Go-Live?

Die entscheidende Frage an den Entwickler:

„Welche Prozesse sind in diesem Angebot von der Eingabe bis zur Speicherung vollständig abgedeckt und welche Schnittstellen sind enthalten?“

Eine fundierte Antwort listet konkrete Datenflüsse und Systemgrenzen auf. Eine reine Aufstellung von Entwürfen oder Template-Seiten lässt die technisch aufwendigen Teile der Softwareentwicklung offen.

Häufige Fragen

Kann man den Aufwand einer App nach der Anzahl der Seiten schätzen?

Nein. Zwei identisch aussehende Screens können im Hintergrund völlig unterschiedliche Berechtigungsprüfungen, Datenbankabfragen und Drittsysteme erfordern. Maßeinheit für den Aufwand ist die Komplexität der Geschäftslogik, nicht das Layout.

Ist eine Web-App immer günstiger als eine Store-App?

Nicht zwangsläufig. Eine Web-App spart zwar den Freigabeprozess und die Verwaltung der Store-Accounts. Der eigentliche Entwicklungsaufwand für Logik, Schnittstellen und Datenstrukturen bleibt jedoch identisch.

Welche Posten gehören in die Betriebskostenaufstellung?

Hosting-Infrastruktur, Systemüberwachung (Monitoring), regelmäßige Backups und Sicherheitsupdates. Nutzt du externe APIs (z. B. für KI-Funktionen oder Payment), müssen diese variablen Kosten separat ausgewiesen werden.

Du möchtest wissen, welche technischen Bausteine den Aufwand deiner geplanten App oder Plattform bestimmen? Wir zerlegen das Vorhaben in konkrete Abläufe und Schnittstellen. Sprich mit uns.