Web App entwickeln lassen: Kosten, Ablauf und klare Auswahlkriterien

Wenn Sie eine Web App entwickeln lassen, kaufen Sie nicht eine bestimmte Zahl von Screens, sondern einen klar abgegrenzten Geschäftsprozess samt Betrieb und Übergabe. Vor einem belastbaren Angebot sollten deshalb Nutzerrollen, Kernablauf, Daten, Integrationen, Abnahmekriterien und Zuständigkeiten nach dem Launch beschrieben sein. Fehlt einer dieser Punkte, wird der Preis zur Wette auf unausgesprochene Annahmen.

Die wichtigste Arbeitsregel lautet: Nicht die Zahl der Screens treibt den Aufwand, sondern die Zahl der Regeln, Rollen und Ausnahmefälle hinter ihnen. Ein Dashboard mit fünf Ansichten kann komplexer sein als eine Anwendung mit zwanzig einfachen Formularseiten.

Kurzantwort: Eine Web App ist eine im Browser laufende Anwendung, die einen Geschäftsprozess abbildet — mit Login, Rollen, Formularen und Datenverarbeitung, nicht nur mit Inhalten. „Entwickeln lassen" bedeutet deshalb, einen abgegrenzten Prozess samt Betrieb, Abnahme und Übergabe zu beauftragen. Der Aufwand bemisst sich an den Regeln, Rollen und Ausnahmefällen dahinter, nicht an der Zahl der Bildschirme.

Zuerst klären: Web App, Website, PWA oder native App?

Eine Web App läuft im Browser, verarbeitet Eingaben und zeigt individuelle Zustände oder Daten. Eine klassische Website veröffentlicht dagegen überwiegend Inhalte. Die Grenze ist technisch nicht scharf, für die Projektplanung aber nützlich.

Eine Web App ist meist die naheliegende Produktform, wenn Nutzer Daten erfassen, bearbeiten, freigeben oder auswerten und dabei mit einem aktuellen Browser arbeiten können. Braucht der Kernablauf dagegen Sensoren, systemnahe Hintergrundaktivität oder plattformspezifische Bedienung, gehört eine native Anwendung als eigener Scope in die Prüfung.

„Responsive“ beantwortet nur die Layoutfrage. Es sagt noch nichts darüber aus, ob Kamera, Offline-Modus, Benachrichtigungen oder Datei-Uploads auf den vorgesehenen Geräten zuverlässig in den benötigten Abläufen funktionieren. Diese Fähigkeiten sollten anhand realer Zielgeräte erprobt werden.

Ein belastbarer Scope passt zunächst in sechs Sätze

Ein langes Lastenheft ist keine Voraussetzung für das Erstgespräch. Eine klare Prozessbeschreibung schon. Schreiben Sie den wichtigsten Ablauf zunächst in diesem Raster auf:

1. Rolle: Wer führt den Ablauf aus?
2. Auslöser: Welches Ereignis startet ihn?
3. Eingabe: Welche Daten liegen vor oder werden erfasst?
4. Regeln: Was wird geprüft, berechnet oder freigegeben?
5. Ergebnis: Was sieht oder erhält die Person am Ende?
6. Abgrenzung: Was gehört ausdrücklich nicht zur ersten Version?

Ein konkretes Beispiel: Eine Vertriebsmitarbeiterin lädt eine CSV-Datei mit Kontakten hoch. Die Anwendung ordnet Spalten zu, markiert fehlerhafte oder doppelte Einträge und zeigt eine Vorschau. Nach der Freigabe werden gültige Datensätze übernommen und problematische Zeilen mit Begründung exportiert. Automatische Anreicherung durch externe Datenquellen bleibt außerhalb der ersten Version.

Aus diesen sechs Sätzen lassen sich bereits Datenmodell, Rollen, Fehlerzustände und Integrationspunkte ableiten. „CSV-Import“ als einzelner Listenpunkt reicht dafür nicht. Offen bleiben sonst unter anderem Zeichencodierung, maximale Dateigröße, Dublettenlogik, Teilimporte und die Frage, wer einen Import zurücknehmen darf.

