Standardprodukt oder Individualsoftware: wann Sie was wählen

Sie kaufen ein CRM, weil der Vertriebsleiter mit den Notizen nicht mehr zurechtkommt, und nach drei Monaten steht neben dem System ein Excel mit drei Preislisten und ein Ordner mit Rechnungen, die jemand in die Buchhaltung überträgt. Das Produkt ist nicht schlechter als das, wofür es verkauft wurde, denn es kennt den Kunden, den Vorgang und den nächsten Anruf, aber es kennt Ihren Prozess nicht, weil dieser Prozess nicht der war, den der Hersteller für Hunderte von Unternehmen gebaut hat, und genau dieser Abstand ist das ganze Thema dieses Artikels: kaufen Sie ein Werkzeug für Ihren Prozess oder einen Prozess für Ihr Werkzeug, und nicht das Loch in einer Funktionsliste, das sich mit einer Anpassung schließen lässt. Ist das Loch eine Verbindung zwischen Systemen, die ihre Arbeit bereits tun, ist das kein Argument für einen Bau: zuerst schließen wir an, was schon da ist.

Standardprodukt oder Individualsoftware: wann Sie was wählen, ist keine Frage, welche Schaltfläche moderner aussieht, und auch keine Frage, ob Sie „groß genug sind, um selbst zu bauen“. Unsere Antwort ist dieselbe, die wir auf der Leistungsseite geschrieben haben: wenn Ihr Prozess in ein Standardwerkzeug passt, nehmen Sie das Standardwerkzeug, das ist günstiger, und ein individuelles System ist gerechtfertigt, wenn der Prozess Teil Ihres Wettbewerbsvorteils ist oder Standardlösungen zu viele Kompromisse verlangen, und dieser Satz ist kein Verkaufstrick, um danach doch einen Bau zu verkaufen, sondern der Test, mit dem wir Aufträge verlieren, in denen noch ein CRM geschrieben werden müsste, und jene behalten, in denen der Prozess Teil des Wettbewerbsvorteils ist oder die Standardwerkzeuge zu viele Kompromisse verlangen.

Dieser Artikel ist kein Vergleich von Onlineshop-Plattformen, denn den haben wir schon anderswo geschrieben, und er ist auch kein Preisverzeichnis für Individualsoftware, denn einen solchen Artikel haben wir nicht und werden wir auch nicht haben, weil wir Preise nicht aus der Luft greifen, und er ist auch kein Versprechen, dass ein eigenes System immer gewinnt. Wir verkaufen die Einführung eines Standardprodukts ebenso wie den Bau von Grund auf, und ein ehrlicher Text beginnt damit, dass der teuerste Dienst, den wir Ihnen verkaufen können, manchmal der ist, den Sie nicht brauchen, deshalb folgt die Grenze, an der sich diese Wahl treffen lässt, bevor Ihnen jemand einen Sprint verkauft.

Standardprodukt oder Individualsoftware: wann Sie was wählen

Nehmen Sie das Standardprodukt, wenn der Prozess darin Platz hat, und bestellen Sie Software, wenn der Prozess Ihr Wettbewerbsvorteil ist oder die Standardwerkzeuge zu viele Kompromisse verlangen: das ist die ganze Antwort, und der Rest dieses Artikels ist, wie sich dieser Satz gegen eine konkrete Arbeit prüfen lässt, nicht gegen eine Präsentation. Ein Vergleich, der mit einer Funktionstabelle beginnt, endet, bevor er begonnen hat, denn die Tabelle zeigt, was der Hersteller benannt hat, nicht wer nach einem Jahr Ihre nächste Änderung entscheidet.

