Bootstrapped im Public Sector: Gründen mit langen Wegen

Zwischen einem guten Gespräch mit einer Verwaltung und einer tatsächlichen Beauftragung können viele Monate liegen. Für ein junges Softwareunternehmen läuft die Arbeit währenddessen weiter und muss finanziert werden. Wer bootstrapped gründet, baut sein Unternehmen ohne Wagniskapital von Investoren aus eigener Kraft auf. Produktentwicklung und Marktzugang werden dabei im Wesentlichen aus eigenen Mitteln und laufenden Einnahmen finanziert.

Wie sich das im Alltag auswirkt, habe ich als Mitgründer von Aivot erfahren. Wir sind mit einem ersten Prototyp unserer Verwaltungssoftware gestartet und haben daraus Schritt für Schritt ein Produkt und ein Unternehmen aufgebaut. Wie viel Zeit und Kapazität wir in die Weiterentwicklung investieren konnten, hing dabei auch davon ab, was die Software bereits erwirtschaftete. Mit wachsenden Einnahmen entstand nach und nach mehr Spielraum für die nächsten Schritte. Unser Jubiläum nehme ich zum Anlass, auf diesen Weg zurückzublicken und darüber nachzudenken, was Gründen im Public Sector besonders macht und welche Herausforderungen damit verbunden sind.

Aus einem Formularwerkzeug wurde eine Plattform

Die Idee für Aivot entstand aus der Verwaltungspraxis meiner heutigen Kollegen und Mitgründer. Sie kannten Medienbrüche, doppelte Arbeit und unnötig komplizierte Abläufe aus dem eigenen Behördenalltag. Ich selbst hatte bis dahin mit Verwaltung eigentlich noch gar nichts am Hut. Mein Blick auf diese Probleme kam anfangs von außen. Gemeinsam wollten wir die Abläufe mit Köpfchen einfacher machen. Das steckt auch in unserem Namen: Aivot ist Finnisch und bedeutet Gehirn.

Unser erster Prototyp trug noch keinen Produktnamen und konzentrierte sich auf Online-Formulare. Aus ihm wurde später Gover, und aus dem Formularwerkzeug entwickelte sich schrittweise eine Plattform für durchgängige Verwaltungsprozesse. Künftig trägt sie den Namen Prosuna.

Wir konnten diesen Weg gehen, weil im Team Softwareentwicklung, UI/UX, Konzeption, Projektmanagement und Verwaltungserfahrung zusammenkamen. Trotzdem hatten wir uns damit ein deutlich größeres Feld vorgenommen, als uns am Anfang vermutlich bewusst war. Eine solche Plattform reicht über einen einzelnen Arbeitsschritt hinaus. Sie trifft auf Fachrecht, Datenmodelle, Rollen und Rechte, Schnittstellen, Barrierefreiheit, Datenschutz, IT-Sicherheit, Betrieb und die tägliche Arbeit in der Sachbearbeitung.

Jedes dieser Themen erhöht den Prüf- und Abstimmungsbedarf und erweitert den Kreis der Menschen, die einer Einführung zustimmen müssen. Der Nutzen lässt sich nicht allein an einer gelungenen Oberfläche zeigen. Die Plattform muss sich auch dort bewähren, wo Daten weitergegeben, Sonderfälle bearbeitet, Entscheidungen dokumentiert und Systeme langfristig betrieben werden.

Die Breite hat einen fachlichen Grund. Medienbrüche verschwinden selten, wenn nur ein einzelner Schritt eine bessere Oberfläche bekommt. Wer einen Verwaltungsprozess spürbar entlasten will, muss über das Absenden eines Online-Formulars hinausdenken. Für uns bedeutet dieser Anspruch, dass wir lernen müssen, wie Fachlichkeit, Organisation und Technik in der Verwaltung tatsächlich zusammenwirken.

Der erste Auftrag braucht einen Vertrauensvorschuss