Akzeptanzkriterien statt Interpretationsspielraum

Jede Kernfunktion braucht beobachtbare Abnahmekriterien. Für das Beispiel könnte ein Fall lauten:

> Angenommen, eine berechtigte Nutzerin lädt eine Datei mit 100 Zeilen hoch, von denen drei keine E-Mail-Adresse enthalten. Nach der Prüfung zeigt die Vorschau genau diese drei Zeilen mit einem verständlichen Hinweis. Erst die anschließende Freigabe schreibt die akzeptierten Datensätze in die Datenbank.

Das Kriterium schreibt nicht vor, wie der Code gebaut wird. Es beschreibt, was Auftraggeber und Entwickler gemeinsam prüfen können. Für einen Festpreis sind solche Fälle wertvoller als Adjektive wie „intuitiv“, „modern“ oder „skalierbar“.

Was kostet es, eine Web App entwickeln zu lassen?

Eine einzelne belastbare Summe lässt sich ohne Scope nicht angeben. Für die Kalkulation ist dieses Modell brauchbarer als eine pauschale Marktspanne:

`Projektkalkulation = Arbeitspakete + Unsicherheitsreserve + externe Einmalkosten`

Laufende Kosten für Hosting, Überwachung, Support und externe Dienste sollten getrennt ausgewiesen werden. So bleibt sichtbar, welcher Betrag die Entwicklung finanziert und welcher Teil nach dem Launch wiederkehrt.

Fiktives Rechenbeispiel mit 372 Stunden

Die folgende Kalkulation ist ein strukturiertes Beispiel, kein Preisangebot, Marktwert oder Stundensatzhinweis. Der Rechensatz von 100 Euro und die Reserve von 15 Prozent sind frei gewählte Zahlen, damit die Logik nachvollziehbar bleibt.

Bei dem frei gewählten Rechensatz ergeben 372 Stunden zunächst 37.200 Euro. Eine ebenfalls fiktive Reserve von 15 Prozent führt zu 42.780 Euro. Wird ein Geschäftsablauf so vereinfacht, dass 32 Stunden entfallen, sinkt dasselbe Modell um 3.680 Euro. Genau dafür ist eine transparente Kalkulation nützlich: Eine Scope-Entscheidung wird in Zeit und Rechengröße sichtbar.

Der Anbieter kann eine andere Reserve, andere Arbeitspakete oder ein anderes Vertragsmodell verwenden. Entscheidend ist, dass Annahmen offengelegt werden. Ein Festpreis beseitigt Unsicherheit nicht; er ordnet sie entweder einem Preis, einer Abgrenzung oder einem geregelten Change Request zu.

Die größten Hebel sind häufig:

• Anzahl und Überschneidung der Nutzerrollen
• Regeln, Freigaben und Ausnahmefälle pro Ablauf
• Qualität und Dokumentation externer Schnittstellen
• Migration vorhandener Daten
• Datei-, Such-, Reporting- oder Exportfunktionen
• Anforderungen an Tests, Geräte, Last und Barrierefreiheit
• Betriebsmodell, Supportfenster und Übergabetiefe

Eine weitere Aufschlüsselung bietet der Beitrag zu den Kostenfaktoren der Web-App-Entwicklung. Für den Angebotsvergleich bleibt die entscheidende Frage: Welcher konkrete Scope ist eingerechnet, und welche offenen Punkte können den Betrag später verändern?

Vom Erstgespräch zum Betrieb: Sieben Entscheidungstore

Ein guter Projektablauf produziert nicht nur Code. Jede Phase liefert eine überprüfbare Entscheidung, bevor weitere Arbeit darauf aufbaut.

1. Ziel und Prozessgrenze