Die Folgen der falschen Seite sind nicht symmetrisch, denn das Standardwerkzeug, in das Sie Ihren Prozess mit Gewalt gelegt haben, wird zum Abonnement plus Excel plus einem Menschen, der beides zusammenhält, und dieser Mensch ist nach einem Jahr teurer als jede Lizenz, aber ein individuelles System für einen Prozess, der schon in der Buchhaltung, im Mailprogramm und in einem Standard-CRM lebt, ist ein Bau, den Sie selbst warten, obwohl ihn am Markt schon jemand anderes wartet. Im ersten Fall haben Sie ein Produkt gekauft und danach ein zweites System daneben geschrieben, im zweiten haben Sie ein System dort geschrieben, wo eine Lizenz gereicht hätte, und beide Fehler kosten länger, als sie im Angebot aussehen.

Wir benennen diese Grenze, weil wir beide Enden in einer Woche gesehen haben: ein Unternehmen, das „sein HubSpot“ wollte, obwohl es HubSpot brauchte, und ein Unternehmen, das drei Jahre ein fertiges ERP um seine Preistabelle gebogen hat und schließlich mit derselben Tabelle als neuem Projekt kam, nicht weil „das ERP das nicht kann“, sondern weil die Kompromisse schon mehr waren als die Konfiguration. Keiner dieser Zustände ist das Ergebnis schlechten Willens, denn beide beginnen mit dem Satz „wir brauchen ein System“, der noch kein Test ist, und der Test beginnt erst, wenn Sie den Prozess auf einer Seite ohne Werkzeugnamen aufschreiben und danach suchen, welches Werkzeug diese Seite schon tut.

Bevor Sie einkaufen, schreiben Sie auf, was das System am ersten Tag tun muss, was es im zweiten Jahr nicht vergessen darf, und wer dieses zweite Jahr ohne fremden Release ändern darf, denn wenn die Antworten in ein Produkt passen, das sich konfigurieren lässt, nehmen Sie das Produkt. Ist die Frage Katalog, Preise, Bestellung und Lieferung in einem Onlineshop, ist das der Shop-Test, und den schreiben wir hier nicht um; sind die Antworten ein Prozess, den der Wettbewerber nicht als Standardwerkzeug kaufen darf, dann erst hat es Sinn, über einen Sprint zu sprechen. Dieser Artikel verkauft weiter diese Reihenfolge, nicht ein Werkzeug.

Was ein Standardprodukt ist und was Individualsoftware

Ein Standardprodukt ist Software, die jemand bereits für viele geschrieben hat und die Sie kaufen oder abonnieren, um sie ohne wesentliche Umbauten zu nutzen. In den IT-Grundschutz-Bausteinen des BSI hat die Entwicklung von Individualsoftware einen eigenen Baustein (APP.7); APP.6 Allgemeine Software gilt für Software jeder Herkunft, auch für individuell entwickelte. COTS bleibt das englische Kürzel für fertige kommerzielle Software ohne wesentliche Anpassung, SaaS (Software as a Service) die Anwendung, die im Internet als Abonnement zu nutzen ist. Das sind Wörter für die öffentliche Planung, keine Pflicht für ein privates Unternehmen, und wir nehmen sie hier als bereits benannte Wörter, nicht als Gesetz, das Ihnen eine BSI-Freigabe auferlegt.

Individualsoftware ist ein System, das für Ihren Prozess geschrieben wird. In der öffentlichen Planung ist das individuell entwickelte Software für eine konkrete Stelle oder Branche. Wir nennen sie auch individuelles System, auf der Leistungsseite nicht standardisiertes System und in der Überschrift Individualsoftware, und das sind nicht drei Produkte, sondern eine Arbeit: Code, der bei Ihrem Prozess beginnt, nicht bei der Annahme des Herstellers darüber, was ein Kunde, ein Auftrag oder eine Rechnung ist, deshalb ist der Unterschied nicht „besser“ gegen „schlechter“, sondern wer diese Annahme danach ändern darf.

