Warum ein Entwickler-Abo mit unbegrenzten Anfragen nicht funktioniert

1000 Dollar im Monat, unbegrenzte Anfragen, drei Tage Turnaround. Designjoy, aber für Entwicklung. Ich habe das Angebot aufgesetzt, genau einen Interessenten bis zum Gespräch gebracht und das Modell im August wieder eingestellt.

Es lag nicht am Vertrieb. Das Modell trägt bei Entwicklungsarbeit strukturell nicht, und der Grund dafür ist interessanter als mein Scheitern daran.

Was Designjoy tatsächlich verkauft

Ein einzelner Designer, rund 5000 Dollar im Monat pro Kunde, keine Agentur drumherum. Auf der Seite steht „unlimited requests". Das war der Teil, den ich kopiert habe, und es ist der falsche Teil.

Die Last wird über die Warteschlange geregelt, nicht über das Versprechen:

• Eine Aufgabe zur Zeit. Der Kunde darf unendlich einreichen, gearbeitet wird immer nur an einer Sache. Damit ist die gleichzeitige Last gedeckelt, egal wie viele Kunden auf der Liste stehen.
• Versprochen wird Tempo, rund 48 Stunden pro Aufgabe, nicht Menge. Wer viel einreicht, wartet länger und rationiert sich selbst.
• Alles läuft asynchron über ein Board. Außer einem kurzen Erstgespräch gibt es keine Termine, und damit fällt der größte versteckte Zeitfresser weg.
• Enge Ausschlüsse im Leistungsumfang: kein Video, kein 3D, keine Animation, kein komplexer Druck. Damit bleibt jede Aufgabe im 48-Stunden-Fenster.

„Unlimited" ist Marketing und kostet ihn nichts, weil die Warteschlange rationiert und nicht er. Ich hatte das Versprechen übernommen und den Mechanismus weggelassen.

Entwicklung lässt sich nicht in dieselbe Warteschlange stecken

Die Warteschlange funktioniert, wenn die Einheiten ähnlich schwer sind. Zwischen einem Logo und einer Landingpage liegt im Aufwand vielleicht Faktor drei. Das kann ein Anbieter über den Monat ausmitteln.

Zwischen „bau mir einen Filter in die Übersicht" und „bau mir Multi-Tenant-Authentifizierung" liegen zwei Größenordnungen. Gleicher Slot, gleicher Preis.

Der Kunde lernt das nach zwei Anfragen. Er merkt, welche Aufgabe seinen Slot wert ist, und schickt ab dann nur noch die teuren. Das ist kein böser Wille, das ist die vernünftige Reaktion auf die Regeln, die ich selbst aufgestellt habe. Ich verliere bei jeder einzelnen Anfrage, und je länger die Zusammenarbeit läuft, desto zuverlässiger.

Der Wartungsschwanz, den Design nicht hat

Ein geliefertes Design ist fertig. Es liegt in einer Datei und ändert sich nicht mehr von allein.

Ein geliefertes Feature lebt weiter. Es bekommt Fehler, es braucht Deployments, seine Abhängigkeiten veralten, und es verarbeitet fremde Daten, die sich ändern. Nach einem halben Jahr verkaufe ich keine Entwicklung mehr, sondern trage acht Codebasen, die ich nicht entworfen habe und nicht ablehnen kann. Das Abo zahlt flach, die Verpflichtung wächst.

Das killt Entwickler-Retainer härter als die Streuung im Aufwand, und es passiert langsam genug, dass man es erst merkt, wenn es teuer ist.

„Beliebige Anfrage" ist keine Leistungsbeschreibung

Mein Versprechen lautete sinngemäß: Komm mit irgendeiner Anfrage, du hast immer deinen Entwickler an deiner Seite.

Der eine Interessent, der bis zum Gespräch kam, wollte mir Rohvideos schicken, damit ich Clips daraus schneide. Das war ehrlich sein größter Schmerz, und es war Assistenzarbeit zum Entwicklerpreis.

Ohne feste Form des Ergebnisses füllt der Kunde die Flatrate mit seiner billigsten Arbeit. Er tut nichts Falsches. Ich hatte ihm eine Schublade verkauft und vergessen zu sagen, was hineingehört. Der Fehler steckte im Angebot, nicht in seiner Nutzung des Angebots.

Dazu kam ein zweiter Punkt aus demselben Gespräch, der mit dem Modell nichts zu tun hat und trotzdem zusammenhängt: Der Call begann auf der persönlichen Ebene und blieb dort. Danach fühlte sich jede Anfrage wie ein Gefallen an, in beide Richtungen. Struktur hätte das verhindert, nicht mehr Freundlichkeit. Wie dieses Gespräch gelaufen ist, steht ausführlicher im Post-mortem zu OfficeOS.