Zu Beginn werden Zielrolle, Ausgangsprozess, gewünschtes Ergebnis und Nicht-Ziele notiert. Das Ergebnis ist eine einseitige Prozesskarte, kein Funktionskatalog. Ein Verantwortlicher auf Auftraggeberseite entscheidet offene Fachfragen.

2. Klickbarer Kernablauf

Der Prototyp zeigt nicht nur den Idealweg. Leere Zustände, Ladephasen, ungültige Eingaben und fehlende Berechtigungen gehören in die Diskussion. Hier lassen sich unklare Begriffe korrigieren, bevor sie Datenbank und Code prägen.

3. Technischer Risikotest

Die unsicherste Annahme wird früh praktisch geprüft: Beispielsweise ein Importformat, eine externe API, ein komplexer Bericht oder eine Gerätefunktion. Ein kurzer technischer Durchstich kann zeigen, welche Einschränkungen in den Scope aufgenommen werden müssen.

4. Vertikaler Ausschnitt

Statt zunächst alle Oberflächen zu zeichnen, wird ein kleiner Ablauf durchgehend gebaut: Oberfläche, Geschäftsregel, Datenbank, Berechtigung und Deployment. Damit wird die Architektur an einem echten Pfad geprüft.

5. Inkremente mit festen Abnahmeterminen

Weitere Abläufe folgen in überschaubaren Paketen. Auftraggeber prüfen sie mit vereinbarten Beispieldaten. Fachliche Entscheidungen werden in einem Decision Log dokumentiert, damit eine spätere Diskussion nicht auf unterschiedlichen Erinnerungen beruht.

6. Abnahme und Release-Vorbereitung

Abnahmefälle, offene Fehler, Datenmigration, Zugänge und Rückfallplan werden gemeinsam geprüft. Eine Präsentation ist noch keine Abnahme; maßgeblich sind die vereinbarten beobachtbaren Ergebnisse.

7. Übergabe und Betriebsphase

Nach dem Release werden Monitoring, Supportweg, Verantwortlichkeiten und Aktualisierungen praktisch durchgespielt. Die Dokumentation sollte eine andere technisch qualifizierte Person in die Lage versetzen, den Betrieb nachzuvollziehen.

Freelancer, Agentur oder internes Team auswählen

Die passende Organisationsform hängt weniger vom Etikett als von Umfang, Parallelität und benötigten Disziplinen ab.

Ein direkter Vergleich der Modelle findet sich unter Freelancer vs. Agentur für Web-Entwicklung. Für die konkrete Auswahl sollten Referenzen jedoch nicht nur nach Branche betrachtet werden. Ein Anbieter mit Erfahrung in ähnlichen Rollenmodellen, Datenflüssen oder Integrationen kann fachlich näher am Problem liegen als ein Anbieter mit einem passenden Branchenlogo.

Eine 100-Punkte-Scorecard für Angebote

Bewerten Sie jede Kategorie von 0 bis 5 und multiplizieren Sie den Anteil mit dem erreichten Fünftel. Die Gewichte sind ein eigenes Entscheidungsmodell und können an das Projektrisiko angepasst werden.

Ein fiktiver Anbieter A erzielt in den sechs Kategorien 5, 4, 3, 4, 4 und 3 Punkte. Gewichtet sind das 25 + 16 + 12 + 16 + 8 + 3, also 80 von 100 Punkten. Anbieter B erreicht mit 3, 5, 5, 2, 4 und 5 Punkten 76 von 100 Punkten. B liefert in diesem Beispiel die stärkere Qualitätserklärung, A deckt Scope und Betrieb breiter ab. Die Scorecard macht diesen Unterschied sichtbar, ohne daraus eine allgemeine Rangliste abzuleiten.

Ein niedriger Preis sollte eine schwache Kategorie nicht automatisch ausgleichen. Definieren Sie vor Sichtung der Angebote, welche Nachweise Ausschlusskriterien sind. Bei einer geschäftskritischen Datenmigration kann etwa ein ungeklärter Wiederherstellungsweg schwerer wiegen als mehrere Komfortfunktionen.

