Von der Idee zum Produktivsystem

Warum Prozess entscheidend ist

Jedes erfolgreiche digitale Produkt durchlaeuft die gleichen Phasen. Der Unterschied zwischen Projekten, die im Produktivbetrieb laufen, und solchen, die nach sechs Monaten eingestellt werden, liegt selten an der Technologie. Er liegt am Prozess -- und daran, ob die richtigen Fragen zum richtigen Zeitpunkt gestellt werden.

Bei RawLinks haben wir in den letzten Jahren verschiedene Systeme gebaut: von Finanzvergleichsplattformen ueber Speditions-Management bis hin zu automatisierten Lead-Engines. Jedes dieser Projekte hat unseren Prozess geschaerft. Was uebrig geblieben ist, sind vier Phasen, die wir bei jedem Projekt durchlaufen -- und die wir bewusst nicht abkuerzen.

Phase 1: Problemverstaendnis

Bevor eine Zeile Code geschrieben wird, klaeren wir die zentrale Frage: Welches Problem loesen wir -- und fuer wen?

Das klingt offensichtlich, wird aber erstaunlich oft uebersprungen. Die meisten Projektanfragen, die uns erreichen, starten mit einer Loesungsbeschreibung: "Wir brauchen eine App, die X kann." Unsere erste Aufgabe ist es, zurueck zum Problem zu gehen.

Wir analysieren den Markt, identifizieren Engpaesse und definieren klare Erfolgskriterien. Konkret bedeutet das:

• Stakeholder-Interviews: Wer sind die Nutzer? Was ist ihr aktueller Workflow? Wo verlieren sie Zeit oder Geld?
• Prozess-Mapping: Wir zeichnen den Ist-Prozess auf -- jeden Schritt, jede Entscheidung, jede Datenquelle. Erst wenn wir verstehen, wie es heute laeuft, koennen wir sinnvoll automatisieren.
• Erfolgskriterien definieren: Was muss das System leisten, damit es den manuellen Prozess tatsaechlich ersetzt? Nicht "waere schoen", sondern harte Kriterien.

Beispiel FreightPilot: Die Ausgangslage war ein Disponent, der taeglich 80 Ladungen manuell auf Timocom bewertet hat. Das Problem war nicht "wir brauchen ein besseres Tool". Das Problem war: "Wir koennen nicht schnell genug bewerten, verlieren profitable Ladungen an schnellere Wettbewerber und nehmen aus Zeitdruck unrentable Ladungen an." Dieses Problemverstaendnis hat die gesamte Architektur bestimmt -- Geschwindigkeit und automatische Scoring-Logik wurden zu den zentralen Anforderungen.

Zeitrahmen: 1 bis 2 Wochen. Bei komplexen Domaenen wie Finanzprodukte oder Logistik auch bis zu 3 Wochen.

Was schiefgeht, wenn man diese Phase ueberspringt

Der haeufigste Anti-Pattern: Direkt in die Entwicklung springen, weil "die Anforderungen klar sind". Das Ergebnis sind Systeme, die technisch funktionieren, aber am eigentlichen Problem vorbeigehen. Wir haben das bei Uebernahme-Projekten gesehen -- Unternehmen, die sechs Monate und fuenfstellige Budgets in eine Loesung investiert haben, die niemand nutzt, weil sie den Workflow der Anwender nicht abbildet.

Phase 2: Systemdesign

Mit dem Problemverstaendnis entwerfen wir die Systemarchitektur: Datenmodelle, Schnittstellen, Automatisierungslogik und UI-Flows. Diese Phase ist der Bauplan -- und sie entscheidet, ob das System in sechs Monaten noch erweiterbar ist oder ein technisches Sanierungsfall.

Unser Systemdesign umfasst drei Ebenen:

Datenmodell: Welche Entitaeten gibt es? Wie haengen sie zusammen? Welche Daten kommen von aussen (APIs), welche werden intern generiert? Wir arbeiten hier mit Supabase als Datenbankschicht, weil PostgreSQL die Flexibilitaet bietet, die wir fuer komplexe Relationen und Echtzeit-Subscriptions brauchen.