Eine Verwaltung muss vor einer Einführung auch einschätzen, ob sie sich im laufenden Betrieb auf den Anbieter verlassen kann. Wer steht für die Lösung ein, wenn nach dem Go-live etwas nicht funktioniert? Und kann das Unternehmen die Betreuung und Weiterentwicklung langfristig bewältigen?

Für ein junges Unternehmen entsteht daraus eine schwierige Schleife. Verwaltungen wünschen sich Erfahrung und belastbare Referenzen. Beides entsteht jedoch erst durch den Einsatz der eigenen Lösung. Wer noch am Anfang steht, muss also Vertrauen aufbauen, bevor er in größerem Umfang zeigen kann, dass dieses Vertrauen gerechtfertigt ist.

Das ist nicht einfach Ausdruck einer langsamen Verwaltung. Es geht um öffentliche Mittel, sensible Daten, rechtlich gebundene Entscheidungen und Leistungen, auf die Menschen angewiesen sind. Die Vorsicht hat also einen nachvollziehbaren Grund. Für Gründer:innen passt dadurch das gewohnte Bild vom Aufbau eines jungen Softwareunternehmens aber nur bedingt. Produkt, Marktzugang und Unternehmen können nicht sauber nacheinander reifen. Sie sind gleichzeitig voneinander abhängig.

Vertrauen entsteht in diesem Markt vor allem durch verlässliche Arbeit, verständliche Dokumentation und Gespräche, in denen auch Grenzen benannt werden. Betriebsmodelle, Sicherheitskonzepte und erreichbare Ansprechpartner:innen gehören deshalb zum Produktversprechen eines Softwareanbieters.

Das verändert auch den Vertrieb. Bei uns fühlt er sich selten wie der eine überzeugende Pitch an. Häufiger besteht er aus kleinen Belegen dafür, dass wir Zusagen einhalten, Fragen nachvollziehbar beantworten und auch nach dem Vertragsabschluss Verantwortung übernehmen. Eine erfolgreiche Einführung kann für ein junges Unternehmen deshalb weit über den unmittelbaren Umsatz hinaus wichtig sein: Sie macht die eigene Verlässlichkeit für andere sichtbar.

Auch Quelloffenheit ist für uns Teil dieser Verlässlichkeit. Sie gibt einer Verwaltung noch keine Garantie für guten Betrieb oder gute Zusammenarbeit. Sie schafft aber prüfbare Grundlagen und hält langfristig Optionen offen. Das ist ein wichtiger Teil der digitalen Souveränität, die wir mit Aivot unterstützen wollen.

Bootstrapping trifft auf einen langsamen Markt

Diese Verlässlichkeit aufzubauen, kostet schon vor dem ersten Auftrag Zeit. Produktentwicklung, Kundentermine und die vielen kleinen Aufgaben eines jungen Unternehmens konkurrieren dabei um dieselben begrenzten Kapazitäten. Mit jeder Einführung wurde unser Produkt belastbarer und unsere Perspektive verlässlicher.

Bootstrapped zu bleiben, war für uns nicht nur eine finanzielle Entscheidung. Wir wollten unabhängig von den großen Anbietern bleiben, deren Trägheit aus unserer Sicht dazu beigetragen hat, dass sich viele Probleme der Verwaltungsdigitalisierung bis heute halten. Gerade diese Trägheit war einer der Gründe für unsere Gründung: Wir wollten in diesem Bereich selbst etwas bewegen. Die Richtung unseres Produkts sollte deshalb unter unserer Kontrolle bleiben.

Dieser Weg band die Entwicklung des Unternehmens unmittelbar an das, was wir bereits erwirtschaften konnten. Produkt und Unternehmen mussten in einem gemeinsamen Tempo wachsen. Zusätzliche Kapazität brauchte eine finanzielle Grundlage. Jede Zusage band spürbar Zeit, und Grundlagenarbeit ließ sich nicht unbegrenzt vorfinanzieren.