Das Standardprodukt ist kein gescheiterter Bau, und der Bau ist kein besseres CRM, denn WooCommerce ist ein fertiges Onlineshop-Produkt, Moodle eine fertige Lernplattform, WordPress eine fertige Content-Plattform, und wir verkaufen alle drei als Einführung, nicht als versteckten Bau unter anderem Namen. Laravel ist in diesem Sinn kein Produkt: es ist ein Framework, auf dem wir seit der Version 4.0 im Jahr 2013 individuelle Systeme schreiben, und es liefert weder Katalog noch Warenkorb noch CRM, solange sie niemand geschrieben hat, deshalb bedeutet, Framework und Produkt zu verwechseln, sich einzubilden, „auf Laravel“ sei schon die Antwort, obwohl es nur die Art ist, die Antwort zu schreiben.

Die dritte Sache, die man an dieser Stelle gewöhnlich vermischt, ist Abonnement gegen Eigentum, denn SaaS bedeutet, dass Sie für die Nutzung zahlen und die Daten beim Anbieter stehen, eine unbefristete Lizenz bedeutet, dass Sie für das Recht gezahlt haben, eine Version zu nutzen, und Updates oft eine eigene Zeile sind, aber der Auftragscode, den wir übergeben, bedeutet, dass Quellcode, Dokumentation und Infrastruktur-Konfiguration Ihnen gehören. In keiner dieser Zeilen liegt ein automatischer Sieg, es gibt nur Klarheit darüber, was Sie kaufen, denn sonst streiten Sie nach einem Jahr darüber, ob „das System uns gehört“, wenn in Wahrheit ein Abonnement da ist, das sich kündigen lässt.

Der Test, mit dem wir diese Wahl treffen

Der Test ist nicht „ob uns dieser Bildschirm gefällt“, sondern ob der Prozess, den Sie dem Wettbewerber nicht überlassen dürfen, in ein Werkzeug passt, das der Wettbewerber im selben Laden kaufen kann: wenn er passt, ist das Werkzeug die richtige Antwort, weil es günstiger sein wird und es jemand wartet, dessen einzige Arbeit dieses Werkzeug ist, wenn er aber nicht passt, weil Preistabelle, Auftragsfreigabe oder Lieferbedingungen das sind, womit Sie sich unterscheiden, dann wird das Standardprodukt zum Kompromiss, und Kompromiss heißt hier, dass der Prozess neben dem System in Excel zu leben beginnt.

Die andere Seite desselben Tests wird zu oft vergessen, denn Bedürfnisse sind häufiger gemeinsam als einzigartig, und ein Mailprogramm baut man nicht, eine Buchhaltung, die schon tut, was das Gesetz verlangt, baut man nicht, und einen Standard-Verkaufstrichter, in dem ein Vorgang ein Vorgang ist, baut man auch nicht. Stellen, die ihr Geld nach geschriebenen Kriterien ausgeben, haben dieselbe Form anders benannt: zuerst fragen, ob die Sache am Markt schon existiert, und bauen, wenn die verfügbaren Produkte den Kern nicht decken oder wenn man die Sache selbst steuern muss, und das ist keine Pflicht eines privaten Unternehmens, und wir machen sie nicht dazu, aber es ist dieselbe Form, mit der wir nein sagen zu einem Bau, den man kaufen kann.

Der dritte Fehler ist der Umbau eines Produkts, bis es kein Produkt mehr ist, denn Konfiguration bleibt im unterstützten Rahmen (Felder, Rollen, Abläufe, die der Hersteller vorgesehen hat), aber eine Anpassung, die den Kern umschreibt, damit der Prozess „endlich passt“, gibt genau den Vorteil aus, für den das Produkt gekauft wurde: Updates, Dokumentation, dass den Fehler jemand anderes findet. Wir haben das in Moodle-Einführungen gesehen, in denen wir zuerst prüfen, ob das Plugin schon existiert, und erst dann unser eigenes schreiben, und auf WordPress-Websites, auf denen wir kein fertiges Theme setzen, weil es Dutzende Funktionen mitbringt, die Sie nicht brauchen und die zum Sicherheitsrisiko werden, deshalb ist ein Produkt mit fremdem Kern kein individuelles System, sondern ein Produkt, dem Sie den Kern des Herstellers herausgenommen haben.

