Wie eine Person ein Tool für 40.000 $/Jahr durch etwas ersetzte, das sie an einem Tag baute

Marta leitete Operations für ein Logistikunternehmen mit 30 Mitarbeitenden in Guadalajara. Ihr Team nutzte eine Enterprise-Projektmanagement-Plattform, die sie rund 40.000 $ im Jahr kostete — Lizenzierung pro Platz, Premium-Stufe für die Reporting-Features, plus eine:n Berater:in, den oder die sie vor zwei Jahren engagiert hatten, um die ursprünglichen Workflows einzurichten.

Hier ist die Sache, die niemand im Team laut sagen wollte: Sie nutzten vielleicht 15 % davon.

Fahrer:innen protokollierten ihre täglichen Routen im Tool. Disponent:innen checkten ein Kanban-Board, um zu sehen, wer verfügbar war. Marta zog einen Wochenbericht, der pünktliche Lieferungen und offene Probleme zeigte. Das war’s. Die Gantt-Charts, das Resource Leveling, die Sprint-Planung, das Zeit-Tracking und die Portfolio-Dashboards? Die rührte niemand an. Sie zahlten für ein Schweizer Taschenmesser, um Briefumschläge zu öffnen.

Der Moment, in dem es klick machte

Die Vertragsverlängerung stand im Februar an. Marta hatte sich über ein Jahr lang eingeredet, sie würde “nächstes Quartal” auf etwas Günstigeres migrieren. Aber diesmal sagte ihr eine Freundin, die eine kleine E-Commerce-Marke führte, etwas, das hängenblieb: “Ich habe aufgehört, nach dem richtigen Tool zu suchen, und einfach einer KI beschrieben, was ich brauchte. Sie hat es gebaut.”

Marta war keine Entwicklerin. Sie hatte mal einen Python-Kurs gemacht und ihn nach Woche drei abgebrochen. Aber sie verstand ihre eigenen Workflows besser als alle anderen. Sie konnte genau beschreiben, was ihr Team brauchte, weil sie jeden Tag in diesen Prozessen lebte.

Sie beschloss, vor der Unterschrift der Verlängerung selbst einen Ersatz zu bauen.

Was sie tatsächlich baute

Marta setzte sich an einem Samstagmorgen mit einem KI-App-Builder hin und fing an zu beschreiben, was sie brauchte, ein Stück nach dem anderen.

Ein Bildschirm zum Routen-Protokollieren. Fahrer:innen mussten zu Schichtbeginn einchecken, ihre zugewiesenen Stopps sehen und jeden als abgeschlossen markieren. Kein Drag-and-Drop-Gantt-Quatsch — nur eine Liste mit Checkboxen und einem Zeitstempel. Sie beschrieb das in einfachem Spanisch und sah zu, wie der App-Builder eine funktionierende Oberfläche mit einer Datenbank dahinter generierte.

Ein Disponenten-Dashboard. Eine einzige Seite, die zeigte, welche Fahrer:innen aktiv waren, wie viele Stopps sie noch hatten und eine farbcodierte Anzeige, ob sie im Plan lagen. Marta beschrieb die Logik: grün, wenn sie bis Mittag mindestens 60 % der Stopps geschafft hatten, gelb zwischen 40 und 60 %, rot darunter. Der Builder übersetzte das in bedingte Formatierung und eine sich live aktualisierende Ansicht.

Ein Wochenbericht. Die Zahlen, die Marta tatsächlich jeden Freitag zog: Gesamtlieferungen, Pünktlichkeitsquote, von Fahrer:innen gemeldete Probleme (wie eine falsche Adresse oder ein:e nicht angetroffene:r Kund:in) und ein Vergleich zur Vorwoche. Sie bat den Builder, eine Zusammenfassungstabelle und ein einfaches Balkendiagramm zu generieren. Er tat es.

Ein einfacher Issue-Tracker. Wenn ein:e Fahrer:in etwas meldete — falsche Adresse, beschädigtes Paket, Kundenbeschwerde —, musste es irgendwohin, wo Marta es sehen und zuweisen konnte. Kein vollständiges Ticketing-System. Nur eine Liste mit einem Status (offen / in Arbeit / gelöst) und der Möglichkeit, eine Notiz hinzuzufügen.

Das Ganze dauerte etwa acht Stunden, verteilt über den Samstag. Nicht weil irgendein einzelnes Stück schwer war, sondern weil Marta immer weiter verfeinerte. Die erste Version des Disponenten-Dashboards zeigte zu viele Daten. Sie kürzte es. Der Routen-Protokoll-Bildschirm brauchte eine “Stopp überspringen”-Option, an die sie zunächst nicht gedacht hatte. Sie fügte sie hinzu, indem sie die Änderung beschrieb.

Was 40.000 $ tatsächlich kaufte

Als Marta ihre Vier-Bildschirm-App mit der Enterprise-Plattform verglich, war die Lücke offensichtlich — aber nicht in der Richtung, die sie erwartet hatte.

Das Enterprise-Tool hatte Hunderte von Features und brauchte eine:n Berater:in zum Konfigurieren. Martas App hatte vier Bildschirme, die direkt darauf abgebildet waren, wie ihr Team schon arbeitete. Keine Schulung nötig. Keine Konfigurations-Schuld.