In einem Markt mit langen Vertriebs- und Beschaffungswegen wird dieser Zusammenhang besonders herausfordern. Zwischen einem guten Gespräch und einer tatsächlichen Beauftragung können viele Monate liegen. Das Produkt muss trotzdem weiterentwickelt, der Betrieb vorbereitet und das vorhandene Team finanziert werden. Wer bootstrapped gründet, kann diese Zeit nicht einfach mit mehr Personal überbrücken.

Diese Monate bestehen zudem aus Arbeit. Ausschreibungsunterlagen müssen geprüft, Nachweise zusammengestellt, Angebote kalkuliert und technische Rückfragen beantwortet werden. Vieles davon fällt an, bevor feststeht, ob daraus überhaupt ein Auftrag wird. In einem kleinen Team fehlt diese Zeit an anderer Stelle, etwa bei der Weiterentwicklung oder der Betreuung bestehender Kunden.

Der KOINNO-Vergabereport 2025 gibt einen Hinweis darauf, wie stark diese Vorarbeit ins Gewicht fällt: 80 Prozent der Befragten mit Ausschreibungserfahrung bewerten den Aufwand einer Angebotsabgabe für öffentliche Aufträge als höher als den Vertriebs- und Angebotsaufwand bei anderen Kunden. An der Befragung nahmen insgesamt 62 Personen beziehungsweise Unternehmen teil, überwiegend aus länger bestehenden Unternehmen. Das ist in der Menge nicht repräsentativ, entspricht aber meiner eigenen Wahrnehmung und Erfahrung.

Für ein bootstrapped Unternehmen gehört deshalb auch die Auswahl der verfolgten Aufträge zur Produktstrategie. Passt der Bedarf zur eigenen Lösung? Steht der Aufwand für das Angebot in einem vertretbaren Verhältnis zur möglichen Beauftragung? Und welche Arbeit bleibt dafür liegen? Selbst eine fachlich interessante Gelegenheit kann zu viel Kapazität binden. Ein voller Kalender mit aussichtsreichen Gesprächen finanziert noch keine zusätzliche Stelle.

Ich möchte daraus keine Heldengeschichte über langsames Wachstum machen. Bootstrapping kann Kräfte aufzehren und Optionen begrenzen. Mehr Kapital hätte manche Entwicklung beschleunigt. Das ist nicht automatisch die bessere oder moralischere Gründungsform. Für uns hat sich dieser Weg richtig angefühlt, weil Produkt und Unternehmen so miteinander wachsen konnten.

Die Richtung des Produkts braucht auch ein Nein

Ohne Wagniskapital zu arbeiten, gibt uns die Freiheit, über unsere Richtung selbst zu entscheiden. Damit ist die Frage nach Unabhängigkeit allerdings nicht erledigt. Wer seine Weiterentwicklung aus Kundeneinnahmen finanziert, muss sich auch mit dem Einfluss einzelner Kundenwünsche auseinandersetzen. Besonders dann, wenn nur wenige Aufträge einen großen Teil der laufenden Kosten decken, kann eine zusätzliche Anforderung erhebliches Gewicht bekommen.

Bei einer breiten Plattform ist die Grenze nicht immer offensichtlich. Der Einsatz bei einzelnen Verwaltungen liefert das Wissen, das für ein gutes Produkt nötig ist, bringt aber auch spezielle Anforderungen mit. Wir mussten früh unterscheiden: Welche Anpassung verbessert das Produkt für viele Verwaltungen, und welche würde uns dauerhaft in eine Sonderlösung führen? Unser Geschäftsmodell ist deshalb kein klassisches Projektgeschäft. Im Mittelpunkt steht Prosuna als eigenständiges Produkt, das wir kontinuierlich weiterentwickeln.

