Wie man eine Anwendung von Grund auf baut - Schritt für Schritt

Der Bau einer Anwendung lässt sich in sieben Bereiche gliedern: Discovery, Umfang, Design und Architektur, iterative Entwicklung, Tests, Einführung und Betrieb. Sie laufen nicht immer linear ab, doch das Auslassen von Ziel, Umfangsgrenzen und Abnahmekriterien erhöht das Risiko kostspieliger Änderungen während der Entwicklung.

Dieser Beitrag beschreibt die Reihenfolge, die wir verwenden, samt ungefähren Dauerangaben und den Risiken, die entstehen, wenn einzelne Schritte ausgelassen werden.

Phase 1. Discovery - wofür und für wen?

Ziel: klären, welches Problem wir lösen und wer die Anwendung nutzen wird. Nicht „Welche Funktionen wollen wir?“, sondern „Welche Wirkung soll eintreten?“.

Ergebnis: eine Liste von Geschäftszielen, eine Beschreibung der Nutzenden und ihrer Aufgaben, Einschränkungen (rechtlich, durch Integrationen, budgetär) sowie eine Prozesskarte für den Ist- und Soll-Zustand.

Dauer: von einem Workshop bis zu zwei Wochen, je nach Komplexität.

Risiko beim Auslassen: Das Team kann Funktionen bauen, die die zentrale Aufgabe der Nutzenden nicht lösen, und die Abweichung erst bei Abnahme oder nach der Einführung entdecken. Wenn Annahmen unklar sind, beginnen Sie mit Design und Planung.

Phase 2. Umfang - was gehört in die erste Version und was nicht?

Ziel: „muss vorhanden sein, damit es überhaupt funktioniert“ von „wäre schön“ trennen. Ohne diese Trennung wächst die erste Version leicht, und die Kosten können das verfügbare Budget überschreiten, bevor der zentrale Ablauf abgeschlossen ist.

Ergebnis: der Umfang der ersten Version mit Begründung für jeden Punkt, eine Liste bewusst verschobener Dinge und Kriterien für „fertig“.

Dauer: einige Tage, allerdings braucht es Entscheidungen – und Entscheidungen sind oft ein Engpass.

Risiko beim Auslassen: Ein Projekt ohne Umfangsgrenze kann wachsen, bis Zeit oder Budget aufgebraucht sind. Statt einer funktionierenden, fokussierten Version bleibt dann eine Sammlung unfertiger Funktionen. Den Umfang des Einstiegsprodukts beschreiben wir im Angebot MVP in 4–6 Wochen.

Phase 3. Design und Architektur

Zwei parallele Themen:

• Interface-Design – Bildschirme und Abläufe. Die visuelle Ebene soll Verständnis, Hierarchie und Aufgabenerledigung unterstützen; sie ist nicht nur Dekoration.
• Architektur – Datenmodell, Systemgrenzen, Integrationen, Authentifizierungsweg und Einführungsplan. Eine Änderung grundlegender Beziehungen nach dem Ansammeln von Daten erfordert meist eine Migration und ist riskanter als die Korrektur eines einzelnen Bildschirms.

Dauer: 1–3 Wochen.

Risiko beim Auslassen: Das Hinzufügen von Funktionen kann Umgehungslösungen, Datenmigrationen und Änderungen an vielen abhängigen Stellen erfordern. Nicht jede Korrektur bedeutet, das System neu zu schreiben, doch fehlende explizite Architekturgrenzen erhöhen Kosten und Risiko der nächsten Änderungen.

Phase 4. Entwicklung - iterativ, nicht „bis es fertig ist“

Ziel: möglichst früh eine funktionierende, wenn auch schlanke Version zu erhalten, die eine zentrale Annahme prüfen kann, und sie anschließend anhand des Ergebnisses zu erweitern.

So arbeiten wir: Wir führen ein Projekt durch die Kette Discovery → Briefing → Plan → Einführung → Überprüfung und schreiben Code mit KI-Assistenten (Claude Code, Codex) in einem dedizierten Workflow, mit gegenseitigem Review und Tests. KI beschleunigt einige Aufgaben, das Ergebnis durchläuft aber weiterhin Review, Tests und Abnahme nach den vereinbarten Kriterien. Siehe Prozess und die technische Beschreibung unserer Arbeit mit KI-Assistenten.

Den Rhythmus passen wir dem Umfang an; gewöhnlich planen wir Meilensteine alle 1–2 Wochen. Jeder sollte mit einem Element enden, das sich ansehen, starten oder anhand eines vereinbarten Kriteriums prüfen lässt.

Risiko ohne Iterationen: Eine unterschiedliche Auffassung des Umfangs zeigt sich erst, nachdem viele voneinander abhängige Teile gebaut wurden. Kurze Abnahmen erlauben Kurskorrekturen, solange die Änderungskosten begrenzt sind.

Phase 5. Tests - und nicht nur „Klicken“

Drei Testebenen, deren Umfang sich nach dem Projektrisiko richtet:

