Jeder Dienst auf strako.net entsteht über ein Projekt — den vollständigen Lebenszyklus von der Planung über die Entwicklung bis in den produktiven Betrieb. Das Herzstück dieses Verlaufs ist die Bedarfsbörse: der Schritt, an dem aus einer Idee ein tragfähiger Dienst wird. Dieses Kapitel beschreibt den Projektverlauf insgesamt und die Bedarfsbörse im Detail.

Was ein Projekt ist

Ein Projekt ist die vollständige Reise eines Dienstes oder einer Erweiterung — von dem Moment, in dem aus einem Wunsch eine konkrete Idee wird, bis zum stabilen Betrieb. Ein Projekt umfasst:

die Konzeption und Planung,
die Entwicklung — egal ob ein Dienst selbst gebaut oder eine fertige Anwendung adaptiert und betrieben wird,
die Bedarfsbörse als Tragfähigkeitsprüfung,
die verbindliche Vorabregistrierung,
den Live-Gang,
und den anschließenden Betrieb.

Das ist anders, als es bei klassischen Projekten oder Startups üblich ist. Dort gibt es einen Plan, eine Finanzierungsrunde, dann wird gebaut, dann gestartet — und der Markt soll sich danach finden. Bei strako.net wird das Projekt von Anfang an mit denen entwickelt, die den Dienst später nutzen werden. Die Trennung zwischen „erst bauen, dann verkaufen" gibt es nicht.

Entwicklung gemeinsam mit den künftigen Nutzern

Die Entwicklung ist öffentlich und im Dialog mit den künftigen Nutzern. Diese Öffentlichkeit ist nicht Stilfrage, sondern Notwendigkeit: Bei strako.net wird nicht für einen abstrakten Markt gebaut, sondern für die konkreten Menschen, die später nutzen. Sie müssen während der Entwicklung gefunden und einbezogen werden, nicht danach.

Konkret bedeutet das: Das Entwicklerteam zeigt seinen Stand, lädt zu Rückmeldung ein, baut die Dienste mit einer wachsenden Gruppe von Vorab-Nutzern. Diese Vorab-Nutzer sind in dieser Phase nicht zahlend — sie sind Mitgestalter.

„Entwicklung" meint dabei nicht zwangsläufig, dass jede Zeile Code neu geschrieben wird. Viele Projekte bestehen darin, eine bestehende offene Anwendung einzurichten, an die Bedürfnisse anzupassen und betreibbar zu machen. Andere Projekte sind echte Neuentwicklungen. Beides ist Entwicklung im Sinne dieses Modells.

Während der Entwicklung wird durchgerechnet: Welche Funktionen wird der Dienst haben? Was kostet er im Betrieb? Wie hängt der Preis pro Nutzer von der Gesamtzahl der Nutzer ab? Diese Berechnung ist die Grundlage für die Bedarfsbörse.

Die Bedarfsbörse als Tragfähigkeitsprüfung

Bevor ein Dienst live gehen kann, muss klar sein, dass er sich tragen wird — dass also genug Menschen ihn zu einem Preis nutzen wollen, der seine Kosten deckt. Das ist die Aufgabe der Bedarfsbörse.

Der Name ist bewusst gewählt. An einer klassischen Börse treffen Angebot und Nachfrage aufeinander und finden gemeinsam einen Preis. Genau das geschieht hier — nur nicht kompetitiv, sondern kooperativ. Angebot ist die kalkulierte Kostenseite: Was kostet der Betrieb des Dienstes abhängig von der Nutzerzahl? Nachfrage sind die Preisangaben der potenziellen Nutzer: Bis zu welchem Preis wären sie dabei? Aus dem Zusammentreffen beider Seiten ergibt sich, ob und zu welchem Preis der Dienst tragfähig ist.

Was hinterlegt wird

Für ein Projekt wird in der Bedarfsbörse eine Kostenkalkulation hinterlegt. Sie besteht aus zwei Komponenten: einem Stufenmodell der Fixkosten (Server, Lizenzen, Wartung, anteilige Gemeinkosten — diese Kosten wachsen typischerweise sprunghaft mit der Nutzerzahl) und einem variablen Anteil pro Nutzer (Storage, Traffic, individuelle Ressourcen, die linear mit der Nutzerzahl wachsen). Aus beidem zusammen lässt sich für jede mögliche Nutzerzahl der Preis pro Nutzer berechnen, der nötig wäre, damit der Dienst sich trägt.

Diese Kalkulation ist öffentlich einsehbar. Wer wissen will, wie ein Preis zustande kommt, sieht es.

Was Nutzer angeben

Wer Interesse an einem Projekt hat, gibt seine persönliche Schmerzgrenze an — den maximalen Preis, den er für diesen Dienst zu zahlen bereit wäre. Diese Angabe ist unverbindlich. Sie ist eine Bekundung, kein Vertrag.

