Die richtige Technologie für die richtige Projektgröße

Die häufigste Frage bei der Technologieauswahl lautet: Was ist das beste Werkzeug? Aus meiner Sicht ist das die falsche Frage. Die richtige lautet: Was passt zu diesem Projekt, in dieser Größenordnung, mit dieser Lebenserwartung? Over-Engineering ist genauso ein Fehler wie eine zu schwache Architektur – beides zahlt man später, nur an unterschiedlicher Stelle.

Warum mit Kanonen auf Spatzen schießen?

Es gibt eine Verlockung, immer das mächtigste verfügbare Werkzeug zu wählen. Es fühlt sich sicher an: Wer das große Setup nimmt, kann später nicht dafür kritisiert werden, zu klein gedacht zu haben.

Der Preis dieser Sicherheit taucht nur nicht in der Angebotssumme auf. Ein überdimensioniertes Setup bedeutet mehr bewegliche Teile, mehr Betriebsaufwand, längere Einarbeitung, langsameren Start. Für eine kleine, fokussierte Anwendung ist das keine Vorsorge, sondern Ballast – bezahlt in Wochen, die niemand für Funktionen hatte.

Umgekehrt gilt dasselbe. Wer ein System, das absehbar wächst und über Jahre laufen soll, auf einem zu schmalen Fundament aufsetzt, verschiebt die Kosten nur nach hinten. Dann steht irgendwann eine Migration an, die deutlich teurer ist als die Entscheidung, es von Anfang an robust zu bauen.

Beide Fehler sind derselbe Fehler: Die Werkzeugwahl folgt nicht dem Projekt, sondern einer Gewohnheit. Mal ist es die Gewohnheit, immer das Größte zu nehmen, mal die, immer das Vertrauteste. Diesem Muster sind wir auch bei der Wahl von KI-Entwicklungstools begegnet – mehr dazu im Artikel Welche KI-Dev-Tools lohnen sich wirklich?

Zwei Anforderungen, die bei uns am Anfang stehen

Bevor überhaupt ein Produktname fällt, klären wir zwei Dinge.

Datensouveränität. Läuft das System self-hosted in Deutschland, ohne Datenabfluss in Drittländer? Für einen erheblichen Teil unserer Projekte ist das keine Präferenz, sondern Bedingung. Diese Frage schließt Optionen aus, bevor die technische Bewertung beginnt – Firebase etwa fällt für souveräne Projekte praktisch weg: proprietär, US-gehostet, kein realistischer Weg an dieser Eigenschaft vorbei.

Angemessene Komplexität. Welche Projektklasse haben wir vor uns? Ein Prototyp, der eine Idee belegen soll, hat andere Anforderungen als ein System, das in fünf Jahren noch läuft und dann von jemandem gewartet wird, der heute noch nicht im Team ist.

Erst nach diesen beiden Fragen wird die Auswahl technisch.

Die zwei Projektklassen, mit denen wir arbeiten

In der Praxis lassen sich die meisten Vorhaben einer von zwei Klassen zuordnen.

Leichtgewichtige MVPs und kleine Apps. Klar umrissener Funktionsumfang, überschaubare Nutzerzahl, oft die Aufgabe, schnell etwas Belastbares in die Hand zu bekommen. Hier spielt ein schlankes Backend seine Stärken aus: schnell startklar, minimaler Betriebsaufwand, vollständig selbst gehostet.

Größere, langlebige Systeme. Hoch frequentiert, geschäftskritisch, über Jahre gewartet, wachsender Funktionsumfang. Hier setzen wir auf ein Postgres-basiertes Fundament – ob als Supabase, Directus oder Eigenbau, hängt vom Projekt ab. Der gemeinsame Nenner ist die Reife: bekannte Betriebseigenschaften, breite Wissensbasis, verlässliche Migrationspfade.

Die Einordnung in eine dieser Klassen ist die eigentliche Arbeit. Sie ist ein Urteil, keine Rechnung, und sie muss ehrlich ausfallen – auch dann, wenn ein Projekt als MVP verkauft wurde, aber erkennbar auf ein Produktivsystem zuläuft.

Was ein schlankes Backend leistet – und wo seine Grenzen liegen