• Automatisierte Tests für Logik, von der Geld abhängt (Berechnungen, Berechtigungen, Integrationen).
• Test mit repräsentativen Daten und Volumen. Die Stichprobe sollte Formate, Randfälle und eine Last nahe der geplanten Nutzung abdecken; einige bequeme Datensätze zeigen weder Probleme der Skalierung noch der Datenqualität.
• Test mit Nutzenden. Jemand, der nicht am Projekt beteiligt war, soll eine Aufgabe ohne Hinweise erledigen.

Die Dauer ist mit der Entwicklung verflochten, nicht eine gesonderte Phase am Ende.

Phase 6. Einführung in den Produktivbetrieb

Eine Produktiveinführung ist mehr als „Dateien hochladen“. Sie umfasst unter anderem:

• Server und Konfiguration (bei uns ein VPS mit automatischer Einführung aus dem Repository),
• Backups und eine getestete Wiederherstellung – ohne Test weiß niemand, ob man sich innerhalb der erforderlichen Zeit auf das Backup verlassen kann,
• Monitoring und Alerts, die die Chance erhöhen, einen Ausfall zu erkennen, bevor ihn ein Nutzer meldet,
• Domain, Zertifikate, Zugangsdaten und Dokumentation.

Dauer: einige Tage mit einem guten Plan, Wochen ohne ihn.

Phase 7. Betrieb und Weiterentwicklung

Eine produktive Anwendung braucht für ihre gesamte Nutzungszeit Betreuung: Aktualisierung von Abhängigkeiten, Monitoring, Backups, Reaktion auf Vorfälle und Anpassung an Prozessänderungen. Im August 2026 beträgt unser Retainer 1.500–6.000 PLN netto/Monat, abhängig von Umfang und Reaktionszeit.

Risiko beim Auslassen: Rückstände bei Updates wachsen, und die Einführung der nächsten Änderung verlangt zunächst die Beseitigung von Sicherheits- oder Kompatibilitätsproblemen bei Abhängigkeiten. Betriebsumfang und Verantwortlichkeiten der Parteien sollten noch vor dem Produktivstart vereinbart werden.

Wie lange dauert das alles und was kostet es?

Unsere Preisrahmen, damit es eine gemeinsame Gesprächsgrundlage gibt:

Umfang	Ungefähre Dauer	Preisrahmen netto (August 2026)
MVP / Startanwendung	4–6 Wochen bei einem zentralen Ablauf und begrenzter Zahl von Integrationen	15.000–35.000 PLN
Mittlere Anwendung mit Integrationen	2–4 Monate	35.000–90.000 PLN
Umfassendes maßgeschneidertes System	ab 4 Monaten	90.000–250.000 PLN
Betrieb	fortlaufend	1.500–6.000 PLN/Monat

Was die Kalkulation verschiebt: Anzahl der Integrationen, Sicherheitsanforderungen, Anzahl der Rollen und Berechtigungen, Datenumfang und die Notwendigkeit einer Migration von einem Altsystem. Den Rahmen bestätigen wir, nachdem Umfang und Abhängigkeiten festgehalten sind.

Wann keine Anwendung bauen?

• Wenn ein fertiges Werkzeug die wichtigsten Anforderungen abdeckt. Vergleichen Sie Lizenz- und Prozessanpassungskosten mit Kosten für Bau und Betrieb einer eigenen Lösung.
• Wenn noch nicht klar ist, ob das Problem real ist. Erst validieren, notfalls manuell, dann coden.
• Wenn Inhalt statt Funktion das Produkt ist. Dann kann eine Website die richtige Wahl sein – wir vergleichen dies in Next.js oder WordPress.
• Wenn auf Ihrer Seite niemand Zeit für das Projekt hat. Eine maßgeschneiderte Anwendung verlangt Entscheidungen des Kunden. Ohne sie entsteht eine Anwendung nach unseren Vermutungen.

Häufige Fragen

Gehört der Code uns?

Wir übergeben das Repository und die Rechte am für den Kunden erstellten Code in dem im Vertrag beschriebenen Umfang. Open-Source-Bibliotheken, externe Dienste, Schriften und andere Abhängigkeiten bleiben unter ihren jeweiligen Lizenzen. Daher sollte eine Übersicht der Komponenten und Konten Teil der Übergabe sein.

Lässt sich eine Anwendung bauen, ohne für alles schon eine fertige Idee zu haben?

Ja. Genau dafür gibt es Discovery und Etappierung: Wir beginnen mit der kleinsten Version, die eine wichtige Annahme prüfen kann, und entscheiden über die nächsten Schritte anhand der Ergebnisse und Informationen von Nutzenden.

Wie prüfe ich, ob ein Dienstleister den Produktivbetrieb beherrscht?

Fragen Sie, was er heute produktiv betreibt, wie er Störungen erkennt, Daten wiederherstellt und Verantwortung übergibt. Ein Portfolio allein beantwortet diese Fragen nicht; bitten Sie um ein Verfahren, den Umfang des Monitorings und einen beispielhaften Übergabeplan.

---

Wir bauen Anwendungen von Grund auf und führen sie in den Produktivbetrieb. Ein Beispiel für ein System, das wir zusammen mit kontinuierlich arbeitenden Kollektoren betreiben, ist die auf TimescaleDB basierende Analyseplattform. Sehen Sie sich von Grund auf gebaute Anwendungen an oder beschreiben Sie uns Ihren Prozess.