Wir führen diesen Test im Discovery-Workshop, nicht auf der Folie im Angebot, denn auf der Folie gewinnt immer der Bau, der nach Sorgfalt aussieht, im Workshop gewinnt der Prozess, den man benennen kann. Zeigt sich nach zwei Tagen, dass der Prozess in ein Standardwerkzeug passt, sagen wir das, auch wenn das heißt, dass das Geschäft dieser Woche nicht unser nicht standardisiertes System ist, denn ein Artikel, der immer mit „wir bauen Ihnen etwas Eigenes“ endet, ist kein Test, sondern ein Angebot, das sich hinter einer Frage versteckt.

Wann das Standardprodukt die richtige Antwort ist

Das Standardprodukt ist dort die richtige Antwort, wo der Prozess in der Branche schon benannt ist und Sie nicht diejenigen sind, die diesen Namen erfunden haben, denn E-Mail, eine Buchhaltung, die die Rechnung so schreibt, wie das Gesetz verlangt, ein Standard-Verkaufs-CRM, eine Lernplattform, die Kurs und Abschluss erfasst, und ein kleiner Shop mit einem Preis und einem Lager sind Orte, an denen der Bau nichts gibt, wofür sich die Differenz zwischen Lizenz und Sprint zu zahlen lohnte. Diese Zeilen verkaufen wir nicht als „Zwischenlösung, bis Sie für das richtige System bereit sind“, denn sie sind die richtigen Systeme für diese Prozesse.

Wir verkaufen diese Produkte auch, und das ist kein verstecktes Versprechen, dass nach einem Jahr der Bau kommt: WordPress bleibt eine Content-Plattform mit einem Theme, das wir schreiben, nicht mit einem fertigen Theme aus dem Laden; für einen kleinen Shop mit Standardprozessen sagen wir selbst WooCommerce; Moodle bleibt eine Lernplattform, die wir konfigurieren, migrieren und gestalten, nicht von vorn erfinden. Die Preise dieser Zeilen stehen auf den Leistungsseiten und an einer Stelle weiter unten in diesem Artikel, wo sich zeigen muss, dass die Untergrenze der Individualsoftware nicht automatisch die teuerste Zeile ist, und hier reicht zu sagen, dass das Produkt Produkt bleibt.

Die Folge, wenn Sie an dieser Stelle trotzdem einen Bau bestellen, ist nicht „bessere Kontrolle“, sondern eine Wartung, die Sie nicht mehr mit Tausenden anderen teilen, denn den Sicherheitspatch des Mailprogramms gibt jemand für alle heraus, den Patch Ihres eigenen Mailprogramms geben Sie heraus, und das klingt nach Freiheit, solange nicht die zweite Nacht kommt, in der Sie reparieren müssen, was der Hersteller in seinem Produkt schon repariert hat. Diese Freiheit verkaufen wir dort, wo der Prozess sie verdient, nicht dort, wo eine Lizenz reicht, denn sonst verkaufen wir Ihnen Arbeit, die Sie nach einem Jahr als teures Duplikat hassen werden.

Deshalb ist das Ehrlichste, das wir vor jeder nicht standardisierten Schätzung sagen können, eine Liste von Produkten, die wir Ihnen stattdessen empfehlen würden: ist der Prozess Lernen, beginnen Sie mit Moodle, ist der Prozess Inhalt, beginnen Sie mit WordPress, ist der Prozess ein kleiner Shop, beginnen Sie mit WooCommerce, und ist der Prozess Rechnungen und die gesetzlich vorgeschriebene Buchführung, beginnen Sie mit der Buchhaltung, die Sie schon haben, und fragen Sie erst dann, ob etwas davon ein eigenes System werden muss. Diese Liste ist kein Partnervertrag, sie ist ein Test, den wir gegen uns selbst verwenden.

