Maßgefertigte Softwareentwicklung.

01

Was wir bauen.

Interne Werkzeuge und Betriebsplattformen.

Tabellenkalkulationen, manuelle Prozesse und unverbundene SaaS-Abos werden durch konstruierte Systeme ersetzt, die den Betrieb zusammenführen und mit dem Wachstum des Teams skalieren.

Integration und Middleware.

Verbindung von Systemen, die miteinander sprechen müssen — ERP zu E-Commerce, CRM zu Abrechnung, Drittanbieter-APIs zu internen Daten — durch zuverlässige Middleware, auf Dauer entwickelt.

Kundenseitige Anwendungen und Plattformen.

Webanwendungen und Plattformen, die Geschäfte vor ihre Kunden stellen, gebaut auf dem Niveau, an dem das Geschäft selbst gemessen werden will.

Websites und digitale Oberflächen.

Für Geschäfte, in denen die Website das Geschäft ist — gebaut mit derselben architektonischen Disziplin wie die größeren Systeme, die wir liefern.

02

Wie wir arbeiten.

Aufgaben beginnen mit einer Diagnose. Bevor wir einen Bau vorschlagen, wollen wir die Arbeit verstehen, die die Software tragen soll — die Menschen, die sie nutzen werden, die Systeme, neben denen sie lebt, die echten Einschränkungen und die ererbten. Diese Untersuchung prägt den Umfang der Arbeit; sie prägt auch die Form der Aufgabe: wo das Eigentum sitzt, welcher Rhythmus gilt, wie Entscheidungen getroffen werden, was Übergabe bedeutet. Die Antwort ist selten zweimal die gleiche. Drei Formen kommen wieder vor, an die Arbeit angepasst, nicht ihr aufgezwungen.

Vollständige Entwicklung.

Wir tragen die Verantwortung für die Arbeit vom ersten Gespräch bis zum Start und in die Zeit, die folgt. Design und Entwicklung sitzen unter einem Dach, was Entscheidungen in der Nähe der Menschen hält, die sie treffen, und die Reibung beseitigt, die zwischen getrennten Firmen üblich ist. Das Tempo bestimmt sich nach dem, was die Arbeit braucht: frühe Erkundung und architektonische Entscheidungen; iterativer Bau mit eng beteiligtem Kunden; Veröffentlichung in den Produktivbetrieb, wenn das System bereit ist, nicht wenn ein Kalender es sagt. Nach dem Start bleiben wir mit dem System — nicht als Selbstzweck-Pauschalvertrag, sondern um es zu betreiben, an der Nutzung zu verfeinern und es weiterzuentwickeln, während sich das Geschäft ändert.

Eingebettete Aufgabe.

Wo ein Kunde ein internes Team hat, arbeiten wir an seiner Seite, nicht an seiner Stelle. Die Form variiert — Kapazität für einen definierten Vorstoß, architektonische Beratung durch eine folgenreiche Entscheidung, dauerhafte Partnerschaft durch eine mehrquartalige Modernisierung. Die Disziplin bleibt gleich. Wir integrieren uns in die Werkzeuge, Arbeitsmuster und Entscheidungsrechte des Teams. Wir importieren keinen parallelen Prozess. Wir sind verantwortlich für die Arbeit, die wir tun; wir übernehmen keine Arbeit, die dem Kunden gehört. Eingebettete Aufgaben beginnen oft mit einem diagnostischen Gespräch, da die richtige Form der Partnerschaft erst klar wird, sobald die Arbeit verstanden ist.

Diagnostische Aufgabe.

Die kürzeste Aufgabe, die wir anbieten, ist eine fokussierte Untersuchung: das System, das Team, die Einschränkungen und der Weg nach vorn, ehrlich geprüft und zurückberichtet. Das Ergebnis ist eine schriftliche Bewertung — die Empfehlung, die wir geben würden, wenn wir die Verantwortung für die Arbeit trügen, einschließlich der Fälle, in denen die Empfehlung lautet, weniger zu tun, oder etwas anderes als zu bauen. Sie kann für sich stehen; sie kann in eine der oben genannten Formen führen; sie kann zu der Empfehlung führen, dass wir nicht die richtige Firma sind. Die Diagnose ist die eine Stelle, an der die Arbeit manchmal in einem Absatz statt in einem System endet, und wo nicht bauen manchmal die richtige Empfehlung ist.

Diese Formen schließen einander nicht aus. Was bleibt, ist, dass die Form der Aufgabe an die Arbeit angepasst ist, die das Geschäft braucht, dass das Eigentum am Code beim Kunden bleibt, und dass das Gespräch mit dem beginnt, was wahr ist.

03

Wann maßgefertigte Software das Richtige ist.

Maßgefertigte Software verdient ihren Platz, wenn die Arbeit für das Geschäft spezifisch ist, langlebig genug, um die Investition zu rechtfertigen, und folgenreich genug, dass es teuer ist, falsch zu liegen. Eine eigens gebaute interne Plattform ist sinnvoll, wenn die Abläufe, die sie ausführt, kernhaft für das Geschäft sind und nicht durch ein konfiguriertes SaaS-Abo bedient würden. Eine maßgefertigte Integration ist sinnvoll, wenn die Systeme, die Daten austauschen sollen, zu unterschiedlich sind, als dass eine fertige Middleware sie handhaben könnte. Eine zweckgebaute kundenseitige Anwendung ist sinnvoll, wenn die Erfahrung selbst das Produkt ist, oder ein Teil davon, und eine vorgefertigte Alternative die Arbeit verzerren würde.

Sie verdient ihren Platz nicht überall. Ein kleines Geschäft, das von einem Shopify-Shop gut bedient wäre, braucht keine maßgefertigte Handelsplattform. Ein Team, das eine intelligentere Art zu projektmanagement braucht, ist meist besser durch ein konfiguriertes Notion oder Asana bedient als durch ein von Grund auf gebautes System. Ein Arbeitsablauf, der in drei Tabellenkalkulationen lebt, wird manchmal gelöst, indem man die Tabellen durch ein bereits existierendes Werkzeug ersetzt; manchmal durch ein konstruiertes System, das sie zusammenführt; und manchmal dadurch, dass man prüft, ob der Arbeitsablauf selbst das Problem ist. Die richtige Antwort ist nicht immer, zu bauen.

Wir haben diagnostische Aufgaben mit der Empfehlung beendet, bestehende Software zu abonnieren, einen Prozess umzugestalten bevor er automatisiert wird, und — ein- oder zweimal — gar nichts zu tun. Die Arbeit, die wir ablehnen, ist kein Versagen des Gesprächs; sie ist oft das nützlichste Ergebnis, das das Gespräch bringen konnte.

Beispiel — Eine repräsentative Plattform-Aufgabe

Umfang

Kundenseitige Oberfläche, interne Abläufe, Integrationsschicht

Integrationen

3–6 Drittsysteme, typisch

Ablauf

~14 Wochen erste Version, laufende Wartung

Eigentum

Kunde besitzt den Quellcode · Wartung durch Serdica

Bewertet an

Leistung, Zuverlässigkeit, Geschäftsergebnisse