Der Tech Stack folgt den Randbedingungen

React, Next.js, TypeScript, Supabase oder PostgreSQL sind keine Qualitätsbeweise für sich. Ein Stack ist erst nachvollziehbar, wenn er zu Datenmodell, Team, Deployment und Betrieb passt.

Für jede wesentliche Entscheidung genügt zunächst ein kurzes Architecture Decision Record: Problem, gewählte Option, verworfene Alternative, Konsequenzen und verantwortliche Person. Diese Notizen verhindern, dass eine spätere Übergabe nur aus Quellcode ohne Begründung besteht.

„Skalierbar“ braucht ebenfalls einen konkreten Bezug. Benennen Sie erwartete Datenmenge, gleichzeitige Nutzung, rechenintensive Abläufe und Wachstumsszenario. Ohne diese Eingaben kann das Wort weder entworfen noch abgenommen werden.

Datenschutz und Sicherheit als eigener Arbeitsstrom

Datenschutz ist kein Häkchen am Ende des Projekts. Vor der Architektur sollte ein Datenflussplan zeigen, welche Daten woher kommen, wo sie verarbeitet werden, welche Rollen darauf zugreifen und wann sie entfernt oder exportiert werden sollen.

Zur technischen Vorbereitung gehören mindestens diese Fragen:

• Welche Datenfelder braucht der Kernprozess tatsächlich?
• Welche Rolle darf Datensätze lesen, ändern, freigeben oder entfernen?
• Welche Informationen landen in Logs, Fehlerberichten und Sicherungen?
• In welchen Konten und Regionen laufen Hosting und externe Dienste?
• Wie werden Geheimnisse, Schlüssel und Umgebungsvariablen verwaltet?
• Wie wird eine Wiederherstellung getestet und dokumentiert?
• Wer bewertet einen Vorfall und wer kann technische Maßnahmen auslösen?

Diese Liste ersetzt keine rechtliche Bewertung und belegt für sich keine Compliance. Welche aktuellen Anforderungen für Branche, Datenarten und Zielmärkte gelten, sollte anhand offizieller Quellen und bei Bedarf mit fachkundiger Beratung geklärt werden. Das Entwicklungsteam kann dafür Datenflüsse, technische Maßnahmen und offene Entscheidungen nachvollziehbar dokumentieren.

Qualität messen: 72 Abnahmefelder statt „ausführlich getestet“

Eine einfache Matrix deckt mehr auf als ein pauschales Testversprechen. Nehmen wir vier Rollen – Eigentümer, Bearbeiter, Leser und Support –, sechs Aktionen – anlegen, ändern, freigeben, exportieren, entfernen und wiederherstellen – sowie drei Zustände: Gültiger Normalfall, leerer oder grenzwertiger Fall und verweigerter oder fehlerhafter Fall.

Die Rechnung lautet:

`4 Rollen × 6 Aktionen × 3 Zustände = 72 Abnahmefelder`

Nicht jedes Feld braucht einen eigenen automatisierten Test. Die Matrix zeigt aber, wo eine bewusste Antwort fehlt. Darf ein Leser exportieren? Was sieht der Support bei einem entfernten Datensatz? Was passiert, wenn eine Freigabe parallel geändert wird? Ein leeres Feld ist entweder ein Nicht-Ziel oder eine offene Produktentscheidung.

Die Teststrategie kann anschließend nach Risiko geschichtet werden:

• Regeltests für Berechnungen, Statuswechsel und Berechtigungen
• Integrationstests an Datenbank, Dateiverarbeitung und externen Schnittstellen
• durchgängige Browsertests für geschäftskritische Nutzerwege
• manuelle Prüfung auf vereinbarten Geräten und mit realistischen Beispieldaten
• technische Messungen für ausgewählte Routen, Datensätze und Nutzungsszenarien
• Release-Checkliste für Migration, Konfiguration und Rückfallweg