Wann Individualsoftware gerechtfertigt ist

Individualsoftware ist gerechtfertigt, wenn der Prozess Teil Ihres Wettbewerbsvorteils ist oder Standardlösungen zu viele Kompromisse verlangen, und der Prozess kann der Ware untergeordnet bleiben und trotzdem Teil dieses Tests sein, denn der Test ist die Zahl der Kompromisse, nicht ob Sie Software verkaufen. Wenn das Standardprodukt zu verlangen beginnt, dass Sie der durchschnittliche Kunde werden, und der durchschnittliche Kunde nicht Ihr Wettbewerbsvorteil ist, dann ist der Bau endlich ein Test, den der Prozess bestanden hat, und nicht der Wunsch nach einem eigenen Bildschirm.

Integration ist hier kein Argument für sich, denn Produkte haben ebenfalls Schnittstellen, und wir schließen sie an, und das Argument beginnt erst, wenn die Schnittstelle nicht reicht und der Prozess verlangt, dass die Wahrheit über Bestand, Preis oder Status an einem Ort lebt, den Sie steuern. Das Kartenportal von Sadales tīkls, das wir auf Laravel und Leaflet gebaut haben, zeigt Abschaltungen, freie Netzkapazität und die Anschlusskosten, und das ist nicht „Karte plus Plugin“, weil Gebühr und Kapazität der Prozess des Betreibers sind, nicht das Feld eines Kartenprodukts; im Elektrum-Portal hängt sich die SSO-Sitzung an jede Anfrage, bevor der Vue-Konfigurator zeichnet, und das ist kein „Energie-Theme für WordPress“, weil die Sitzung Teil des Dienstes ist, nicht Dekoration.

Farbe, Logo und die Anordnung des Menüs sind nicht dieser Test, denn das lässt sich im Produkt tun, und wir tun es im Produkt: ein Moodle-Theme mit Ihrer Palette, ein WordPress-Theme ohne Überfluss, ein WooCommerce-Shop, der nach Ihnen aussieht. Ist das Einzige, was sich im Standardwerkzeug nicht tun lässt, „dass es nach uns aussieht“, sind Sie nicht bei Individualsoftware angekommen, sondern bei einem Theme, und diese zwei Dinge zu vermischen heißt, für einen Bau zu zahlen, wo Design reicht, und sich danach zu wundern, warum die Wartung für ein System teuer ist, dessen einziger Unterschied die Farbe ist.

Wir sagen auch nicht, dass jede Branche automatisch eine eigene Plattform verlangt, denn der Branchenname ist kein Test, und der Test ist, ob der Prozess dieser Branche in Ihrem Unternehmen derselbe ist, den der Hersteller schon ins Paket gelegt hat, oder ob es Ihre Art ist, wie die Branche arbeitet, und diese Art sich nebenan nicht kaufen lässt. Wenn man sie kaufen kann, kaufen Sie; wenn nicht, dann geht es um ein individuelles Geschäftssystem, und erst dann lohnt der Discovery-Workshop, nicht das Theme.

Der dritte Weg: das Produkt mit unserem Code darüber

Zwischen dem Standardprodukt und dem Bau von Grund auf liegt ein dritter Weg, den wir ebenfalls verkaufen und den Vergleiche am häufigsten auslassen: das Produkt bleibt Produkt, und darüber schreiben wir, was das Produkt nicht tut, und das ist nicht „ein bisschen Individualsoftware“, sondern die Entscheidung, den Kern dort zu lassen, wo ihn der Hersteller wartet, und nur die Schicht zu schreiben, die die Ihre ist. Das Serviceportal von Sadales tīkls steht auf October CMS, und Rechner, Kalender und die Störungsmeldung sind Arbeit auf dem Produkt, kein neuer Content-Kern; in einer Moodle-Einführung prüfen wir zuerst, ob das Bewertungs- oder Berichts-Plugin schon existiert, und schreiben erst dann unser eigenes, denn sonst verkaufen wir Ihnen ein Duplikat.

