- Rollen, Geschäftslogik und Schnittstellen bestimmen den Aufwand stärker als die Screenzahl.
- Eine Discovery reduziert Fehlentwicklungen und schafft belastbare Etappen.
- Ein MVP muss einen vollständigen Kernprozess zuverlässig lösen.
- Hosting, Sicherheit, Support und Weiterentwicklung gehören in die Gesamtbetrachtung.
1. Warum es keinen seriösen Einheitspreis gibt
„Eine App“ kann fünf Eingabemasken ohne Login oder eine mandantenfähige Plattform mit Rollen, Zahlungen und Integrationen bedeuten. Der Aufwand wird nicht primär durch die Zahl der Screens bestimmt, sondern durch Geschäftslogik, Daten, Rechte, Ausnahmen und Qualitätsanforderungen.
2. Die grössten Kostentreiber
- Anzahl Nutzerrollen und Berechtigungsregeln
- Komplexität der Workflows und Ausnahmen
- Datenmigration und Datenqualität
- Schnittstellen zu Drittanbietern
- Mobile Apps, Offline-Fähigkeit und Gerätefunktionen
- Sicherheits-, Datenschutz- und Verfügbarkeitsanforderungen
- Tests, Dokumentation, Schulung und Betrieb
3. Warum Discovery Geld spart
Eine kurze Discovery klärt Problem, Nutzer, Prozess, Daten, Risiken und MVP-Grenze. Ohne diese Phase wird häufig zu früh entwickelt und später teuer umgebaut.
Das Ergebnis sollte eine priorisierte Funktionsliste, Nutzerwege, Architekturannahmen und eine Etappenplanung sein.
4. Ein MVP ist nicht einfach eine schlechte Vollversion
Ein gutes MVP löst einen schmalen Anwendungsfall vollständig. Es verzichtet auf Funktionen, nicht auf Sicherheit, Datenkonsistenz oder eine verständliche Bedienung.
Wählen Sie den Kern so, dass reale Nutzer damit einen vollständigen Prozess erledigen können und Feedback nicht nur auf einem Prototyp basiert.
5. Betrieb und Weiterentwicklung
Zum Entwicklungsbudget gehören später Hosting, Backups, Monitoring, Fehlerbehebung, Sicherheitsupdates, Support und Anpassungen an externe APIs. Planen Sie dafür einen laufenden Rahmen, statt nur den ersten Release zu finanzieren.
6. Was in einer guten Offerte stehen sollte
Leistungsumfang, Annahmen, Ausschlüsse, Meilensteine, Abnahme, Rechte, Infrastruktur, Fremdkosten und Änderungsprozess sollten verständlich dokumentiert sein. Bei Unsicherheit ist eine bezahlte Konzeptphase ehrlicher als eine scheinbar präzise Pauschale.
7. Standardlösung oder Eigenentwicklung?
Vor jeder Kostenfrage steht die Frage, ob es überhaupt eine Eigenentwicklung braucht. Eine Standardlösung ist meist die günstigere Wahl, wenn der Prozess branchenüblich ist, die Anpassungen sich auf Konfiguration beschränken und die Datenhoheit geklärt ist.
Für eine Eigenentwicklung sprechen dagegen ein Ablauf, der Ihr Geschäft tatsächlich unterscheidet, mehrere Systeme, die zusammengeführt werden müssen, oder Lizenzmodelle, die mit der Nutzerzahl unverhältnismässig wachsen. Häufig ist die tragfähigste Antwort eine Kombination: Standard für die Buchhaltung, individuelle Software für den Kernprozess. Welche Vorgehensweise Appvolution dabei anwendet, ist unter individuelle Softwareentwicklung in der Schweiz beschrieben.
Wofür dieser Beitrag nicht gedacht ist
Es gibt hier bewusst keine Preistabelle und keinen Tagessatz-Vergleich. Aufwandszahlen ohne beschriebene Anforderungen sind irreführend, weil dieselbe Funktionsbeschreibung je nach Datenlage, Rollenmodell und Integrationstiefe ein Vielfaches auseinanderliegen kann. Der Beitrag ersetzt auch keine Architekturberatung für bestehende Systemlandschaften.
Häufige Fragen zu Softwarekosten
Warum ist eine Schätzung ohne Konzept so ungenau?
Weil der Aufwand hauptsächlich aus Ausnahmen entsteht. Der Normalfall eines Prozesses ist rasch beschrieben; teuer werden Sonderfälle, Berechtigungen, Korrekturen und der Umgang mit unvollständigen Daten.
Wie klein darf ein MVP sein?
So klein, dass reale Nutzer damit einen vollständigen Ablauf ohne Umweg erledigen können. Wird der Umfang darunter geschnitten, entsteht kein belastbares Feedback, sondern nur eine Demo.
Welche Kosten entstehen nach dem ersten Release?
Hosting, Backups, Monitoring, Sicherheitsupdates, Support und Anpassungen an externe Schnittstellen. Diese Positionen laufen dauerhaft und sollten von Beginn an budgetiert sein.
Was passiert mit dem Quellcode?
Klären Sie Rechte, Repository-Zugang und Dokumentation vor Projektbeginn schriftlich. Ohne diese Punkte ist ein späterer Anbieterwechsel teuer, unabhängig von der ursprünglichen Projektsumme.
Dieser Beitrag dient der allgemeinen Orientierung und ersetzt keine individuelle Rechts-, Steuer-, Treuhand- oder Sicherheitsberatung.