Bauen, modernisieren oder kaufen?
Wir sagen es euch, bevor der erste Euro fließt.
Eine gremientaugliche Make-Modify-Buy-Entscheidungsvorlage für eure teuerste und am schwersten rückholbare Tech-Weiche – in Wochen, nicht Quartalen.
Partner
Kurz erklärt
Für wen ist das gemacht
Ihr steht vor einer teuren, kaum rückholbaren Tech-Entscheidung, neu bauen, ein bestehendes System modernisieren oder eine fertige Lösung kaufen, und müsst diese Entscheidung vor einem Gremium vertreten, das die technische Realität nicht selbst beurteilen kann.
Am Ende zählt eine Empfehlung, die trägt, auch gegenüber dem eigenen Vorstand.
Leistungsumfang
- Make-vs-Modify- und Build-vs-Buy-Analyse eurer konkreten Ausgangslage
- 5-Jahres-TCO-Berechnung und Risikomatrix für jede geprüfte Option
- Tech Due Diligence des Bestands, sofern Legacy-Systeme im Spiel sind
- Optional: Clickdummy oder Prototyp als greifbarer Beleg für die Empfehlung
Nicht enthalten: Umsetzung der Entscheidung selbst, dafür gibt es die Build-Phase.
Ablauf - wenige Wochen, nicht Quartale
Kurz-Discovery
Zielbild und Rahmenbedingungen klären.
Jede Option ehrlich durchgerechnet.
In 4 Schritten zum geförderten Coaching
Was existiert bereits, was wäre möglich?
Gremientauglich, mit klarer Empfehlung.
Optional: Clickdummy oder Prototyp als Beleg für die Empfehlung.
Kurz-Discovery
Zielbild und Rahmenbedingungen klären.
Bestands- und Optionsanalyse
Was existiert bereits, was wäre möglich?
5-Jahres-TCO & Risikomatrix
Jede Option ehrlich durchgerechnet.
Entscheidungsvorlage
Gremientauglich, mit klarer Empfehlung.
Über Railslove
- Gegründet 2007, seither im Produktgeschäft
- Rund 15 Personen im Team
- 5-Jahres-TCO-Horizont in jeder Analyse
- Empfehlung in Wochen statt Quartalen
Häufig gestellte Fragen
Eine Make-or-Buy-Entscheidung klärt, ob ein Unternehmen eine benötigte Software-Funktion selbst entwickelt, eine bestehende Lösung modernisiert oder eine fertige Lösung am Markt kauft. Die Entscheidung hängt von Kosten über mehrere Jahre, strategischer Bedeutung und vorhandenem Bestand ab.
Eigenentwicklung lohnt sich meist dort, wo die Funktion einen echten Wettbewerbsvorteil darstellt und langfristig differenzierend wirkt. Für Commodity-Funktionen ist der Zukauf einer Standardlösung in der Regel wirtschaftlicher.
Der Aufwand richtet sich nach Umfang von Bestand und Optionen und wird im Kurz-Discovery-Gespräch eingeschätzt. Die Analyse selbst ist auf wenige Wochen ausgelegt, nicht auf Quartale.
Eine Tech Due Diligence bewertet vor allem den technischen Zustand eines bestehenden Systems. Die Make-Modify-Buy-Analyse geht einen Schritt weiter und liefert zusätzlich eine wirtschaftliche Gegenüberstellung aller drei Optionen samt Empfehlung.
Wir ordnen KI-Optionen realistisch ein, getrennt von Hype-Versprechen, und prüfen, ob ein KI-gestützter Ansatz die Make-, Modify- oder Buy-Option in eurem konkreten Fall tatsächlich verändert.
Die Empfehlung ist unabhängig von einer möglichen Zusammenarbeit danach formuliert. Ihr bekommt eine Entscheidungsvorlage, die auch mit einem anderen Umsetzungspartner oder intern tragfähig ist.
Für Teams, die die Grundsatzentscheidung bereits getroffen haben und direkt Umsetzung suchen. Dafür ist die Build-Phase der richtige Einstieg.
Liane Kirschner, Head of Product
Verantwortet bei Railslove Discovery-Sprints und Konzeptionsformate, mit Fokus auf KI-gestützte Methoden und Konzepte, die gleichermaßen für Entwicklung, Pitches und interne Kommunikation tragen.
Zuletzt aktualisiert am 13.11.2026