Ist die Frage Katalog, Preise, Bestellung und Lieferung, ist das der Shop-Test, und der ist schon in dem Beitrag über die Wahl zwischen WooCommerce und Laravel geschrieben, deshalb schreiben wir ihn hier nicht um und machen ihn nicht zum Standard eines nicht standardisierten Systems. Ist die Frage ein CRM, ein ERP, ein internes Panel oder ein Branchenprozess, bleiben Sie in diesem Artikel, denn der Shop ist nur ein Fall desselben Tests, nicht der ganze Inhalt der Wahl.

Auf der WordPress-Seite sieht der dritte Weg nach einer Absage aus, denn fertige Themes setzen wir nicht, sie bringen Funktionen mit, die zum Sicherheitsrisiko werden, und wir bauen ein sauberes Theme nur mit dem, was nötig ist, und das bleibt ein Produkt: die Redaktion schreibt in WordPress, nicht in einem von uns erfundenen Editor, und die Updates kommen von WordPress, nicht aus unserem einen Release. Der Unterschied zwischen diesem Weg und einem individuellen System ist, dass der Inhaltsprozess ins Produkt passt, der Theme-Prozess aber nicht in ein ThemeForest-Theme, und sie zu vermischen heißt entweder ein fremdes Theme zu setzen und sich danach über Plugins zu wundern, oder ein eigenes CMS für Inhalt zu bauen, für den ein CMS schon existiert.

Diese Grenze ist auch die Stelle, an der wir nein sagen zu einem „kleinen Umbau“, der nach dem dritten Monat der Kern ist, denn wenn die Anpassungen mehr werden als die Konfiguration, wenn jedes Update zuerst unseren Code verlangt, wenn das Feld des Herstellers nicht mehr die Wahrheit ist, sind Sie nicht mehr auf dem dritten Weg. Sie sind auf einem Bau, der sich hinter dem Produktnamen versteckt, und dann ist es ehrlicher, den Bau zu nennen und ihn als Bau zu rechnen, denn sonst zahlen Sie für ein Produkt, das sich nicht mehr aktualisieren lässt, und für ein System, das sich noch nicht übernehmen lässt.

Geld und Zeit sind eine Form, kein Preisverzeichnis

Ein individuelles System beginnt bei uns ab 8.000 €, und der volle Zyklus dauert in der Regel 12–32 Wochen, und das ist ein „ab“, keine Rechnung, und 12 Wochen sind nicht dieselben ersten drei Monate, in denen wir ein nutzbares MVP versprechen: die Untergrenze ist der kürzeste Bau, das MVP ist der Schritt, nach dem das System schon genutzt wird, und 32 Wochen sind die Obergrenze einer größeren Arbeit, die auch in das fällt, was wir in der allgemeinen FAQ für ein großes individuelles System mit sechs bis acht Monaten nennen. Die Laravel-Seite beginnt bei derselben Untergrenze von 8.000 € und 6–24 Wochen, und das ist keine günstigere Individualsoftware: das ist die Seite für den Menschen, der schon weiß, dass die Arbeit Laravel ist, nicht der Test, ob die Arbeit überhaupt ein Bau ist.

Diese Zahlen dürfen nicht zu dem Satz werden „Individualsoftware ist die teuerste Wahl“, denn eine Moodle-Einführung beginnt ab 15.000 €, die Pro-Version des Shops kostet 9.500 €, und beide liegen über der Untergrenze der Individualsoftware, weil das eine die Einführung eines großen Produkts ist, das andere ein Shop mit Lager und B2B-Preisen. Die Untergrenze von 8.000 € mit der Moodle-Untergrenze als „Bau gegen Produkt“ zu vergleichen ist falsche Arithmetik, denn vergleichen lassen sich nur zwei Wege desselben Prozesses, und selbst dann sind beide Seiten Untergrenzen, keine Summen; bei größeren nicht standardisierten Arbeiten rechnen wir nach dem Time-and-Materials-Modell mit Wochenobergrenze, weil ein Festpreis dort meist einen Risikoaufschlag oder Streit über den Umfang bedeutet, und der Stundensatz beträgt 50 €.