Aus den Angaben aller Interessierten ergibt sich für jede mögliche Preisstufe, wie viele Nutzer dabei wären — und ob das genug wäre, damit der Dienst sich auf diesem Preisniveau trägt. Das System zeigt fortlaufend an, welche Preisstufen rechnerisch tragfähig wären und wie viele Nutzer noch fehlen, damit eine bestimmte Stufe erreicht würde. Sortiert wird nach „wenigste fehlende Nutzer": Die Preisstufe, die einer Tragfähigkeit am nächsten ist, steht ganz oben.

Warum dynamisch und nicht als einmalige Umfrage

Eine einmalige Umfrage hätte einen entscheidenden Nachteil: Sie wäre eine Momentaufnahme. Wer im Februar gefragt wird, gibt seine Schmerzgrenze auf Basis seiner damaligen Situation an. Im Juni mag das anders aussehen. Außerdem würde eine einmalige Umfrage die Tatsache ignorieren, dass Preisangaben sich gegenseitig beeinflussen: Wer sieht, dass der Dienst zu einem etwas höheren Preis tragfähig wäre, mag bereit sein, etwas mehr zu zahlen — und wer sieht, dass schon viele dabei sind, mag mit einem niedrigeren Preis dazustoßen.

Die Bedarfsbörse ist deshalb dynamisch. Angaben können jederzeit angepasst oder zurückgezogen werden. Der Stand aktualisiert sich live. Periodisch — etwa monatlich — werden Teilnehmer gebeten zu bestätigen, dass ihr Interesse weiterhin besteht; geschieht das nicht, wird die Angabe nicht mehr mitgezählt. So bleibt das Bild aktuell und realistisch.

Was die Bedarfsbörse nicht ist

Die Bedarfsbörse ist nicht der Moment der verbindlichen Buchung. Wer seine Schmerzgrenze einträgt, bestellt damit noch nichts. Es ist eine Vorabhandlung: Hier wird ausgehandelt, ob ein Dienst überhaupt zustandekommen kann und zu welchem Preis. Verbindlichkeit folgt im nächsten Schritt.

Vorabregistrierung und Live-Gang

Wenn die Bedarfsbörse einen tragfähigen Punkt sichtbar gemacht hat — genug Nutzer wären zu einem Preis dabei, der die Kosten deckt — folgt die verbindliche Vorabregistrierung. Alle, deren Schmerzgrenze mindestens dem ermittelten Preis entspricht, werden gefragt, ob sie zu diesem konkreten Preis verbindlich buchen wollen.

Erst wenn die Mindestnutzerzahl durch verbindliche Zusagen erreicht ist, geht der Dienst live. Ohne diese Schwelle kein Live-Gang.

Diese Regel ist hart, und sie ist absichtlich hart. Sie schützt davor, Dienste zu betreiben, die niemand wirklich braucht — und davor, dass das Team in einer Zwickmühle landet, einen Dienst halten zu müssen, der sich nicht trägt. Sie schützt auch die Nutzer: Niemand zahlt für einen Dienst, der mangels weiterer Nutzer absehbar wieder eingestellt wird.

Die zwei Stufen — unverbindliche Schmerzgrenze in der Börse, dann verbindliche Zusage zum konkreten Preis — sind getrennt aus gutem Grund. Die Börse braucht niedrige Hürden, damit sie ein realistisches Bild ergeben kann; verbindliche Verträge zu Preisen, die noch gar nicht feststehen, kann niemand verlangen. Die Vorabregistrierung kommt erst dann, wenn der Preis feststeht — und ist dann eine klare Entscheidung.

Tests mit Pilotnutzern

Spätestens vor dem geplanten Live-Gang gibt es eine Testphase mit Pilotnutzern — einer kleinen Gruppe, die den Dienst real benutzt und Rückmeldung gibt. Tests werden aus dem Fördertopf finanziert, weil sie Teil der Entwicklung sind, nicht des regulären Betriebs.

Im Betrieb

Im laufenden Betrieb finanziert sich der Dienst aus den Beiträgen seiner Nutzer. Er trägt sich selbst — direkte Kosten plus anteilige Gemeinkosten plus Polster-Anteil werden durch die Nutzerbeiträge gedeckt. Der Fördertopf wird im Betrieb nicht angezapft, der Verein subventioniert nicht.

Weiterentwicklung im Betrieb läuft über neue Projekte — etwa für ein zusätzliches Feature, das aus einem Wunsch in der Wunschbox entstanden ist. Auch diese Projekte durchlaufen wieder Planung, Entwicklung, und gegebenenfalls eine Bedarfsbörse, wenn die Erweiterung eigene Tragfähigkeit braucht (etwa weil sie zusätzliche laufende Kosten verursacht und einen Preisaufschlag erfordert). Aus laufenden Diensten entstehen neue Wünsche, aus neuen Wünschen werden neue Projekte — der Kreis schließt sich.