Schnittstellen-Design: Welche externen Systeme muessen angebunden werden? Wie sehen die APIs aus? Wie gehen wir mit Rate Limits, Ausfaellen und Dateninkonsistenzen um? Jede externe Abhaengigkeit ist ein Risiko, das wir in dieser Phase explizit adressieren.

Automatisierungslogik: Welche Entscheidungen kann das System automatisch treffen? Wo braucht es menschlichen Input? Wir definieren klare Regeln -- nicht vage Absichten, sondern konkrete Schwellenwerte und Entscheidungsbaeume.

Beispiel FreightPilot: Das Datenmodell besteht aus Ladungen, Carriern, Routen und Deals. Jede Ladung hat einen Score, jeder Carrier eine Zuverlaessigkeitsbewertung. Die Schnittstellen zu Timocom und Trans.eu wurden als separate Module designed, damit bei einem API-Wechsel nur ein Modul angepasst werden muss. Die Automatisierungslogik: Score unter 30 gleich automatische Ablehnung, Score ueber 50 gleich automatische Preiskalkulation und Carrier-Matching.

Zeitrahmen: 1 bis 3 Wochen, abhaengig von der Systemkomplexitaet.

Was schiefgeht, wenn man diese Phase ueberspringt

Ohne Systemdesign entstehen Architekturen, die organisch wachsen -- und irgendwann unter ihrem eigenen Gewicht zusammenbrechen. Das typische Muster: Die ersten Features werden schnell gebaut, aber mit jeder Erweiterung wird der Code fragiler. Nach sechs Monaten dauert jede Aenderung drei Mal so lang wie am Anfang. Das ist keine technische Schuld durch Zeitdruck, sondern durch fehlendes Design.

Phase 3: Iterative Entwicklung

Statt monatelanger Planung setzen wir auf schnelle Iteration. Das bedeutet nicht "schnell und schmutzig", sondern: frueh echte Ergebnisse liefern und auf Basis von realen Daten optimieren.

Unser Entwicklungszyklus folgt einem klaren Rhythmus:

1. Kern-Funktionalitaet bauen: Das absolute Minimum, das Wert liefert. Kein Login-System, keine Einstellungsseite, keine schoene Oberflaeche -- der Kern der Geschaeftslogik.
2. Reale Daten anbinden: Testdaten sind nutzlos fuer die Validierung. Wir binden so frueh wie moeglich echte Datenquellen an, um die Logik unter realen Bedingungen zu testen.
3. Testen und optimieren: Funktioniert die Scoring-Logik? Stimmen die Kalkulationen? Ist die Performance ausreichend? Wir messen, nicht raten.
4. Schrittweise erweitern: Erst wenn der Kern stabil laeuft, kommen zusaetzliche Features dazu.

Beispiel FreightPilot: Das erste lauffaehige System konnte genau eine Sache -- Ladungen von Timocom abrufen und einen Score berechnen. Keine UI, keine Carrier-Kommunikation, kein Dashboard. Nur ein Script, das alle 30 Sekunden neue Ladungen abfragt und eine Bewertung ausgibt. Damit konnten wir innerhalb von zwei Wochen validieren, ob die Scoring-Logik in der Praxis funktioniert. Die Antwort: teilweise. Die initialen Gewichtungen mussten angepasst werden, weil bestimmte Routen im realen Markt anders bewertet wurden als in unseren Annahmen. Diese Erkenntnis nach zwei Wochen statt nach drei Monaten zu haben, hat das Projekt gerettet.

Technologie-Stack: Next.js und TypeScript fuer die Anwendung, Supabase fuer die Datenbank, n8n fuer Workflow-Automatisierung. Wir waehlen den Stack nicht nach Trend, sondern nach Eignung. TypeScript gibt uns die Typsicherheit, die bei komplexer Geschaeftslogik unerlaesslich ist. n8n ermoeglicht es, Automatisierungen schnell zu prototypen und ohne Deployment-Zyklen anzupassen.

Zeitrahmen: 4 bis 8 Wochen bis zum funktionsfaehigen MVP, dann fortlaufende Iteration.

Warum MVP first besser ist als Feature-Complete first

Der Instinkt vieler Gruender und Produktmanager ist es, das System "fertig" zu bauen, bevor es jemand sieht. Das fuehlt sich sicherer an -- aber es ist das groesste Risiko. Ein System, das drei Monate lang ohne Nutzerfeedback entwickelt wird, basiert auf Annahmen. Und Annahmen sind meistens falsch.

