Ihre Ruby-on-Rails-Anwendung ist geschäftskritisch. Und niemand traut sich mehr, sie anzufassen.

Wir übernehmen die bestehende Rails-Anwendung so, wie sie ist, ohne Bewertung, wie es dazu gekommen ist. Zuerst wird stabilisiert, was tatsächlich brennt, dann bauen wir die fehlende Testabdeckung auf, und danach entwickeln wir als Ihr Team weiter. Das ist weder eine Neuentwicklung noch ein Audit, das anschließend in der Ablage verschwindet.

Ein namentlich benannter Senior-Entwickler führt die Zusammenarbeit und bleibt Ihr fester Ansprechpartner, es gibt also keine Übergabe an einen Junior, der Ihr Produkt nicht kennt. Wir bauen die fehlende Testabdeckung auf, damit Änderungen kein Risiko mehr sind, liefern zuerst die Verbesserungen, die Ihre Nutzer merken, und sprechen erst danach über die größere strukturelle Arbeit. Alte Rails-Version, keine Dokumentation, ursprünglicher Entwickler nicht mehr erreichbar: das ist für uns der normale Ausgangspunkt, kein Hindernis.

Modernisierung bedeutete früher, ein ganzes Team über Monate auf eine fremde Codebasis zu setzen. Mit Senior-Urteilsvermögen und KI-Verstärkung erfolgen die umfassende Analyse der Codebasis und der Aufbau einer Testabdeckung in einem Bruchteil dieser Zeit. Auch die Rechnung auf Ihrer Seite hat sich verschoben: ein festangestellter Entwickler kostet inzwischen Gehalt plus laufende Kosten für KI-Werkzeuge, während ein Senior-Entwickler mit KI-Verstärkung über uns unter den Kosten dieser einen lokalen Stelle liegen kann, weil wir diese Werkzeuge ohnehin als Standard einsetzen. Die konkreten Zahlen hängen von Ihrem Markt und vom Umfang ab, deshalb geben wir Ihnen vorab eine ehrliche Einschätzung, bevor Sie sich festlegen.

Können Sie eine Rails-Anwendung übernehmen, deren Entwickler nicht mehr da ist? Ja. Genau das ist der Normalfall und kein Hindernis. Eine alte Rails-Version, keine Dokumentation und kein Ansprechpartner aus der Entstehungszeit sind die Ausgangslage, für die es diese Leistung gibt. Wir lesen den Code selbst und übernehmen die Verantwortung dafür.

Müssen wir die Anwendung neu entwickeln? Fast nie. Eine Neuentwicklung ist die letzte Option, nicht die erste. Wir stabilisieren die bestehende Anwendung, bauen die fehlende Testabdeckung auf und sprechen erst danach über größere strukturelle Arbeit. Sollten wir wirklich zu dem Schluss kommen, dass eine Neuentwicklung günstiger ist als schrittweise Modernisierung, sagen wir das schriftlich und mit Begründung, bevor Sie sich festlegen.

Was ist, wenn es weder Tests noch Dokumentation gibt? Das ist bei übernommenen Anwendungen der Regelfall. Wir erfassen zuerst, was die Anwendung tatsächlich tut, und bauen dann Testabdeckung für die Teile, auf die es ankommt, damit Änderungen nicht länger ein Risiko sind. Die schriftliche Einschätzung am Ende der ersten Phase ist meistens die erste echte Dokumentation, die das Produkt je hatte.

Wie schnell können Sie anfangen? In der Regel innerhalb einer Woche. Die erste Phase ist eine Bestandsaufnahme mit sofortiger Stabilisierung, sie dauert ein bis zwei Wochen und endet mit einer schriftlichen Einschätzung: was gesund ist, was fragil ist, was tatsächlich gefährdet ist und was die Behebung jeweils kostet.

Arbeiten Sie auch mit alten Rails-Versionen? Ja. Ein Versionssprung und eine Übernahme sind zwei verschiedene Aufgaben, und wir halten sie bewusst getrennt. Zuerst läuft die Anwendung stabil, danach wird der Versionssprung geplant. Beides machen wir, aber nicht gleichzeitig und nicht blind.

Wer macht die Arbeit konkret? Ein namentlich benannter Senior-Entwickler führt die Zusammenarbeit und bleibt Ihr fester Ansprechpartner, es gibt also keine Übergabe an einen Junior, der Ihr Produkt nicht kennt. Bei Rails ist das in der Regel unser Gründer Volodymyr Petlovy mit 17+ Jahren Rails-Erfahrung. Sie sprechen mit der Person, die die Arbeit auch übernimmt, nicht mit dem Vertrieb.