Ein Beispiel für die erste Klasse ist PocketBase. Für nicht-technische Leser: Es bündelt in einer einzigen Datei, was man sonst aus mehreren Bausteinen zusammensetzt – Datenbank, Benutzerverwaltung und Login, Echtzeit-Funktionen, Dateispeicher und eine Verwaltungsoberfläche. Man muss die Teile nicht einzeln auswählen, verbinden und betreiben. Für einen schnellen, souveränen Start ist das ein echter Vorteil.

Genauso gehören die Grenzen dazu, und wir benennen sie vor der Entscheidung, nicht danach:

• Der Aufbau ist auf einen Server mit lokaler Datenbankdatei ausgelegt. Horizontale Skalierung ist damit begrenzt, und bei vielen gleichzeitigen Schreibzugriffen wird das spürbar.
• Das Projekt steht Mitte 2026 noch vor Version 1.0. Abwärtskompatibilität ist nicht garantiert, gelegentlich sind manuelle Migrationsschritte nötig.
• Der Kern wird im Wesentlichen von einer einzelnen Person entwickelt. Das ist ein kleiner Bus-Faktor – kein Ausschlusskriterium, aber ein Risiko, das man kennen sollte.
• Funktionen, die man in ausgewachsenen Plattformen erwartet, fehlen teilweise.

Diese Eigenschaften sind in der ersten Projektklasse verkraftbar und werden durch den Geschwindigkeitsvorteil aufgewogen. In der zweiten Klasse sind sie es nicht. Das ist keine Kritik am Werkzeug – es ist schlicht für einen anderen Zweck gebaut.

Bei der Karte ist die Antwort größenunabhängig

Anders liegt der Fall bei Kartenmaterial. Hier fällt die Entscheidung über alle Projektgrößen hinweg gleich aus: OpenStreetMap.

Der Hauptgrund ist Kontrolle. Die Daten und das Kartenmaterial liegen bei uns, es findet kein Datentransfer in die USA statt, und es entsteht keine Abhängigkeit von einem Anbieter, der Preise oder Nutzungsbedingungen einseitig ändern kann. Die Kostenseite ist ein realer Nebeneffekt: keine laufenden Lizenzgebühren wie bei kommerziellen Kartenmodellen.

Auch hier die Grenzen offen: Die Datenqualität ist regional unterschiedlich. Geocoding, Routing und Kartenkacheln muss man selbst betreiben, das ist Setup-Aufwand. Fertige Premium-Funktionen wie Live-Verkehrsdaten oder Straßenansichten gibt es nicht ab Werk. Wir akzeptieren das bewusst, weil Kontrolle und Souveränität in unseren Projekten schwerer wiegen.

Der Unterschied zum Backend ist aufschlussreich: Nicht jede Technologieentscheidung ist eine Größenfrage. Manche folgen einem Prinzip, das über alle Projektklassen trägt. Man sollte nur wissen, welche Art von Entscheidung man gerade trifft.

Nicht „dieses Tool für immer", sondern „dieses Tool für diese Projektklasse"

Das ist der Kern. Eine Technologieentscheidung ist kein Bekenntnis. Sie gilt für eine Projektklasse, unter bestimmten Annahmen – und Annahmen ändern sich.

Deshalb gehört zu jeder Auswahl eine zweite Frage, die selten gestellt wird: Woran würden wir merken, dass diese Entscheidung nicht mehr trägt? Wenn die Antwort lautet „wenn es kracht", ist das Kriterium zu spät. Brauchbare Signale sind konkreter: Antwortzeiten unter Last, Häufigkeit manueller Eingriffe im Betrieb, Aufwand pro Aktualisierung, das Auftauchen von Anforderungen, für die das Werkzeug nicht gedacht war.

Wer diese Schwellen vorher benennt, kann rechtzeitig und geordnet umbauen, statt unter Druck. Das gehört für mich genauso zum Handwerk wie die erste Auswahl – und es ist der Unterschied zwischen einer Architektur, die mitwächst, und einer, die irgendwann gegen die Wand läuft.

Man baut keinen Industriehafen, wenn man ein Ruderboot anlegen will. Man sollte nur wissen, ab wann aus dem Ruderboot ein Frachter wird.