Was stattdessen trägt

Wiederkehrende Einnahmen brauchen etwas Uniformes. Drei Formen halten dem stand.

Wartung statt Bau. Das Projekt wird einmalig bezahlt, der Betrieb läuft im Abo. Das bildet den Wartungsschwanz ehrlich ab, statt ihn in ein Bau-Abo zu schmuggeln, und der Kunde versteht sofort, wofür er zahlt.

Eine enge Kategorie, oft wiederholt. Der zweite Kunde kostet deutlich weniger Aufwand als der erste, weil ich es schon einmal gebaut habe. Das ist die eigentliche Produktisierung: Meine Kosten sinken, statt dass mein Versprechen vager wird. Für Design heißt die Antwort auf dieselbe Frage serialisieren, für tiefe Software heißt sie standardisieren und automatisieren. Beides ist produktisiert, nur der Hebel ist ein anderer, weil die Einheit unterschiedlich schwer ist.

Software, die ich selbst betreibe. Beim Verkauf von Zeit kompoundiert nichts. Am Monatsende fange ich wieder bei null an.

Flat oder flat plus Umsatzanteil, aber nicht gemischt

Bei der Preisform gibt es zwei saubere Varianten, und sie passen zu unterschiedlichen Leistungen.

Reines Flat ist einfach zu verkaufen und zu verstehen. Es deckelt aber das, was ich am besten Kunden verdiene. Wenn ein Kunde mit dem, was ich gebaut habe, das Zehnfache verdient, sehe ich davon nichts.

Flat plus Umsatzanteil ist nach oben offen, hat aber eine harte Voraussetzung: Ich muss im Zahlungsfluss des Kunden sitzen, sonst ist der Anteil nicht einziehbar, sondern eine Bitte. Bei einer App, deren Abrechnung über meine Infrastruktur läuft, geht das. Bei einer einmalig gebauten Website geht es nicht.

Daraus folgt eine simple Zuordnung. Alles, was ich abliefere und danach loslasse, wird reines Flat. Der Umsatzanteil gehört in Modelle, in denen ich den Betrieb übernehme und ohnehin in der Bezahlung drinsitze. Mischformen aus beidem erzeugen nur Diskussionen darüber, was jetzt eigentlich gilt.

Der Vertrieb läuft anders, als ich dachte

Mein Gedanke war, dass die Vermarktung eines solchen Angebots ein gelöstes Problem ist, weil Agenturen das seit Jahrzehnten machen. Das ist genau das falsche Playbook.

Agenturen verkaufen über Beziehungen, Empfehlungen, Verkaufsgespräche und Angebote pro Projekt. Ein produktisierter Service verkauft über eine öffentliche Preisseite und Inbound: sichtbar bauen, Suchmaschinen, Verzeichnisse, ein Ablauf, den der Kunde ohne mich durchlaufen kann. Bei Designjoy ist der gesamte Vertrieb öffentliches Bauen auf einer Plattform plus ein offenes Angebot. Die Seite selbst verkauft.

Für mich heißt das, was ich im selben Sommer schon an anderer Stelle gelernt habe: Der Kanal ist das ganze Spiel, das Bauen ist der leichte Teil. Wer ein solches Abo startet und abwartet, was passiert, hat in den allermeisten Fällen null Kunden. Ein bewusst gewählter Kanal gehört an Tag eins fest, nicht in Monat vier.

Der Ein-Satz-Test

Mein Reflex war, alles anzubieten. Mobile Apps, Web-Apps, einfach einen Entwickler, alles in ein Abo. Das ist das exakte Gegenteil der Formel.

Alles anzubieten macht drei Sachen kaputt. Ein fester Preis wird unmöglich, weil der Umfang unbegrenzt ist. Die Lieferung wird nicht wiederholbar, weil jeder Auftrag anders liegt. Und ich werde zu austauschbarer Personalgestellung, die über den Preis mit dem gesamten globalen Contractor-Markt konkurriert.

Der Test ist simpel: Kann ich es in einem Satz sagen? „Ich baue X für Y zu Z im Monat." Wenn nicht, ist es noch zu breit geschnitten.

Bei mir ging das damals nicht, und ich habe es trotzdem verkauft. Die nächste Frage vor dem nächsten Anlauf ist deshalb nicht, wie ich das Angebot besser vermarkte. Sie lautet: Welche Arbeit will ich wiederholt machen, und wiederholt sie sich identisch genug, um sie mehr als einmal zu verkaufen?

Überlegst du gerade, wie du Entwicklungsarbeit einkaufen oder anbieten solltest? 30 Minuten, unverbindlich: Termin buchen