So haben wir beispielsweise spezialisierte Funktionen für das Fördermittelmanagement bewusst abgelehnt, die ausschließlich in diesem Bereich zum Einsatz gekommen wären. Fachlich liegt das nah genug an Verwaltungsprozessen, um zunächst wie eine plausible Erweiterung zu wirken. Damit hätten wir aber dauerhaft zusätzliche Fachlogik pflegen müssen, die anderen Verwaltungsprozessen nicht zugutegekommen wäre. Wir wollten eine Plattform für durchgängige Verwaltungsprozesse bauen. Solche bereichsspezifischen Erweiterungen hätten uns von dieser Vision entfernt.

Die Schwierigkeit liegt für mich gerade darin, dass eine solche Anfrage durchaus sinnvoll sein kann. Ein nachvollziehbarer Bedarf verpflichtet uns trotzdem nicht dazu, ihn mit unserem Produkt abzudecken. Mit jeder Erweiterung übernehmen wir Verantwortung für ihre Pflege und Weiterentwicklung. Diese Arbeit bleibt, auch wenn der ursprüngliche Anlass längst nicht mehr gegeben ist. Unsere Unabhängigkeit zeigt sich deshalb auch darin, eine Richtung ablehnen zu können, die nicht zu dem passt, was wir langfristig tragen und vertreten wollen.

Ein enger Zuschnitt kann den Einstieg erleichtern

Wie weit man sich mit einem Produkt vorwagt, prägt auch den Weg zum ersten Einsatz. Im GovTech-Markt, also dem Markt für digitale Produkte und Dienstleistungen für Staat und Verwaltung, gibt es reichlich Angebote, die bei klar begrenzten Aufgaben ansetzen. Gerade bei neuen KI-Lösungen sieht man Angebote, die eine Recherche unterstützen, Dokumente zusammenfassen oder Texte formulieren. Ihr Nutzen lässt sich schnell erklären und oft ebenso schnell ausprobieren.

Für die Produktentwicklung liegt darin auch der Gedanke eines Minimum Viable Product, kurz MVP: eine erste, bewusst begrenzte Version, mit der ein Team früh prüfen kann, ob seine Annahmen über das Problem und den Nutzen der Lösung stimmen. Je enger die zu prüfende Aufgabe umrissen ist, desto gezielter lässt sich diese Version entwickeln und auswerten. Gerade beim Bootstrapping ist es hilfreich, grundlegende Annahmen prüfen zu können, bevor zu viel Entwicklungszeit in eine Richtung geflossen ist. Ein Produkt mit wenigen Funktionen ist aber nicht automatisch ein MVP. Es kann sich längst im Alltag bewährt haben und bewusst auf eine einzelne Aufgabe beschränkt bleiben.

Ein solches Produkt kann auch mit wenigen Funktionen im Verwaltungsalltag viel bewirken. Sind damit weniger Schnittstellen, beteiligte Rollen und Eingriffe in bestehende Abläufe verbunden, kann das die Hürden für Beschaffung und Einführung senken. Eine Verwaltung kann mit einem begrenzten Anwendungsfall beginnen und Erfahrungen sammeln. Trägt die Lösung nicht, lässt sie sich unter diesen Bedingungen vergleichsweise schnell austauschen.

Entscheidend ist allerdings, worauf das Produkt zugreift und was es beeinflusst. Auch ein Werkzeug mit wenigen Funktionen kann sensible Daten verarbeiten oder in rechtlich relevante Entscheidungen eingreifen. Die Zahl der Funktionen allein sagt deshalb wenig über den Prüfbedarf aus. Der Vorteil entsteht dort, wo sich eine Aufgabe tatsächlich mit überschaubaren Abhängigkeiten lösen lässt.

Wenige Abhängigkeiten können zugleich den Wechsel zu einem anderen Angebot erleichtern. Hängt das gesamte Geschäft an diesem einen Anwendungsfall, trifft dessen Austauschbarkeit das Unternehmen entsprechend stark.