Auch Performance braucht einen benannten Messfall. „Die App lädt schnell“ ist nicht abnahmefähig. „Das Dashboard wird mit dem vereinbarten Testdatensatz auf den definierten Zielgeräten gemessen“ liefert zumindest einen reproduzierbaren Prüfrahmen. Zielwerte und Messmethode gehören vor der Abnahme in den Scope.

Der Betrieb gehört in das ursprüngliche Angebot

Mit dem Launch wechseln die Fragen: Wer erhält Fehlermeldungen? Wer erneuert Zugangsdaten? Wie werden Abhängigkeiten aktualisiert? Was passiert, wenn eine externe Schnittstelle ihr Verhalten ändert?

Eine einfache Zwölf-Monats-Betrachtung trennt Entwicklung und Betrieb:

`Zwölf-Monats-Aufwand = Umsetzung + 12 × laufender Betrieb + Änderungen + Ausfallvorsorge`

Zum laufenden Betrieb können Hosting, Monitoring, Support und externe Dienste gehören. Welche Positionen tatsächlich anfallen und wie sie aktuell abgerechnet werden, muss im jeweiligen Angebot und auf den offiziellen Anbieterseiten geprüft werden.

Zur technischen Definition of Done gehören je nach Scope:

• Quellcode und nachvollziehbare Versionshistorie
• Konten und Zugriffe unter geklärter Inhaberschaft
• dokumentierte Umgebungsvariablen ohne offene Geheimnisse im Repository
• Deployment- und Wiederherstellungsanleitung
• Datenbankmigrationen und Beispieldaten für Tests
• Monitoring mit benanntem Empfänger
• Liste bekannter Einschränkungen und nächster Wartungsschritte

Ein datierter Wiederherstellungstest ist aussagekräftiger als der Satz, es gebe Backups. Er zeigt, welcher Datenstand mit welchem Ablauf tatsächlich rekonstruiert wurde.

KI und No-Code: Werkzeugwahl statt Ersatz für den Scope

KI-gestützte Entwicklung kann bei Prototypen, wiederkehrendem Code, Testentwürfen oder Dokumentation helfen. Das Ergebnis braucht für einen produktiven Einsatz weiterhin eine Prüfung von Architektur, Geschäftsregeln, Datenzugriffen, Abhängigkeiten und Betrieb. Der Auftrag sollte deshalb nicht nur die Codeerzeugung, sondern auch Review und Verantwortlichkeit beschreiben.

Für eine erste Einordnung nutze ich folgende Scoping-Regel: Eine No-Code-Prüfung lohnt sich besonders bei höchstens zwei Rollen, einer externen Integration, standardnahen Anlege- und Bearbeitungsabläufen sowie ohne individuelle Hintergrundverarbeitung. Das ist keine technische Grenze. Es ist ein Filter, mit dem sich einfache interne Werkzeuge von Projekten mit vielen Regeln und Integrationen trennen lassen.

Eine eigene App „kostenlos“ zu erstellen kann für einen lokalen Prototyp oder einen Wegwerftest möglich erscheinen. Für einen verlässlichen Produktbetrieb bleiben jedoch Zeit für Spezifikation, Tests, Konten, Deployment und Wartung als reale Eingaben. Aktuelle Gratispläne und Nutzungsgrenzen sollten direkt beim jeweiligen Anbieter geprüft werden.

So wird Ihre Projektanfrage vergleichbar

Ein Anbieter kann nur die Informationen kalkulieren, die er erhält oder ausdrücklich als Annahme ergänzt. Für die erste Anfrage reicht ein kompaktes Paket:

