Der Außendienst ruft dreimal am Tag im Büro an, um zu fragen, ob ein Artikel am Lager ist. Die Aufträge laufen über eine Excel-Datei mit vierzehn Reitern, die nur zwei Leute wirklich verstehen. Und irgendwann fällt in der Geschäftsführung der Satz: „Wir brauchen dafür eine App.“
Spätestens beim ersten Anruf bei einem Entwickler kommt dann die Frage, auf die niemand eine schnelle Antwort geben kann: Was kostet das? Wer eine App entwickeln lassen oder Individualsoftware beauftragen will, findet im Netz Preisangaben, die extrem weit auseinanderliegen. Das liegt nicht an unseriösen Anbietern, sondern daran, dass „App“ alles bedeuten kann, vom Formular mit Datenbank bis zur Plattform mit hundert Nutzern und fünf angebundenen Systemen.
Dieser Beitrag klärt, welche Art von App du wahrscheinlich brauchst, wovon die Kosten abhängen, was KI an der Entwicklung ändert, wie ein Projekt typischerweise abläuft, was du vorbereiten solltest und welche Kosten nach dem Start bleiben.
Erst klären: Web-App, Progressive Web App oder native App?
Bevor es um Geld geht, lohnt ein Blick auf die Bauform. Sie entscheidet mit über Kosten, Betrieb und Verteilung, und sie wird oft zu früh festgelegt, weil „App“ nach App Store klingt.
Web-App. Eine Anwendung, die im Browser läuft, auf dem Rechner, dem Tablet und dem Handy. Nichts muss installiert werden, ein Update ist für alle sofort da, und es gibt eine einzige Codebasis. Kundenportale, interne Werkzeuge, Dashboards und die Ablösung von Excel-Listen sind fast immer Web-Apps.
Progressive Web App (PWA). Eine Web-App, die sich zusätzlich wie eine App verhält. Sie lässt sich auf dem Startbildschirm installieren, öffnet sich in einem eigenen Fenster ohne Browserleiste und kann so gebaut werden, dass sie auch offline funktioniert. Auf dem iPhone installierst du sie über das Teilen-Menü und „Zum Home-Bildschirm“. Seit iOS 16.4 können solche installierten Web-Apps dort auch Push-Benachrichtigungen senden.
Native App. Eine App, die eigens für iOS und Android gebaut und über den App Store und Google Play verteilt wird. Dafür brauchst du Entwicklerkonten: Das Apple Developer Program kostet 99 US-Dollar im Jahr, Google Play einmalig 25 US-Dollar (Stand: September 2026). Jede Version durchläuft die Prüfung der Stores, bei Apple laut eigener Angabe in 90 Prozent der Fälle in weniger als 24 Stunden.
| Web-App | Progressive Web App | Native App | |
|---|---|---|---|
| Läuft auf | jedem Gerät mit Browser | jedem Gerät mit Browser, installierbar | iOS und Android, jeweils eigens gebaut oder mit gemeinsamer Basis |
| Verteilung | Link | Link, auf Wunsch auch über Stores | App Store und Google Play |
| Updates | sofort für alle | sofort für alle | über die Stores, mit Prüfung |
| Offline | nein | möglich | möglich |
| Typisch für | interne Werkzeuge, Portale, Dashboards | Außendienst, Erfassung vor Ort | Apps für Endkunden, tiefe Gerätefunktionen |
Meine Einschätzung: Die meisten internen Bedarfe im Mittelstand sind Web-Apps, manchmal mit PWA-Funktionen für den Außendienst. Eine native App lohnt sich vor allem, wenn Endkunden sie im Store finden sollen oder die App sehr tief auf das Gerät zugreifen muss. Wer „App“ sagt und „Anwendung im Browser, die auch auf dem Handy gut funktioniert“ meint, spart sich den Store und oft einen großen Teil des Budgets.
Wovon die Kosten abhängen
Die Bauform ist nur ein Faktor. Sieben weitere erklären fast die gesamte Spannbreite, und keiner davon ist eine Frage der Programmiersprache.
- Umfang. Wie viele Abläufe, Masken und Auswertungen braucht die Anwendung? Jede zusätzliche Maske ist Arbeit, und jeder Sonderfall, der zwingend mit rein muss, auch.
- Rollen und Rechte. Der Außendienst sieht nur seine Kunden, die Buchhaltung sieht Preise, der Kunde nur seine eigenen Aufträge. Jede Rolle erhöht die Zahl der Fälle, die gebaut und getestet werden müssen.
- Anbindungen an bestehende Systeme. Muss die App mit Warenwirtschaft, CRM oder Buchhaltung sprechen? Mit einer ordentlichen Schnittstelle ist das überschaubar. Ohne Schnittstelle verschiebt sich der Aufwand vom Bauen zum Verbinden, und genau dort sitzen die meisten Überraschungen.
- Offline-Fähigkeit. Klingt nach einem Häkchen, ist aber oft eine der teuersten Anforderungen. Wer offline arbeiten lässt, muss klären, was passiert, wenn zwei Leute denselben Datensatz ohne Netz geändert haben.
- Gestaltung. Ein internes Werkzeug kommt mit bewährten Standardbausteinen aus. Eine App für Kunden, die nach deiner Marke aussehen und sich besonders anfühlen soll, braucht eigene Gestaltung und kostet entsprechend mehr.
- Datenmenge und Altdaten. Müssen 20.000 Datensätze aus einer alten Access-Datenbank übernommen und dabei bereinigt werden? Das ist Projektzeit, auch wenn es sich nicht nach Entwicklung anfühlt.
- Betrieb und Wartung. Wer betreibt die Anwendung, wer spielt Updates ein, wer wird angerufen, wenn sie nicht läuft? Das gehört in die Rechnung, auch wenn es erst nach dem Start anfällt.
Wenn du ahnst, dass der Umfang eigentlich eine Standardsoftware abdecken könnte, lohnt vor jeder Anfrage die Gegenprobe. Wann Eigenbau wirklich sinnvoll ist, steht in Eigene Software entwickeln, und wie sich Eigenbau über die Jahre gegen Kaufen rechnet, in Selbst bauen oder kaufen.
Warum es keinen seriösen Pauschalpreis gibt
Der Preis einer Individualsoftware ist im Kern eine Multiplikation: Aufwand mal Satz. Der Satz lässt sich vergleichen. Zur Einordnung: Der Freelancer-Kompass 2026 von freelancermap nennt für freiberufliche Software- und Webentwickler im DACH-Raum einen mittleren Stundensatz (Median) von 90 Euro. Agenturen und Teams kalkulieren eigene Sätze.
Der Aufwand dagegen lässt sich erst schätzen, wenn klar ist, was gebaut wird. Und er schwankt viel stärker als jeder Stundensatz. Eine einfache Rechnung mit 90 Euro zeigt, warum: Zehn Euro Unterschied im Satz machen bei 200 Stunden 2.000 Euro aus. Ein falsch verstandener Umfang, der 200 Stunden zusätzlich kostet, macht 18.000 Euro aus.
Wer dir deshalb ohne genaues Hinsehen einen Festpreis für „eine App“ nennt, hat entweder großzügig Puffer eingerechnet oder wird später nachfordern. Beides zahlst du. Seriös ist der umgekehrte Weg: erst gemeinsam klären, was die Software können muss und was bewusst nicht, dann schätzen. Und mit der kleinsten Version starten, die schon echten Nutzen bringt.
Für KI-Funktionen in der App gelten eigene Kostenlogiken, vor allem laufende Modellkosten nach Verbrauch. Wie sich die zusammensetzen, steht in Was kostet ein KI-Projekt im Mittelstand.
Wie KI die Entwicklung verändert
KI hat das Schreiben von Code spürbar beschleunigt. Formulare, Tabellen, Standardabläufe und die Anbindung an gut dokumentierte Schnittstellen entstehen heute deutlich schneller als noch vor zwei Jahren, und auch ein klickbarer Prototyp steht früher. Das macht viele Projekte kürzer und oft günstiger.
Was die KI nicht übernimmt, ist die Verantwortung für das Ergebnis. Jemand muss klären, was gebaut werden soll, die Architektur festlegen, den erzeugten Code prüfen, testen und die Anwendung sicher betreiben. Die KI weiß nicht, welcher Fehler in deinem Betrieb harmlos ist und welcher Geld kostet. Deshalb verschiebt sich der Aufwand: weniger Zeit fürs Tippen, mehr Anteil für Anforderungen und Prüfung.
Genau hier liegt der Unterschied zwischen schnell zusammengepromptet und sauber gebaut. Wie sich Vibe Coding von professioneller KI-gestützter Entwicklung unterscheidet, habe ich in Vibe Coding oder KI-gestützte Softwareentwicklung beschrieben. Warum gute KI-Software mit einer klaren Beschreibung beginnt, steht in Spec-Driven Development.
Eine Warnung vor großen Versprechen gehört dazu. Wie viel schneller Entwicklung mit KI tatsächlich wird, ist schwer zu messen. Das Forschungsinstitut METR, das die Arbeit erfahrener Entwickler mit und ohne KI in kontrollierten Studien untersucht, schrieb Anfang 2026, seine Daten seien nur ein sehr schwacher Beleg für die Größe des Zuwachses. Frag einen Anbieter deshalb nicht, um wie viel KI ihn schneller macht, sondern wie er prüft, was die KI schreibt.
So läuft ein Projekt typischerweise ab
Die Namen der Phasen unterscheiden sich von Anbieter zu Anbieter, der Kern ist fast überall ähnlich. Als Beispiel die vier Schritte, mit denen ich selbst in der Softwareentwicklung arbeite:
- Discovery und Anforderungen. Die Abläufe ansehen, das eigentliche Ziel klären und festlegen, was die Software können muss und was bewusst nicht. Am Ende steht eine Beschreibung, auf deren Basis sich der Aufwand seriös schätzen lässt.
- Konzept und klickbarer Prototyp. Bevor gebaut wird, siehst du, wie sich die Lösung anfühlt, und kannst korrigieren, solange Änderungen wenig kosten.
- Umsetzung in kleinen, testbaren Etappen. Statt einer Blackbox, die erst am Ende sichtbar wird, bekommst du regelmäßig nutzbare Stände. Ein erster nutzbarer Stand steht in meinen Projekten oft nach 4 bis 8 Wochen, größere Vorhaben mit vielen Anbindungen dauern länger.
- Betrieb und Weiterentwicklung. Sauberer Start, laufender Betrieb und gezielte Erweiterungen, wenn sich im Alltag zeigt, was fehlt.
Wichtiger als die Namen ist das Prinzip dahinter: früh etwas Sichtbares, dann in kleinen Schritten, jeweils mit Stand zum Ausprobieren. Wenn du schon einen selbst gebauten Prototyp hast, etwa aus Lovable oder Claude Code, ist das ein sehr guter Einstieg in Schritt 1. Was von so einem Prototyp übernommen werden kann und was neu gebaut werden muss, steht in Vom Vibe-Coding-Prototyp zur echten Software.
Was du vorbereiten solltest
Die beste Vorbereitung kostet keinen Euro und senkt den Preis fast immer, weil sie Klärungszeit im Projekt spart.
- Die Abläufe von heute. Wie läuft der Vorgang jetzt, Schritt für Schritt, wer macht was, wo hakt es? Beschreib den echten Ablauf mit allen Abkürzungen, nicht den idealen.
- Echte Beispiele. Die Excel-Datei, drei typische Aufträge, ein Angebot, ein Screenshot der Maske, die heute alle nervt. Beispiele beantworten mehr Fragen als jede Beschreibung.
- Die Daten. Wo liegen sie heute, wie viele sind es, wie sauber sind sie, und welche Systeme sind beteiligt?
- Nutzer und Rollen. Wer arbeitet mit der Anwendung, wie viele sind es, und wer darf was sehen?
- Eine Liste der Nicht-Ziele. Was die Software ausdrücklich nicht können muss, zumindest in der ersten Version. Diese Liste ist das wirksamste Mittel gegen wachsende Budgets.
- Ein Erfolgskriterium. Woran merkst du in drei Monaten, dass es sich gelohnt hat? Weniger Anrufe im Büro, schnellere Angebote, keine doppelte Datenpflege mehr.
Wie du Anforderungen auf zwei Seiten bringst, ohne ein Lastenheft zu schreiben, zeigt Anforderungen für ein KI-Projekt aufschreiben. Das Vorgehen funktioniert für jede Individualsoftware, nicht nur mit KI.
Festpreis oder Aufwand: die Abrechnungsmodelle
Es gibt im Wesentlichen zwei Modelle und eine Mischform. Keines ist grundsätzlich besser, sie verteilen das Risiko unterschiedlich.
| Modell | So funktioniert es | Vorteil für dich | Haken |
|---|---|---|---|
| Festpreis je Etappe | Ein fester Betrag für eine klar beschriebene Etappe | Planbares Budget, klarer Umfang | Der Anbieter rechnet Puffer ein, Änderungen innerhalb der Etappe werden zu Nachträgen |
| Nach Aufwand | Abgerechnet werden die tatsächlich geleisteten Stunden oder Tage | Flexibel, du zahlst nur, was anfällt | Das Budgetrisiko liegt bei dir, du brauchst regelmäßig Einblick in Stand und Stunden |
| Mischform | Discovery zum Festpreis, danach Etappen mit Festpreis oder mit Budgetrahmen nach Aufwand | Frühe Klarheit, danach Beweglichkeit | Braucht saubere Absprachen, wann eine Etappe fertig ist |
Ich würde bei einem ersten Projekt immer mit einer abgegrenzten Discovery beginnen. Danach weißt du, was gebaut wird, und der Anbieter weiß es auch. Ob die Etappen dann zum Festpreis oder nach Aufwand laufen, ist eine Frage deiner Planungsvorlieben. Wichtig ist bei beiden: kurze Etappen, nutzbare Zwischenstände, und nach jeder Etappe die Möglichkeit, neu zu priorisieren.
Laufende Kosten nach dem Start
Mit dem Start endet die Rechnung nicht. Software, die im Alltag genutzt wird, verursacht laufende Kosten, und die gehören von Anfang an in die Entscheidung.
- Hosting und Datenbank. Server oder Cloud-Dienst, Sicherungen, Überwachung. Für interne Werkzeuge meist überschaubar, bei vielen Nutzern oder großen Datenmengen mehr.
- Drittdienste. E-Mail-Versand, Karten, Zahlungsabwicklung, Dokumentenerzeugung, KI-Modelle nach Verbrauch. Jeder einzelne ist klein, in der Summe kommt einiges zusammen.
- Store-Konten bei nativen Apps. Das Apple Developer Program kostet jedes Jahr erneut.
- Wartung. Bibliotheken bekommen Updates, Sicherheitslücken werden geschlossen, neue Betriebssystemversionen kommen. Software, die niemand pflegt, veraltet leise und wird irgendwann zum Risiko.
- Weiterentwicklung. Nach den ersten Wochen im Alltag zeigt sich, was fehlt. Plane dafür von vornherein ein Budget ein, statt die erste Version perfekt machen zu wollen.
Lass dir im Angebot die laufenden Kosten pro Monat getrennt ausweisen: Betrieb, Drittdienste, Wartung. Kläre, wer die Anwendung betreibt, du selbst oder der Dienstleister. Und lass dir den kompletten Quellcode, die Dokumentation und alle Zugänge übergeben, damit du nie von einer einzelnen Person abhängst. Ob sich die Investition über die Jahre rechnet, kannst du mit dem KI-Kostenrechner durchspielen, indem du Aufbau, laufende Kosten und eingesparte Stunden gegenüberstellst.
Häufige Fragen
Was kostet es, eine App entwickeln zu lassen?
Das hängt vor allem von Umfang, Rollen, Anbindungen, Offline-Fähigkeit und Gestaltung ab, deshalb gibt es keinen seriösen Pauschalpreis. Belastbar wird eine Zahl erst nach einer kurzen Klärungsphase. Wer mit der kleinsten nützlichen Version startet, hält die erste Rechnung klein und entscheidet über den Rest mit echten Erfahrungen.
Wie lange dauert es, eine App entwickeln zu lassen?
Ein erster nutzbarer Stand ist bei überschaubarem Umfang oft nach 4 bis 8 Wochen möglich. Große Anwendungen mit vielen Anbindungen dauern länger. Wer in Etappen liefern lässt, sieht früh Ergebnisse, statt monatelang auf eine fertige Version zu warten.
Brauche ich eine App im App Store?
Für interne Anwendungen fast nie. Eine Web-App oder Progressive Web App läuft auf allen Geräten, lässt sich auf dem Startbildschirm ablegen und braucht keine Store-Prüfung. Der Store lohnt sich vor allem, wenn Endkunden deine App dort suchen und finden sollen.
Ist Individualsoftware teurer als Standardsoftware?
Am Anfang fast immer, über die Jahre nicht unbedingt. Standardsoftware wird mit jedem Nutzer teurer, Individualsoftware kostet vor allem Aufbau und Pflege. Entscheidend ist, ob dein Ablauf wirklich besonders ist oder nur gewohnt.
Hilft es, vorher selbst einen Prototyp mit KI zu bauen?
Ja, als Anschauung. Ein selbst gebauter Prototyp zeigt dem Entwickler schneller als jede Beschreibung, was du dir vorstellst. Erwarte aber nicht, dass er eins zu eins weiterverwendet wird. Sicherheit, Berechtigungen, Anbindungen und Betrieb kommen fast immer neu dazu.
Fazit
Eine App entwickeln zu lassen, beginnt nicht mit dem Preis, sondern mit zwei Klärungen: welche Bauform du wirklich brauchst und was die Software können muss. Für die meisten internen Vorhaben ist eine Web-App die richtige Antwort, und der Preis hängt an Umfang, Rollen, Anbindungen, Offline-Fähigkeit, Gestaltung und Betrieb, nicht an der Technik.
KI macht Entwicklung schneller und oft günstiger, aber sie ersetzt weder klare Anforderungen noch sorgfältige Prüfung. Wer seine Abläufe, Beispiele, Daten und Nicht-Ziele vorbereitet, in Etappen beauftragt und die laufenden Kosten von Anfang an mitrechnet, bekommt Software, die bleibt.
Wenn du vorab einschätzen willst, wo der größte Hebel in deinem Betrieb liegt, mach den KI-Potenzial-Check. Wie ich individuelle Anwendungen baue, siehst du auf der Seite zur KI-gestützten Softwareentwicklung. Und für eine erste ehrliche Einschätzung deines Vorhabens gibt es die kostenlose Prozessanalyse.