Zum Inhalt springen
Blog
vector zero Build

Build statt Buy

KI verschiebt die Make-or-Buy-Frage spürbar Richtung Make. Software bauen kann heute fast jeder. Die eigentliche Frage ist, ob daraus produktionsreife Software wird, die dem Unternehmen gehört.

Holger Baten1. Juni 20263 Min. Lesezeit
Illustration zu eigener, wartbarer Codebasis mit vector zero Build
Bereich
Build
Lesezeit
3 Min.
Veröffentlicht
1. Juni 2026
Autor
Holger Baten

Immer mehr Unternehmen bauen ihre Software selbst, statt sie einzukaufen. Erst kürzlich haben wir von einem großen deutschen Cloud-Anbieter erfahren, der sein eingekauftes CRM-System durch eine Eigenentwicklung ersetzt hat, noch vor einem Jahr wäre das keine wirtschaftliche Option gewesen.

Genau in diesem Geist haben wir vector zero Build entwickelt. Anders als bei Self-Service-Tools wie Lovable, bei denen ein Unternehmen selbst zum Entwickler wird, übernehmen wir die Entwicklung der ersten Version in einem professionellen Umfeld und liefern eine lauffähige, wartbare Anwendung. Und wie bei einer klassischen Auftragsentwicklung gehört der Code am Ende vollständig Ihnen und kann von Ihrem Team weiterentwickelt werden.

Was Kunden mit vector zero Build bauen

In den letzten Monaten haben wir genau beobachtet, was dabei entsteht. Fast immer sind es interne Werkzeuge, dort, wo die Kluft zwischen dem, was ein Standardanbieter kann, und dem, was der Betrieb wirklich braucht, am größten ist. Sieben Kategorien begegnen uns besonders oft.

  • Workflow-Automatisierung: die Werkzeuge, die Anwendungen verbinden, Aktionen auslösen und Daten zwischen Systemen bewegen. Werden die Abläufe mehrstufig, greifen sie auf Produktivdatenbanken zu und brauchen echte Fehlerbehandlung, stößt man entweder an die Grenzen gekaufter Plattformen oder baut Umwege, die ihren eigentlichen Zweck wieder zunichtemachen.
  • Interne Verwaltungs- und Betriebstools: eines für Benutzerkonten, eines für Erstattungen, eines für Freigaben. Häufig genutzt, technisch überschaubar, eng an den eigenen Prozess gebunden und nicht für Kunden bestimmt. Ideale Kandidaten für eine Eigenentwicklung. Sie müssen nur an die richtigen Daten andocken und die richtigen Regeln durchsetzen.
  • Operative Dashboards: nicht die tiefe, explorative Analyse des Datenteams, sondern die Auswertungen, die Vertrieb, Support, Betrieb und Finanzen täglich brauchen. Solche Tools rechnen oft pro Nutzer ab, ein widersinniger Anreiz, wenn man möchte, dass möglichst viele Zugriff auf ihre Zahlen haben. Eine eigene Lösung zieht direkt aus der Datenbank, verknüpft Auswerten mit Handeln und kostet nichts pro Kopf.
  • CRM-nahe Anwendungen: Das führende System bleibt, aber kaum eine Kategorie ist so überlizenziert. Statt jeden Ablauf ins CRM zu zwängen, setzt man gezielte Anwendungen darauf: ein Deal-Board für die Geschäftsführung, einen Provisionsrechner fürs Controlling, eine schlanke CRM-Ansicht für alle, die nicht die volle Lizenz benötigen.
  • Erfassung und Freigaben: Das übliche Bild sind ein Formularwerkzeug zum Erfassen, ein zweites fürs Weiterleiten und ein drittes fürs Genehmigen, drei Abonnements für einen einzigen Ablauf. Eine eigene Anwendung führt das zusammen: dynamische Formulare auf Basis echter Daten, Prüfung gegen die eigenen Regeln, Weiterleitung nach klarer Logik, lückenlose Protokollierung.
  • Projekt- und Aufgabensteuerung: nicht das Sprint-Board der Entwickler, sondern die Zweitwerkzeuge, mit denen Teams außerhalb der Entwicklung ihre operative Arbeit organisieren und bis zur Unkenntlichkeit verbiegen. Eine maßgeschneiderte Anwendung bildet genau die Felder, Status und Ansichten ab, die der Prozess verlangt, und zeigt den Stand automatisch aus den echten Daten.
  • Interne Help-Desks: Mitarbeitende reichen Anfragen ein, ein Team nimmt sie auf und löst sie. Dafür eine vollwertige Kundensupport-Plattform zu kaufen, ist überdimensioniert und teuer. Ein eigener Service-Desk greift direkt auf die relevanten Systeme zu, Personalverwaltung, Geräte, Zugänge, und erledigt den Ablauf ohne überflüssigen Ballast.

So entsteht die Software

So unterschiedlich diese Anwendungen sind, das Vorgehen bleibt dasselbe. Wir entwickeln auf einer durchgängigen Pipeline: Claude Code für die Entwicklung, GitHub für Prüfungen und Versionierung, Vercel für das Deployment, und übergeben eine lauffähige Anwendung, Anmeldung per Magic Link eingebaut, Rollen und Rechte gesetzt. Kein Prototyp auf der grünen Wiese, sondern ein belastbares Fundament, das dem Kunden gehört und das er selbst weiterentwickeln kann.

Agentic Engineering im Team verankern

Wir liefern Governance, Reviews und ein Setup, in dem die KI auf Ihren echten Projektdokumenten arbeitet, damit Ihr Team nach der Übergabe sicher weiterbaut.

Projekt besprechen