Abonnement gegen Bau ist auch keine Formel, in der nach N Jahren eine Seite automatisch gewinnt, und in der öffentlichen Planung taucht dasselbe auf, was wir in privaten Verträgen sehen: die SaaS-Gebühr kann mit der Nutzerzahl oder der Indexierung steigen, Integrationen bleiben Ihre Kosten, und für den Wechsel des Anbieters braucht es einen Ausstiegsplan, weil die Daten bei ihm liegen. Das ist kein Prozentsatz vom Bau, den wir hier zitieren würden, weil solche Fußnoten oft auf Anbieterblogs führen, und solche Zahlen schreiben wir nicht, aber die Form bleibt: das Abonnement ist jedes Jahr eine Zeile, der Bau ist eine Untergrenze plus Wartung, und keine der beiden ist ohne Zeile.

Die Datenverordnung, die in der Union ab dem 12. September 2025 gilt, hilft, exportierbare Daten aus einem Cloud-Dienst herauszuholen, und verbietet dem Anbieter, dem Wechsel Hindernisse in den Weg zu legen, aber die Funktionsäquivalenz verlangt sie nur für einen Infrastrukturdienst (IaaS), nicht für ein CRM, das Sie einfach „mitnehmen“, und die Verordnung 2023/2854 verspricht nicht, dass der Prozess mit der Datei umzieht. Artikel 20 der Datenschutz-Grundverordnung (DSGVO) überträgt personenbezogene Daten, die die betroffene Person bereitgestellt hat, nicht die Anwendung, nicht Ihre Konfiguration, nicht die Geschäftsregeln, deshalb ist ein System, das Sie zu einem anderen Entwickler mitnehmen können, der Quellcode, den wir übergeben, nicht der Export aus einem fremden Panel, und hier endet dieser Abschnitt, weil der nächste Satz schon ein Preisverzeichnis wäre, das wir für diese Frage nicht haben.

Was wir nicht sagen, wenn wir über Individualsoftware sprechen

Wir sagen nicht, dass ein eigenes System immer klüger ist, dass das Standardprodukt für jene ist, die „noch nicht gewachsen sind“, oder dass sich der Bau nach drei Jahren bestimmt amortisiert hat, denn eine solche Kurve ohne Ihren Prozess ist eine Erfindung. Ein Artikel, der nach einem ehrlichen Anfang trotzdem dabei ankommt, dass man den Bau kaufen muss, ist zu weit gegangen, und das haben wir oft genug gesehen, um hier stehenzubleiben, denn Ehrlichkeit ist eine Begrenzung und ein kurzer Test ist das Ziel.

Wir sagen auch nicht, dass Laravel die Antwort auf die Frage nach dem Standardprodukt ist, denn Laravel ist die Art, wie wir schreiben, wenn der Test schon den Bau ergeben hat, und einem Menschen, der Moodle braucht, ein Framework zu verkaufen heißt, einem Menschen, der ein Regal braucht, einen Hammer zu verkaufen. Unsere Laravel-Seite beginnt ab 8.000 € und spricht von APIs, Queues und Tests, aber dieser Artikel spricht davon, ob Sie diese Seite überhaupt brauchen, und sie zu vermischen heißt, das Instrument zu wählen, bevor Sie die Arbeit gewählt haben.

