Ihre Idee verdient ein Team, das ihr gewachsen ist

Wann eine Individualentwicklung nicht die richtige Antwort ist

Sagen wir es direkt, denn genau das würden wir Ihnen im ersten Gespräch ohnehin sagen: In vielen Fällen ist eine Individualentwicklung ein Fehler.

Wenn eine am Markt erhältliche Software achtzig Prozent Ihres Bedarfs deckt, ist der Kauf fast immer rationaler. Sie zahlen ein Abonnement statt einer Entwicklung, profitieren von Weiterentwicklungen für Tausende andere Kunden und tragen weder die Wartung noch die technische Schuld. Ihren Prozess an das Tool anzupassen, ist meist günstiger als umgekehrt.

Eine Massanfertigung wird dann sinnvoll, wenn Ihre Arbeitsweise Ihr Wettbewerbsvorteil ist und kein bestehendes Tool sie abbilden kann, wenn Sie Lizenzen für zehn Personen bezahlen, obwohl nur drei die Software nutzen, wenn Ihre Teams den ganzen Tag Daten von einem System ins andere kopieren oder wenn ein bestehendes Tool Ihnen Grenzen setzt, die Sie Umsatz kosten.

Unser erster Reflex ist daher zu prüfen, was es bereits gibt. Wenn wir eine passende Lösung finden, sagen wir es Ihnen - selbst wenn uns das das Mandat kostet.

Eine technische Entscheidung zeigt ihren Wert erst nach fünf Jahren

Wir bevorzugen langweilige Technologien im besten Sinne des Wortes: weit verbreitet, solide dokumentiert und mit leicht verfügbaren Entwicklern. Das ist ein Kriterium, das mehr zählt als die Eleganz eines trendy Frameworks.

Der Grund ist einfach: Wenn Sie die Entwicklung eines Tages intern übernehmen, den Dienstleister wechseln oder die Anwendung drei Jahre nach uns weiterentwickeln möchten, geht es nicht darum, ob die Technologie brillant war. Es geht darum, ob jemand anderes den Code übernehmen kann, ohne alles neu zu schreiben. Eine exotische Wahl bindet Sie an uns - und das ist kein guter Dienst an Ihnen.

Konkret: Der Code ist dokumentiert, an kritischen Stellen getestet, mit vollständiger Historie in Ihrem Git-Repository hinterlegt und wird über eine automatisierte Pipeline bereitgestellt, die Sie selbst übernehmen können.

Klein anfangen und von Anfang an mitdenken

Wir empfehlen fast immer, mit einer reduzierten Version zu starten und diese so früh wie möglich Ihren Nutzern zu übergeben. Nicht aus Budgetvorsicht, sondern weil sich das ursprüngliche Pflichtenheft immer als teilweise falsch erweist.

Es ist ein wiederkehrendes Phänomen: Solange niemand das Tool nutzt, basieren die geäusserten Anforderungen auf Vermutungen. Drei Wochen nach dem Go-live werden Ihre Teams feststellen, dass eine vermeintlich unverzichtbare Funktion niemand braucht, während ein nicht erwähntes Detail ihnen eine Stunde pro Tag raubt. Das bei einer ersten Version herauszufinden, kostet wenig. Es nach sechs Monaten vollständiger Entwicklung zu entdecken, kostet viel.

Wir bauen daher die Fundamente so, dass sie künftige Erweiterungen tragen, entwickeln diese aber erst, wenn Sie deren Notwendigkeit bestätigt haben.