Die Technologie für deine Software wählen (ohne Techniker zu sein)
Der Entwickler fragt "React oder Vue? Nativ oder Flutter?", und du fühlst dich gezwungen, blind über etwas zu entscheiden, das du nicht verstehst. Durchatmen: Als Geschäftsinhaber wählst du nicht das Framework — du wählst die Kriterien und stellst die richtigen Fragen. Dieser Guide gibt dir genau das, inklusive der teuersten Falle: dem proprietären Framework.
6. September 20255 Min. LesezeitIn diesem Artikel
- Die unbequeme Wahrheit: "die beste Technologie" gibt es nicht
- Die vier Kriterien, die fürs Geschäft zählen
- Die Fragen an deinen Anbieter (und wie du die Antworten liest)
- Die teuerste Falle: das proprietäre Framework
- Die Entscheidungen, die WIRKLICH dir gehören
- Die Signale, dass gut gewählt wurde
- Häufige Fragen
Irgendwann im Projekt kommt die gefürchtete Frage: "Machen wir es in React oder Vue? Native App oder Flutter? Welche Datenbank bevorzugst du?" — und du fühlst dich gezwungen, blind über etwas zu entscheiden, das du nicht verstehst, mit dem Verdacht, dass dich die falsche Antwort in zwei Jahren teuer zu stehen kommt.
Durchatmen: Als Geschäftsinhaber wählst du nicht das Framework — du wählst die Kriterien. Die feinen technischen Entscheidungen gehören dem technischen Team; deine liegen auf einer anderen Ebene: dass die Technologie Menschen hat, die sie pflegen können, dass sie dich nicht zur Geisel von irgendwem macht, und dass die Kosten des Lebens mit ihr vernünftig sind. Dieser Guide gibt dir diese Kriterien, die exakten Fragen an deinen Anbieter und die roten Flaggen, die du auch ohne Programmierkenntnisse erkennst.
Die unbequeme Wahrheit: "die beste Technologie" gibt es nicht
Für die Software, die ein typisches Geschäft braucht — Websites, Shops, Verwaltungs-Apps, Buchungssysteme —, kann jede moderne Mainstream-Technologie sie gut bauen. Projekte scheitern nicht, weil Framework B statt A gewählt wurde: Sie scheitern an diffusen Anforderungen, verschwindenden Anbietern und unbezahlbarer Wartung. Die praktische Folge ist befreiend: Hör auf, die perfekte Technologie zu suchen, und beginne, nach den Kriterien zu filtern, die lebende Projekte wirklich von verwaisten trennen.
Die vier Kriterien, die fürs Geschäft zählen
- Verfügbares Talent: Wie viele Entwickler in deinem Markt beherrschen diese Technologie? Eine populäre Technologie heißt: Anbieter wechseln, einstellen und im Wettbewerb anfragen können — eine exotische heißt: von dem abhängen, der sie mitbrachte.
- Reife und Community: Jahre im Produktivbetrieb, reichlich Dokumentation, regelmäßige Updates — das Etablierte und Langweilige altert besser als das Glänzende und Neue.
- Gesamtkosten über 5 Jahre: nicht das Entwicklungsbudget — die Kosten des Lebens damit: Hosting, Lizenzen, Updates und vor allem die Stunden derer, die es warten.
- Passung zum Problem: Die Modetechnologie für Massen-Apps kann ein Panzer für deine Fliege sein — das interne System für 20 Nutzer und die Massenmarkt-App verdienen nicht dasselbe Arsenal.
Die Fragen an deinen Anbieter (und wie du die Antworten liest)
| Frage | Beruhigende Antwort | Rote Flagge |
|---|---|---|
| Warum diese Technologie für MEINEN Fall? | Gründe, die an deinem Projekt hängen: Größe, Budget, Wartung | "Die nehmen wir immer" oder unübersetzter Jargon |
| Wer sonst könnte das warten? | "Jeder X-Entwickler — davon gibt es Tausende" | "Wir — das ist unsere Spezialität" (das ist ein Schloss, kein Vorteil) |
| Wenn ihr morgen verschwindet — was mache ich? | Code in deinem Repository, Zugänge auf deinen Namen, Dokumentation übergeben | Unbehagen, Ausflüchte oder "das passiert nicht" |
| Ist das Standardtechnologie oder etwas Eigenes von euch? | Marktstandard, Open Source oder breit verbreitet | "Unser eigenes Framework/CMS" — siehe Kasten unten |
Die teuerste Falle: das proprietäre Framework
Die Entscheidungen, die WIRKLICH dir gehören
Es gibt eine Ebene von Entscheidungen, die Geschäft sind, nicht Syntax — und die musst du selbst treffen, informiert: Web-App oder installierbare App? — Nutzungsfrequenz und Store-Bedarf entscheiden, wie der Guide zu nativer, hybrider oder Web-App ausführt; No-Code oder Code? — Geschäftsphase und Eigentum entscheiden, nach dem Guide zu No-Code vs. Maßcode; Wo lebt es und wem gehört es? — verlange, dass der Code in einem Repository liegt, das dir gehört, die Zugänge (Domain, Hosting, Datenbank) auf deinen Namen laufen und die Daten exportierbar sind. Keine der drei verlangt Programmieren; alle drei definieren, wer in deiner Software das Sagen hat.
Die Signale, dass gut gewählt wurde
Eine gute Technologiewahl erkennt man an von außen sichtbaren Symptomen: Sie ist langweilig (etablierte Technologie ohne Schlagzeilen — Geschäftssoftware belohnt das Bewährte), man konnte sie dir erklären (wer wirklich versteht, kann in Klartext übersetzen; undurchdringlicher Jargon deckt meist Unsicherheit), es gibt Ersatzteile (mehr Menschen und Anbieter, die morgen übernehmen könnten), und das Budget enthält das Danach — Wartung und Weiterentwicklung mit Zahlen, nicht mit Versprechen. Der komplette Projektrahmen — Anbieter, Liefergegenstände, Vertrag — steht im Guide zur eigenen App.
Häufige Fragen
Sollte ich programmieren lernen, um diese Entscheidungen zu treffen?
Nein — so wie du keine Mechanik studierst, um ein Auto zu kaufen: Du lernst, was zu fragen ist und welchen Antworten zu misstrauen. Was sich enorm auszahlt, ist das Verständnis der Geschäftskonzepte von Software (was ein Repository ist, was Hosting, was eine API bedeutet, der Unterschied zwischen Mieten und Besitzen) — mit zehn gut verstandenen Konzepten wirst du von der Geisel zum Gesprächspartner, und dieser Guide plus der Grundlagen-Guide geben dir die meisten davon.
Zählt es, dass eine Technologie "in Mode" ist?
Weniger, als du denkst, und manchmal umgekehrt: Die technische Mode dreht sich alle zwei Jahre, und was heute glänzt, kann morgen halb gewartet sein. Was die Mode aber anzeigt, ist die künftige Talentverfügbarkeit — deshalb liegt der Sweet Spot bei konsolidierter Mainstream-Technologie: populär genug, dass Entwickler reichlich da sind, reif genug, dass sie niemand bald aufgibt. Misstraue gleichermaßen dem "das ist das Neueste" und dem "das nutzen wir seit 20 Jahren und ändern nichts".
Kann man die Technologie später wechseln, wenn wir uns geirrt haben?
Man kann, aber es ist ein Neubau, kein Umzug: Technologie zu migrieren heißt, einen guten Teil des Systems neu zu schreiben. Deshalb wiegen die Entscheidungen dieses Guides VOR dem Bauen mehr. Die gute Nachricht: Hast du Mainstream gewählt und gehört dir der Code, ist der Wechsel ein teures, aber machbares Projekt mit jedem Anbieter; bist du ins proprietäre Framework gefallen, heißt es bei null anfangen — ein Grund mehr für den "Und wenn wir uns zerstreiten?"-Test.
Zwei Anbieter schlagen verschiedene Stacks vor — wie vergleiche ich?
Vergleiche nicht die Stacks — vergleiche die Antworten auf die vier Fragen der Tabelle: warum dieser Stack für deinen Fall, wer ihn sonst warten kann, was passiert, wenn sie verschwinden, und ob er Standard ist. Addiere die vollen Zahlen (Entwicklung + 5 Jahre Wartung und Hosting) und das Detail der Übergabe (Code in deinem Repository? Zugänge auf deinen Namen?). Zwischen zwei Mainstream-Technologien liegt der echte Unterschied fast nie im Stack: Er liegt im Anbieter — nimm den, der besser geantwortet hat, nicht den mit dem besser vermarkteten Framework.