Aber die echten Kosten des Enterprise-Tools waren nie das Abo. Es war die Reibung, um die ihr Team jeden Tag herumarbeitete. Disponent:innen koordinierten über WhatsApp, weil die Mobile-App der Plattform vier Taps brauchte, um einen Lieferstatus zu aktualisieren. Marta pflegte ein separates Google Sheet für den Wochenbericht, weil das eingebaute Reporting-Modul drei Menüs durchklicken verlangte, um dieselben fünf Zahlen zu ziehen. Die Fahrer:innen hatten sich eine Workaround-Seite in der Hilfe-Doku für den Routen-Protokoll-Bildschirm gebookmarkt, weil der Standardablauf Projektphasen annahm, die sie nicht nutzten.

Martas App hatte keine Workarounds, weil sie aus den Workarounds gebaut war. Jeder Bildschirm existierte, weil jemand im Team diese Aufgabe informell erledigt hatte — auf WhatsApp, in einer Tabelle, auf einem Whiteboard —, und Marta beschrieb dem Builder einfach die informelle Version.

Die Teile, die sie überraschten

Drei Dinge, die Marta nicht erwartet hatte:

Iteration war schnell. Als ein:e Fahrer:in vorschlug, jedem Stopp ein Notizfeld hinzuzufügen, beschrieb Marta die Änderung in ihrer Mittagspause dem Builder und deployte sie noch am selben Nachmittag. Mit dem Enterprise-Tool gingen solche Änderungen durch eine Support-Ticket-Warteschlange und dauerten manchmal Wochen.

Ihr Team nahm es sofort an. Keine Schulungen. Kein “bitte schaut euch dieses Onboarding-Video an”. Die Disponent:innen öffneten es am Montagmorgen und verstanden es, weil es aussah wie das Whiteboard, das sie informell genutzt hatten, nur digital.

Sie verbesserte es immer weiter. In den nächsten zwei Wochen fügte sie einen fünften Bildschirm hinzu: eine Monatsansicht für ihren Chef, die Liefertrends und Schätzungen der Kosten pro Route zeigte. Mit dem Enterprise-Tool wäre das eine individuelle Bericht-Anfrage gewesen. Mit ihrer eigenen App war es ein 20-minütiges Gespräch mit dem Builder.

Was das nicht ist

Das ist keine Geschichte darüber, dass Enterprise-Software schlecht ist. Wenn du ein Unternehmen mit 500 Mitarbeitenden bist, das komplexe funktionsübergreifende Projekte mit Abhängigkeiten, Ressourcenbeschränkungen und Compliance-Anforderungen fährt, brauchst du wahrscheinlich dieses Schweizer Taschenmesser.

Aber wenn du ein 30-köpfiges Team bist, das 15 % eines Tools nutzt, das mehr kostet als eine:r deiner Mitarbeitenden, läuft etwas schief. Das Tool ist nicht das Problem — die Fehlpassung ist es.

Und diese Fehlpassung war früher unvermeidlich. Bevor du eine App ohne Programmieren bauen konntest, waren deine Optionen: für das große Tool zahlen, etwas in Tabellen zusammenflicken oder eine:n Entwickler:in engagieren, um maßgeschneiderte Software zu bauen (was eigene Kosten und Zeitrahmen mit sich bringt). Jetzt gibt es eine vierte Option: beschreiben, was du brauchst, und es selbst bauen.

Die Rechnung

Martas Zahlen nach einem Monat:

• Enterprise-Tool: ~3.300 $/Monat (40.000 $/Jahr)
• KI-App-Builder-Abo: unter 100 $/Monat
• Zeit zum Bauen: 8 Stunden (ein Samstag)
• Zeit zum Iterieren: 20-30 Minuten pro Änderung
• Zeit zur Team-Adoption: null — sie hatten es am ersten Tag

Sie brauchte keine:n CTO und kein Entwicklungsteam. Sie brauchte, zu beschreiben, wie ihr Team tatsächlich arbeitet — und einen KI-App-Builder, der diese Beschreibung in funktionierende Software verwandelte.

Worüber du nachdenken solltest

Wenn du deine eigene Situation in Martas Geschichte wiedererkennst, hier eine nützliche Übung vor deiner nächsten Software-Verlängerung: Schreib jedes Feature auf, das du in deinem aktuellen Tool tatsächlich nutzt. Nicht die Features, von denen du denkst, du solltest sie nutzen, oder die du irgendwann nutzen willst. Die, die dein Team jede Woche berührt.

Wenn diese Liste auf einen Klebezettel passt, zahlst du vielleicht zu viel für Komplexität, die du nicht brauchst.

Du musst den Ersatz nicht an einem Tag bauen. Du könntest mit nur einem Bildschirm anfangen — dem, der am meisten zählt — und schauen, wie es sich anfühlt. Die Kosten des Versuchs sind ein paar Stunden. Die Kosten, es nicht zu versuchen, sind ein weiteres Jahr, in dem du für Features zahlst, die du nie berührst.

Wenn du sehen willst, wie es aussieht, dein eigenes Tool zu bauen, probier Proyecta und fang mit dem an, worüber sich dein Team am meisten beschwert.