Wir sagen auch nicht, dass der Discovery-Workshop ein versteckter Weg ist, Sie in einen Bau zu führen, denn das Ergebnis des Workshops ist ein Plan, der auch dann nützlich bleibt, wenn Sie sich gegen uns entscheiden, und manchmal sagt der Plan: nehmen Sie das Produkt, das Sie schon benannt haben, und wir führen es ein, oder jemand anderes führt es ein. Wenn Ihnen dieser Satz nach einem verlorenen Geschäft klingt, dann deshalb, weil er ein verlorenes Geschäft ist, und wir verlieren lieber einen Bau, in dem noch ein CRM geschrieben werden müsste, als einen Kunden zu gewinnen, der nach einem Jahr fragt, warum er ein System wartet, das er hätte abonnieren können.

Für die öffentliche Vergabe funktioniert dieser Test nicht genauso wie für eine private Firma, und er lässt sich nicht einfach übertragen, denn in der öffentlichen Planung wird oft verlangt zu prüfen, ob am Markt schon eine fertige Lösung existiert, und das gehört zur Vergabe, nicht zu diesem Satz, aber auf der privaten Seite gehören dazu Ihr Prozess und unser Preisverzeichnis. Beide Seiten können bei derselben Antwort ankommen, und sie kommen nicht dort an, weil die eine das Gesetz der anderen wäre.

Wie diese Entscheidung bei uns getroffen wird

Die Arbeit beginnt mit einem zwei- bis dreitägigen Discovery-Workshop, in dem wir mit Ihrem Team Prozesse, Nutzerrollen, Risiken und den MVP-Umfang durchsprechen, und das ist kein Folienvormittag, sondern Arbeit, nach der wir sagen können, ob der Prozess in ein Standardwerkzeug passt, ob er den dritten Weg verlangt oder ob er ein Bau ist. Ist die Antwort das Produkt, hat sich der Workshop mit diesem Satz amortisiert; ist die Antwort der Bau, ist der nächste Schritt nicht Code.

Vor dem Produktionscode bereiten wir in zwei bis drei Wochen einen klickbaren Prototyp vor, denn dort ist Umdenken günstiger als im fertigen System, und der Prototyp ist nicht „damit die Geschäftsleitung etwas zu sehen hat“, sondern der Ort, an dem Sie sehen, dass die Preistabelle, die Sie gestern benannt haben, in Wahrheit eine andere Tabelle ist, und an dem diese Einsicht Tage kostet, nicht Monate. Erst danach beginnt die Entwicklung: in den ersten drei Monaten bauen wir ein MVP, das sich wirklich nutzen lässt, und danach erweitern wir iterativ, in Zwei-Wochen-Sprints mit einer Demo nach jedem.

Am Ende erhalten Sie Quellcode, Dokumentation und die Infrastruktur-Konfiguration und können das zu einem anderen Entwickler mitnehmen, und das ist kein Versprechen, dass der Umzug angenehm wird, sondern das Versprechen, dass Sie nicht an unser Konto gebunden sind. In größeren Projekten bleiben wir beim Time-and-Materials-Modell mit Wochenobergrenze, und die MVP-Grenze legen wir trotzdem fest, denn sonst wird „agile“ zu einem Wort, hinter dem der Umfang verschwindet, und wenn Sie nach dem Workshop einen anderen Weg gehen, bleibt der Plan bei Ihnen, wie wir es auf der Leistungsseite geschrieben haben, und dieser Artikel ändert daran nichts.

Bevor Sie uns schreiben, schreiben Sie den Prozess auf einer Seite ohne Werkzeugnamen auf und markieren Sie, welche Zeilen Sie keinem fremden Release überlassen dürfen: ist die Seite leer oder steht darauf nur „damit wir ein eigenes System haben“, brauchen Sie ein Produkt, und das werden wir auch sagen, steht auf der Seite aber ein Prozess, den der Wettbewerber nicht als Standardwerkzeug kaufen kann, dann lohnt das Gespräch über einen Bau. Schreiben Sie uns, wenn Sie wollen, dass wir diese Seite mit Ihnen lesen und sagen, welche Seite die Ihre ist, auch dann, wenn die Antwort lautet, das Produkt zu nehmen, das Sie schon benannt haben.