```text Ziel: Welcher heutige Prozess soll sich verändern? Nutzerrollen: Wer arbeitet mit der Anwendung? Kernabläufe: Welche drei Wege liefern den Hauptnutzen? Regeln: Welche Freigaben, Berechnungen und Ausnahmen gibt es? Daten: Was wird erfasst, importiert, exportiert oder migriert? Integrationen: Welche Systeme und Ansprechpartner sind vorhanden? Qualität: Welche Geräte, Datenmengen und Abnahmefälle zählen? Betrieb: Wer besitzt Konten und übernimmt den Alltag nach dem Launch? Nicht-Ziele: Was bleibt aus Version eins heraus? Rahmen: Welche Termine sind fachlich begründet, welche nur gewünscht? ```

Bitten Sie jeden Anbieter zusätzlich um eine Annahmenliste mit vier Spalten: Annahme, Auswirkung, verantwortliche Person und Entscheidungsdatum. Zwei Angebote mit unterschiedlichen Annahmen sind trotz gleicher Überschrift nicht direkt vergleichbar.

Eine ausführlichere Vorlage finden Sie in der Checkliste zum Einholen eines Web-App-Angebots. Nutzen Sie dieselbe Version der Anfrage für alle Kandidaten und beantworten Sie Rückfragen gesammelt. Das verhindert, dass ein später Anbieter unbemerkt auf einem präziseren Informationsstand kalkuliert.

Sechs frühe Warnsignale und die passende Gegenfrage

1. Die Schätzung zählt nur Seiten

Warnsignal: Das Angebot nennt Login, Dashboard und Verwaltung, aber keine Rollen, Regeln oder Fehlerfälle.

Gegenfrage: Welche Geschäftsregeln und Zustände wurden pro Modul eingerechnet?

2. Der Prototyp zeigt nur perfekte Daten

Warnsignal: Leere Ergebnisse, ungültige Eingaben und fehlende Rechte sind nicht dargestellt.

Gegenfrage: Können wir den wichtigsten Ablauf mit einem Fehler- und einem Grenzfall sehen?

3. Der Festpreis kommt vor der Klärung

Warnsignal: Ein verbindlich wirkender Betrag wird genannt, obwohl Datenmigration oder Schnittstellen noch unbekannt sind.

Gegenfrage: Welche Annahmen, Ausschlüsse und Reserven tragen diesen Betrag?

4. Externe Systeme stehen nur im Kleingedruckten

Warnsignal: Die Integration wird als einzelner Punkt geführt, ohne Testzugang, Datenformat oder Fehlerbehandlung.

Gegenfrage: Welcher technische Risikotest ist vor der vollständigen Umsetzung vorgesehen?

5. Konten bleiben beim Umsetzer

Warnsignal: Repository, Hosting oder externe Dienste werden in nicht geklärten Anbieterkonten angelegt.

Gegenfrage: Wer ist Kontoinhaber, wer erhält Administratorzugriff und wie sieht ein Anbieterwechsel aus?

6. Der Plan endet am Releasetag

Warnsignal: Monitoring, Support, Wiederherstellung und Dokumentation fehlen.

Gegenfrage: Wer erkennt und bearbeitet einen Fehler am ersten Betriebstag?

Häufige Fragen zur beauftragten Web-App-Entwicklung

Wie viel kostet eine Web App?

Ohne abgegrenzte Abläufe, Rollen und Qualitätsziele ist eine konkrete Zahl nicht belastbar. Lassen Sie Arbeitspakete, Reserve, externe Einmalkosten und laufenden Betrieb getrennt ausweisen. Das fiktive Modell dieses Artikels kommt bei 372 Stunden, 100 Euro Rechensatz und 15 Prozent Reserve auf 42.780 Euro; diese Zahlen erklären nur die Berechnung und sind kein Marktpreis.

Wie kann ich eine Web App entwickeln lassen?

Beginnen Sie mit einem Kernprozess in sechs Sätzen, ergänzen Sie einen klickbaren Ablauf und prüfen Sie die technisch riskanteste Annahme. Danach können Anbieter denselben Scope kalkulieren. Umsetzung, Abnahme, Release und Betrieb sollten jeweils ein benanntes Ergebnis und eine verantwortliche Person erhalten.

Was kostet es, eine eigene App zu entwickeln?