Für solche Anbieter kann Diversifizierung deshalb wichtig sein: weitere passende Anwendungsfälle erschließen oder ergänzende Produkte entwickeln, damit die Einnahmen auf mehreren Angeboten beruhen. So hängt die Zukunft des Unternehmens weniger davon ab, ob es bei einer einzelnen Aufgabe dauerhaft die bevorzugte Lösung bleibt. Fachlich angrenzende Angebote ermöglichen es dabei, vorhandenes Wissen und Technik weiterzuverwenden. Auch bei diesem Weg stellt sich also die Frage, welche Erweiterungen zum Unternehmen passen und welche es zu weit von seiner Richtung entfernen würden.

Manchmal bin ich auf diesen „einfacheren“ Einstieg ein wenig neidisch. Die Aufgabe, den Nutzen schnell verständlich und überprüfbar zu machen, haben wir mit einer breiten Plattform allerdings genauso.

Der erste Prozess muss im Alltag etwas beweisen

Eine ganze Plattform auf einmal einzuführen, würde einer Verwaltung viele Entscheidungen gleichzeitig abverlangen. Für uns stellt sich deshalb die Frage, mit welchem Prozess sie die Zusammenarbeit und das Produkt sinnvoll kennenlernen kann. Der erste Einsatz muss eine reale Aufgabe lösen und dabei so überschaubar bleiben, dass Fragen und Probleme zeitnah geklärt werden können.

Beim Onboarding setzen wir deshalb nach Möglichkeit zuerst einen kleinen Verwaltungsprozess um, der ohne externe Datenquellen oder Schnittstellen auskommt. Zuständigkeiten und Erfolgskriterien klären wir früh. So hängt der Beginn nicht bereits davon ab, dass mehrere andere Systeme angebunden werden. Die Beteiligten können sich zunächst mit dem Ablauf und ihrer Arbeit in der Plattform vertraut machen.

Für mich sollte sich an diesem Prozess bereits zeigen, ob die Lösung im Alltag funktioniert. Finden Sachbearbeiter:innen die Informationen, die sie für die Bearbeitung benötigen? Ist erkennbar, wo eine Rückfrage offen ist und wer als Nächstes handeln muss? Kommt ein Vorgang zu einem fachlich sinnvollen Abschluss? Ein erfolgreich abgesendetes Formular allein würde den Anspruch an unsere Plattform noch nicht prüfen.

Die bewusste Begrenzung lässt aber Fragen offen. Ein Prozess ohne externe Schnittstellen sagt noch wenig darüber aus, wie gut die spätere Anbindung eines Fachverfahrens gelingt. Das sollte bei der Bewertung des ersten Einsatzes sichtbar bleiben. Sonst wird aus einem gelungenen kleinen Schritt eine Sicherheit abgeleitet, die der Versuch gar nicht liefern konnte.

Darauf baut für mich agile Entwicklung in Behördenprojekten auf: Erfahrungen aus einem überschaubaren Einsatz verändern die nächste Entscheidung. Manche Abläufe müssen angepasst, manche Annahmen erneut geprüft werden, bevor weitere Prozesse oder Schnittstellen hinzukommen. Der Einstieg wird damit zu einem Teil der Produktentwicklung und liefert der Verwaltung eine konkrete Grundlage, um über das weitere Vorgehen zu entscheiden.

Ein erfolgreicher Pilot braucht eine Anschlussentscheidung

Auch wenn sich dieser erste Prozess bewährt, bleibt die Frage, wie es nach einer Pilotphase weitergeht. Die OECD beschreibt den Übergang vom Pilot zur breiteren Einführung als eigene Herausforderung: Finanzierung und Beschaffung müssen dafür ebenso gesichert werden wie die Kapazitäten für Einführung und langfristige Betreuung. Ein funktionierender Versuch löst diese Fragen nicht wie von Geisterhand.

