1. Erstellung
Konzeption, Entwicklung, Integrationen, Migration, Tests, Einführung.
Software entwickeln lassen: Erst Klarheit schaffen.
Sie müssen kein technisches Konzept schreiben, bevor Sie mit einem Softwareanbieter sprechen. Sie sollten aber so klar über Problem, Zielzustand, Nutzer und bestehende Systeme sprechen können, dass zwei Anbieter dasselbe Vorhaben verstehen.
Diese Seite hilft Ihnen, genau diese Klarheit herzustellen — unabhängig davon, ob WIRKLAUF später entwickelt.
Projektklarheit bestimmt den richtigen Einstieg
Projektklarheit ist keine Ja/Nein-Frage.
- Problem unklar — es gibt Unzufriedenheit, aber noch keinen abgegrenzten Kern.
- Problem klar — das relevante Problem ist beschrieben.
- Lösungsweg klar — grundsätzlich ist klar, welche Intervention gebraucht wird.
- Umfang ausreichend klar — erste Version, Grenzen, Nutzer und Systeme sind abgrenzbar.
- Angebotsreif — Anbieter können vergleichbare Annahmen kalkulieren.
- Umsetzungsreif — offene Punkte verhindern den Start nicht mehr.
Ein Projekt kann ein klares Problem besitzen und trotzdem noch nicht angebotsreif sein.
Problemklarheit ist nicht Lösungsklarheit
„Wir verlieren zu viel Zeit in der Auftragsannahme“ kann klar sein, obwohl offen ist, ob Prozessänderung, Integration, Automatisierung oder Software gewinnt.
Genau hier entstehen häufig schlechte Angebote: Ein Anbieter nimmt die erste Lösungshypothese des Kunden als Umfang und kalkuliert sie, statt zu prüfen, ob sie das Problem tatsächlich trifft.
Wenn der Lösungsweg offen ist, kann ein produktisierter Diagnose-Schritt sinnvoller sein als sofortige Softwarekalkulation.
Was Sie für eine Anfrage brauchen
Sie müssen nicht wissen, welche Datenbank oder Cloud verwendet werden soll. Eine gute Anfrage beantwortet eher diese Fragen:
- Welcher Ablauf ist betroffen?
- Was funktioniert heute nicht ausreichend?
- Wer nutzt oder bearbeitet den Ablauf?
- Welche Systeme sind beteiligt?
- Welche Daten/Dokumente existieren?
- Welche Ausnahmen treten regelmäßig auf?
- Was muss die erste Version zwingend können?
- Was kann später kommen?
- Woran erkennen Sie Erfolg?
- Wer übernimmt Verantwortung nach Go-live?
Das reicht für ein gutes erstes technisches Gespräch deutlich weiter als eine zufällige Funktionsliste.
Was Sie nicht vorbereiten müssen
Nicht nötig sind:
- fertige Systemarchitektur;
- Datenbankmodell;
- detaillierte API-Spezifikation;
- kompletter UX-Plan;
- jede denkbare Ausnahme;
- endgültiger Technologie-Stack;
- ein 100-seitiges Lastenheft.
Ein guter Anbieter muss technische Verantwortung übernehmen können.
Zielzustand vor Funktionsliste
Statt „Wir brauchen sieben Masken und zwölf Buttons“ ist wichtiger:
„Disposition soll einen Auftrag mit vollständigen Pflichtdaten anlegen, einem Mitarbeiter zuweisen und den Bearbeitungsstatus nachvollziehen können. Ein Auftrag darf ohne Dokumentation nicht abgeschlossen werden.“
Aus einem solchen Zielzustand lassen sich Funktionen und Architektur ableiten. Aus einer Funktionsliste lässt sich nicht automatisch ein sinnvoller Prozess ableiten.
Was trotzdem bei Ihnen bleibt
Technische Architektur kann delegiert werden. Fachliche Verantwortung nicht vollständig.
Sie müssen entscheiden oder ermöglichen:
- welcher Zustand fachlich korrekt ist;
- welche Regeln gelten;
- welche Ausnahmen legitim sind;
- welche Daten sensibel/kritisch sind;
- welche Nutzer Verantwortung tragen;
- woran Erfolg erkannt wird.
Softwareentwicklung ist Zusammenarbeit, nicht vollständige Wissensabgabe.
Kosten: drei Ebenen
2. Laufende technische Verantwortung
Hosting/Infrastruktur, Lizenzen, externe APIs/KI-Dienste, Betriebsüberwachung, Wartung sowie Sicherheits- und Abhängigkeitsupdates.
3. Interne Organisationskosten
Fachliche Mitarbeit, Datenbereinigung, Schulung, Prozessumstellung, verbleibende manuelle Arbeit.
Nur den Umsetzungspreis zu vergleichen kann langfristig die falsche Entscheidung begünstigen.
Was den Preis treibt
- Tiefe der Fachlogik;
- Rollen/Berechtigungen;
- Integrationen;
- Datenmigration;
- Anzahl/Art legitimer Ausnahmen;
- Sicherheit/Compliance-Anforderungen;
- Offline- und Mobile-Anforderungen;
- Testbarkeit;
- Einführung;
- Betrieb/Support.
Die Anzahl der Screens allein ist ein schlechter Kostenschätzer.
Warum Angebote unterschiedlich sind
Zwei Angebote können dasselbe Projekt nennen und etwas anderes meinen.
Ein Anbieter kalkuliert vielleicht Migration, Betriebsüberwachung und Integrationstests mit. Ein anderer nicht. Einer nimmt eine bestehende API als gesichert an. Der andere reserviert Machbarkeit. Einer liefert nur die erste Version. Der andere rechnet spätere Funktionen bereits ein.
Darum muss vor Preisvergleich der Umfangvergleich kommen.
Angebotsvergleich
Vergleichen Sie mindestens:
| Bereich | Frage |
|---|---|
| Zielzustand | Lösen beide Angebote dasselbe Problem? |
| Umfang | Ist die erste Version gleich abgegrenzt? |
| Annahmen | Welche Dinge gelten als „gegeben“? |
| Integrationen | Welche sind enthalten? |
| Migration | Welche Daten? |
| Testing | Welche Fehler- und Rollenfälle? |
| Betrieb | Was passiert nach Go-live? |
| Rechte/Exit | Repo, Datenexport, Infrastruktur? |
| Projektmodell | Festpreis/T&M, Änderungsprozess? |
| Preis | Erst jetzt sinnvoll vergleichbar. |
Das Abrechnungsmodell folgt der Projektsicherheit
Festpreis kann sinnvoll sein, wenn Umfang und Annahmen ausreichend stabil sind. Er verteilt einen Teil des Risikos zum Anbieter — häufig gegen Risikopuffer.
T&M kann bei offeneren Projekten sinnvoller sein, wenn Priorisierung, Transparenz und Budgetsteuerung sauber organisiert sind.
Das Modell ersetzt keine Klarheit. Ein unklarer Umfang bleibt auch mit Festpreis unklar.
Angebotsreife statt falscher Sicherheit
Wenn eine kritische API, Datenmigration oder Fachregel ungeklärt ist, kann eine vorgeschaltete Machbarkeit oder vorgeschaltete Klärung die ehrlichere Lösung sein. Ein fester Gesamtpreis auf ungeklärter Basis kann später zu nachträglichen Änderungsanforderungen, Qualitätsabstrichen oder Konflikten führen.
Anbieter bewerten
Neben Preis:
- versteht der Anbieter den Betrieb oder nur Technik?
- fragt er nach Ausnahmen/Fachregeln?
- kann er bestehende Systeme sinnvoll erhalten?
- behandelt er Betrieb und Fehlerfälle?
- trennt er Annahmen von Fakten?
- kann er erklären, wann er nicht individuell bauen würde?
- ist Übergabe/Exit nachvollziehbar?
Rechte und Übergabefähigkeit
Klären Sie:
- Code- und Repositoryzugang;
- Datenexport;
- Infrastruktur/Accounts;
- Dokumentation;
- Drittanbieterabhängigkeiten;
- Wissen zu Produktivsetzung und Betrieb;
- Übergabemöglichkeit.
Kein Anbieter kann jede Abhängigkeit vollständig eliminieren. Ziel ist transparente, beherrschbare Übergabefähigkeit — kein Marketingclaim „zero lock-in“.
KI und Entwicklungsgeschwindigkeit
KI kann Analyse, Coding, Tests und Dokumentation beschleunigen. Sie beseitigt nicht automatisch:
- unklare Fachlogik;
- falschen Umfang;
- schwierige Daten;
- API-Limits;
- Sicherheitsrisiken;
- organisatorische Einführung;
- laufenden Betrieb.
Schneller Code ist nur wertvoll, wenn das richtige System gebaut wird.
Projektklarheit führt zum passenden Start
Problem und Lösung klar
Problem klar, Lösung offen
Problem selbst noch unscharf
FAQ
Brauche ich ein Lastenheft?
Nein. Eine gute Anfragegrundlage ist hilfreicher als technische Details, die Sie nur raten können.
Wann bekomme ich einen Festpreis?
Wenn Umfang, Annahmen und technische Risiken ausreichend klar sind. Nicht jedes Projekt eignet sich sofort dafür.
Kann ein Anbieter die Konzeption übernehmen?
Ja, aber fachliche Entscheidungen brauchen Ihre Beteiligung. Wenn der Lösungsweg grundsätzlich offen ist, sollte Diagnose als eigene Leistung sichtbar sein.
Wie vergleiche ich Angebote?
Zuerst Zielzustand, Umfang, Annahmen und Ausschlüsse angleichen. Danach Preis.
Wem gehört der Code?
Das ist vertraglich/projektspezifisch zu klären. Wichtig sind transparente Rechte, Zugriff, Daten und Übergabefähigkeit.
Projektklarheit prüfen
Das Formular fragt kurz, wie klar Problem, Lösungsweg und Umfang schon sind, welche Systeme und Unterlagen es gibt und wann Sie starten möchten.
- hallo@wirklauf.com
- Telefon
- 05921 8198432