Zuerst muss „App“ in Website, Web App, PWA oder native Anwendung übersetzt werden. Eine zusätzliche native Plattform erweitert den Scope um plattformspezifische Oberfläche, Tests, Release und Wartung. Kalkulieren Sie diese Arbeit als eigenes Paket, statt sie pauschal in die Web-App-Schätzung einzurechnen.

Wie lange dauert die Entwicklung?

Auch die Dauer folgt dem Scope und der verfügbaren Kapazität. In einer rein illustrativen Planung entsprechen 372 Stunden bei 25 eingeplanten produktiven Stunden pro Woche 14,88 Entwicklerwochen. Das ist keine Kalenderzusage: Feedbackzeiten, externe Abhängigkeiten, parallele Arbeit und Releasefenster müssen separat in den Terminplan aufgenommen werden.

Wann passt ein Festpreis?

Ein Festpreis passt zu Arbeitspaketen mit klarer Grenze, bekannten Abhängigkeiten und beobachtbaren Abnahmekriterien. Bei ungeklärten Schnittstellen oder noch zu erforschendem Produktverhalten kann eine bezahlte Discovery mit anschließendem Festpreis oder ein begrenztes Zeitmodell nachvollziehbarer sein. Änderungen brauchen einen dokumentierten Weg mit Auswirkung auf Scope, Termin und Preis.

Wem gehören Quellcode, Daten und Konten?

Das hängt von Vereinbarung und Kontostruktur ab und sollte vor Projektbeginn ausdrücklich geklärt werden. Prüfen Sie Quellcodezugriff, Nutzungsrechte, Datenexport, Administratorrollen, Domain, Hosting, externe Dienste und Übergabeunterlagen einzeln. Lassen Sie vertragliche Fragen bei Bedarf fachkundig bewerten.

Kann ich eine Web App ohne Programmierkenntnisse planen?

Ja. Für die Auftraggeberrolle sind Prozesswissen, Prioritäten und schnelle Fachentscheidungen wichtiger als eigener Anwendungscode. Beschreiben Sie reale Abläufe, Beispieldaten und Grenzfälle. Der Entwickler übersetzt diese Informationen in Datenmodell, Architektur und Tests und sollte technische Entscheidungen verständlich begründen können.

Sollte ich Standardsoftware erweitern oder neu entwickeln lassen?

Prüfen Sie zuerst drei Optionen: Vorhandene Software konfigurieren, sie über eine Schnittstelle ergänzen oder eine eigene Anwendung bauen. Eine Eigenentwicklung wird nachvollziehbar, wenn der differenzierende Kernprozess mit Standardfunktionen nicht angemessen abgebildet werden kann oder die nötigen Umwege selbst zum dauerhaften Betriebsproblem werden. Dokumentieren Sie für jede Option dieselben Kernabläufe und Integrationen.

Der 30-Minuten-Scope-Test vor dem Erstgespräch

Nehmen Sie ein leeres Blatt und stoppen Sie die Zeit:

• 4 Minuten: Geschäftsziel und heutiges Problem in je einem Satz
• 6 Minuten: wichtigste Rolle, Auslöser und gewünschtes Ergebnis
• 8 Minuten: Kernablauf Schritt für Schritt ohne Produktnamen
• 6 Minuten: drei Fehler-, Leer- oder Grenzfälle
• 3 Minuten: klare Nicht-Ziele der ersten Version
• 3 Minuten: verantwortliche Person für Abnahme und Betrieb

Das ergibt exakt 30 Minuten und eine erste belastbare Gesprächsgrundlage. Wenn sich der Kernablauf in den acht Minuten nicht ohne Begriffe wie „Dashboard“, „KI“ oder „automatisch“ erklären lässt, sollte zuerst die Prozessklärung beauftragt werden. Schicken Sie anschließend genau dieses Blatt an die ausgewählten Anbieter und vergleichen Sie, welche Annahmen sie daraus ableiten.