Ein MVP dagegen zwingt zur Klarheit: Was ist die eine Sache, die funktionieren muss? Wenn diese eine Sache Wert liefert, lohnt sich die Weiterentwicklung. Wenn nicht, haben wir frueh und guenstig gelernt. Bei FreightPilot haetten wir drei Monate in ein schoenes Dashboard investieren koennen. Stattdessen haben wir zwei Wochen in die Scoring-Logik investiert -- den Teil, der tatsaechlich ueber Erfolg oder Misserfolg entscheidet.

Phase 4: Produktivbetrieb

Ein System ist erst dann wertvoll, wenn es autonom laeuft. Die Uebergabe in den Produktivbetrieb ist keine einmalige Aktion, sondern eine eigene Disziplin.

Monitoring, Alerting und automatische Fehlerbehandlung sind von Anfang an eingeplant. Konkret bedeutet das:

• Health Checks: Jede kritische Komponente wird ueberwacht. Wenn die Timocom-API nicht erreichbar ist, weiss das System das innerhalb von Sekunden -- nicht erst, wenn ein Disponent sich wundert, warum keine neuen Ladungen kommen.
• Automatische Fehlerbehandlung: Nicht jeder Fehler erfordert menschlichen Eingriff. Wenn eine API-Anfrage fehlschlaegt, wiederholt das System den Versuch automatisch. Wenn ein Carrier nicht antwortet, wird automatisch der naechste kontaktiert.
• Alerting mit Kontext: Wenn ein menschlicher Eingriff noetig ist, bekommt die zustaendige Person nicht nur eine Fehlermeldung, sondern den Kontext: Was ist passiert? Was hat das System bereits versucht? Was muss manuell erledigt werden?
• Performance-Monitoring: Wie schnell ist das System? Wie viele Ladungen werden pro Stunde bewertet? Wo sind Engpaesse? Diese Daten fliessen zurueck in die Optimierung.

Beispiel FreightPilot: Das System laeuft 24/7 und verarbeitet Ladungen autonom. Wenn der Score einer Ladung im Grenzbereich liegt (zwischen 30 und 50), wird der Disponent per WhatsApp benachrichtigt und kann entscheiden. Alles andere laeuft ohne menschlichen Eingriff. Die Fehlerrate im ersten Monat lag bei unter 2 Prozent -- und die meisten Fehler waren auf inkonsistente Daten aus den Frachtboersen zurueckzufuehren, nicht auf Systemfehler.

Zeitrahmen: Die initiale Produktivsetzung dauert 1 bis 2 Wochen. Die Stabilisierungsphase mit Feintuning dauert weitere 2 bis 4 Wochen.

Das Ergebnis

Ein System, das 24/7 laeuft, datenbasierte Entscheidungen trifft und mit dem Geschaeft waechst. Kein Prototyp, kein Proof of Concept -- ein produktives System, das taeglich Wert liefert.

Der gesamte Prozess von der Idee bis zum stabilen Produktivbetrieb dauert typischerweise 8 bis 16 Wochen. Das ist schnell genug, um relevant zu bleiben, und gruendlich genug, um ein System zu bauen, das laenger als sechs Monate haelt.

Der Schluessel liegt nicht in der Geschwindigkeit einzelner Phasen, sondern darin, keine Phase zu ueberspringen. Jede Phase baut auf der vorherigen auf. Wer das Problemverstaendnis abkuerzt, baut das falsche System. Wer das Systemdesign ueberspringt, baut ein fragiles System. Wer die iterative Entwicklung durch einen Big-Bang-Launch ersetzt, baut ein System auf Annahmen statt auf Daten. Und wer den Produktivbetrieb nicht ernst nimmt, baut ein System, das am ersten Tag nach dem Launch Probleme macht.

Passende Leistungen

• SaaS-Entwicklung — Vom MVP zur skalierbaren Plattform.
• Web-App-Entwicklung — Individuelle Webanwendungen für komplexe Anforderungen.
• API-Integration — Systeme und Datenquellen nahtlos verbinden.
• Lead-Generierung — Automatisierte Systeme für qualifizierte Anfragen.