Deshalb sollte bereits vor dem Start besprochen werden, woran sich der Nutzen zeigen soll, wer anschließend über das weitere Vorgehen entscheidet und aus welchem Budget ein dauerhafter Betrieb finanziert werden könnte. Der mögliche Beschaffungsweg gehört ebenfalls dazu. Das ist keine Zusage für einen Folgeauftrag und darf einen fairen Wettbewerb nicht vorwegnehmen. Es schafft aber Klarheit darüber, welche Voraussetzungen für eine Fortsetzung noch fehlen.

Für ein bootstrapped Unternehmen ist dieser Unterschied wesentlich. Auch ein Pilot bindet Entwicklungszeit und erfordert Abstimmung sowie Betreuung. Sein Lerngewinn lässt sich nicht unbegrenzt gegen eine unklare wirtschaftliche Perspektive aufrechnen. Ein sinnvoller Pilot darf mit der Erkenntnis enden, dass die Lösung nicht passt. Wenn sie sich bewährt, sollte dagegen jemand eine begründete Anschlussentscheidung treffen können. Sonst bleibt wertvolle Arbeit im Versuch stecken und geht verloren.

Bei der nächsten Verwaltung muss etwas leichter werden

Wenn aus dem ersten Einsatz ein dauerhafter Betrieb wird, ist bereits viel erreicht. Für ein Produktunternehmen stellt sich dann die nächste Frage: Wie viel von dieser Arbeit hilft auch bei der Einführung in einer anderen Verwaltung? Eine erfolgreiche Installation belegt zunächst, dass die Lösung unter bestimmten Bedingungen funktioniert.

Wenn jede Verwaltung umfangreiche neue Sonderentwicklung benötigt, wächst mit jedem Auftrag auch die dauerhaft zu betreuende Vielfalt. Der gemeinsame Produktkern hilft dann wirtschaftlich nur begrenzt. Konfigurierbare Abläufe, wiederverwendbare Schnittstellen und verständliche Betriebsdokumentation können dagegen dazu beitragen, dass eine weitere Einführung weniger individuelle Arbeit erfordert. Auch Schulungsmaterial muss nicht jedes Mal von vorn entstehen.

Das bedeutet nicht, dass alle Verwaltungen gleich arbeiten sollten. Unterschiede im Fachrecht, in Zuständigkeiten oder in der vorhandenen IT verschwinden durch ein gemeinsames Produkt nicht. Es kommt darauf an, welche Unterschiede sich durch Konfiguration abbilden lassen und wo tatsächlich neue Entwicklung nötig ist. Gerade deshalb sind offene Standards für ein kleines Softwareunternehmen auch eine wirtschaftliche Frage: Jede wiederverwendbare Anbindung kann Aufwand bei späteren Einführungen vermeiden.

Für unseren Weg lässt sich daraus ein weiterer Maßstab ableiten. Fortschritt wäre, wenn eine Einführung Erfahrungen liefert, die die nächste einfacher machen. Sonst binden zusätzliche Kunden immer mehr von der Zeit, die eigentlich für die Weiterentwicklung des gemeinsamen Produkts gebraucht wird.

Beschaffung kann den Zugang mitgestalten

Auch eine gut übertragbare Lösung muss bei der nächsten Verwaltung wieder einen Weg in die Beschaffung finden. Hier liegt ein Teil der Verantwortung bei den öffentlichen Auftraggebern. Wenn der erste Austausch erst mit einer weitgehend festgelegten Leistungsbeschreibung beginnt, bleibt wenig Raum, andere Lösungswege kennenzulernen.

Im Anwendungsbereich der Vergabeverordnung sind Markterkundungen vor einem Vergabeverfahren ausdrücklich vorgesehen. Sie erlauben Auftraggebern, sich vorab mit dem Angebot des Marktes zu befassen und Unternehmen über ihre Pläne und Anforderungen zu informieren. Ein solcher Austausch ist noch keine Beauftragung. Er kann aber helfen, einen Bedarf so zu beschreiben, dass auch eine andere als die bisher bekannte Lösung infrage kommt.

Auch bei den Nachweisen gibt es Vorgaben, die den Zugang offenhalten sollen. Nach § 122 GWB müssen Eignungskriterien und geforderte Nachweise zum Auftrag und seinem Wert in einem angemessenen Verhältnis stehen. Die Vergabeverordnung nennt bei geeigneten Referenzen ausdrücklich öffentliche oder private Auftraggeber. Eine Referenz muss also nicht allein deshalb ungeeignet sein, weil sie aus der Privatwirtschaft stammt – ihre fachliche Eignung für den konkreten Auftrag bleibt zu beurteilen.

Für mich folgt daraus eine praktische Frage: Welche Erfahrung und welche Nachweise braucht es wirklich, um diesen Auftrag verantwortbar zu vergeben? Anforderungen sollten am tatsächlichen Risiko ansetzen. Ein begrenzter Einstieg bietet die Möglichkeit, den Umfang der Aufgabe und die dafür nötige Absicherung gemeinsam überschaubar zu halten. So können junge Anbieter zeigen, was sie leisten, und Verwaltungen gewinnen eine belastbarere Grundlage für ihre Entscheidung.

Über unsere Mitgliedschaften im Bitkom und in der GovTech Allianz setzen wir uns auch über die Arbeit an unserer Plattform hinaus für bessere Rahmenbedingungen ein, damit Innovationen im Public Sector schneller in die Praxis kommen.

Lange Wege sind keine Entschuldigung

Solche Rahmenbedingungen können den Marktzugang erleichtern. Sie nehmen uns die eigenen Entscheidungen aber nicht ab. Wer im Public Sector gründet, braucht Geduld für Vertrauen, Referenzen und formale Verfahren. Die langen Zyklen des Marktes dürfen trotzdem keine Ausrede dafür werden, Produktfragen jahrelang offenzuhalten.

Nicht jede Verzögerung kommt von außen. Wir haben uns bewusst für eine breite Aufgabe entschieden und ihre Größe am Anfang nicht in jeder Konsequenz verstanden. Unsere Verantwortung besteht darin, diese Aufgabe in beherrschbare Schritte zu übersetzen, klare Prioritäten zu setzen und nur das zu versprechen, was wir anschließend zuverlässig betreiben können.

Für Ende 2026 planen wir mit dem Major Release von Prosuna auf Version 5 einen besonderen Meilenstein. Nach zwei intensiven Jahren der Weiterentwicklung soll Prosuna damit endlich die Plattform sein, die wir uns beim ersten Prototyp vorgestellt haben: eine quelloffene Lösung, die Verwaltungsprozesse durchgängig abbildet, statt nur ihr digitales Eingangstor bereitzustellen. Version 5 beendet diese Entwicklung nicht. Sie schafft die Grundlage für die nächsten Schritte und für neue Anforderungen, die erst im Einsatz sichtbar werden.

Auf das, was unser Team unter diesen Bedingungen aufgebaut hat, bin ich sehr stolz. Ebenso dankbar bin ich allen, die unsere Idee mitgetragen und gemeinsam mit uns daran gearbeitet haben, in der Verwaltung etwas zu bewegen, auch wenn der Weg dorthin nicht immer der kürzeste war und weiterhin ist.

Mit der Zeit ist mir klarer geworden, dass wir mit jedem Auftrag auch darüber entscheiden, welche Arbeit wir uns für die kommenden Jahre vornehmen. Ein guter nächster Schritt muss zur Verwaltung passen, die ihn mit uns geht, und das gemeinsame Produkt voranbringen. Manchmal heißt das, eine Einführung kleiner anzulegen. Manchmal heißt es, eine Weiterentwicklung abzulehnen. Geduld mit dem Markt gehört dazu. Die Richtung unseres Unternehmens und dessen Lösungen müssen wir trotzdem selbst bestimmen.