Ein ehrlicher Bericht über unseren Default-Stack, was er uns bei KMU-Projekten einbringt und die Fälle, in denen wir bewusst etwas anderes wählen.

Wir werden erstaunlich oft nach unserem Standard-Tech-Stack gefragt. Meist in Varianten wie „Warum nicht Next.js?" oder „Warum nicht Django?" oder ab und zu „Warum nicht in Go?"

Jeder Stack ist eine Menge Abwägungen, unserer auch. Dieser Artikel ist die ehrliche Erklärung, warum wir für die meisten KMU-Kundenprojekte Laravel + PostgreSQL greifen, was uns diese Wahl einbringt und in welchen Fällen wir bewusst anders entscheiden.

Die echten Gründe, nicht die Marketing-Gründe

Unser Default für ein typisches kleines-bis-mittleres Kundenprojekt:

• Backend / Web-Framework: Laravel (PHP 8.x).
• Datenbank: PostgreSQL.
• Frontend: Blade + Alpine.js für Admin- und Betriebs-Oberflächen; React, wenn eine Seite sich wirklich wie eine App anfühlen muss.
• Hosting: ein einzelner VPS für kleinere Builds, managed, sobald die Skalierung es verlangt.

Das sind nicht objektiv die besten Entscheidungen für jedes Projekt. Es sind objektiv die besten Entscheidungen für die Art von Arbeit, die wir am meisten machen: interne Tools, Buchungs- und Bestandsplattformen, maßgeschneiderte CRMs, Kundenportale, Dashboards und E-Commerce in KMU-Größe.

Warum Laravel

Drei praktische Gründe, nach Priorität:

1. Es ist langweilig — im guten Sinne. Laravel ist seit einem Jahrzehnt produktionsstabil. Das Ökosystem hat sich gesetzt. Auth, Queues, Mail, Validierung, Admin-Dashboards — alles gelöst mit gepflegten Paketen. Wir erfinden keine Räder auf Kosten anderer.

2. Liefergeschwindigkeit summiert sich. Unser Team stellt das Grundgerüst für ein neues internes Tool — Benutzer, Rollen, grundlegendes CRUD, E-Mail, Job-Queue — an einem Nachmittag auf. Nicht weil wir schneller tippen, sondern weil das Framework uns für genau jene Muster, die jede Geschäftsanwendung braucht, aus dem Weg geht.

3. Einstellen ist regional realistisch. Es gibt eine gesunde Zahl an Mid-Level-PHP/Laravel-Entwicklern in Sri Lanka und der Region. Möchte ein Kunde das Projekt irgendwann inhouse übernehmen, können wir übergeben, ohne dass er ein Einhorn suchen muss.

Eloquent nutzen wir für 80 % der Queries, rohe SQL für die restlichen 20 %. Auf SQL abzusteigen, wenn Eloquent die Query hässlich macht, ist keine Sünde — es ist Wartbarkeitshygiene.

Warum PostgreSQL

PostgreSQL ist unsere Default-Datenbank aus Gründen, die technisch sind, aber auf Business-Ebene zählen:

• Echte Transaktionen, echte Constraints. Doppelbuchungen, doppelte Rechnungen, negative Lagerbestände — das sollte auf Datenbankebene unmöglich sein, nicht von der App überwacht. Postgres macht das mit Constraints und Exclusion-Indexes einfach.
• JSON als erstklassiger Spaltentyp. Wir speichern halbstrukturierte Daten (Formulareingaben, Audit-Payloads, Integration-Webhooks) ohne die relationale Disziplin aufzugeben. „Brauchen wir dafür eine eigene Tabelle?" lässt sich damit aufschieben, bis wir die Antwort kennen.
• Generated Columns, CTEs, Window Functions, Volltextsuche. Der Werkzeugkasten für Reporting und Analyse ist tief. Viele „Wir brauchen ein BI-Tool"-Gespräche enden, wenn der Kunde sieht, was Postgres mit einem CTE und einem Index schafft.

MySQL/MariaDB wäre eine vernünftige Alternative; wir nutzen es, wenn Kunden bei Providern hosten, die es bevorzugen. Unser Startpunkt ist Postgres, weil die Defaults ruhiger und die Constraints stärker sind.

Wo wir bewusst anders wählen

Unser Stack ist keine Religion. Es gibt reale Fälle, in denen wir anders starten:

• Content-lastige Marketing-Sites (viele Seiten, redaktioneller Workflow, SEO zuerst): WordPress oder Statamic, wenn der Kunde redaktionelle Autonomie will; Next.js + Headless-CMS, wenn statische Performance wichtiger ist.
• Echtzeit-Collab-Apps (Multiplayer-Dashboards, Chat, Presence): Laravel geht mit Broadcasting, aber wenn Echtzeit der Kern ist, starten wir mit Node.js + einem eigenen Socket-Framework.
• Datenpipelines und ML-Workloads: Python, immer. Laravel wäre das falsche Werkzeug, selbst wenn wir es erzwingen würden.
• Mobile-Apps: Flutter für Cross-Platform, natives Swift/Kotlin, wenn die App sich auf der Plattform wirklich nativ anfühlen muss. Das Laravel-Backend bleibt meist.

Wir liefern auch kleine, statische Sites als reines HTML/CSS, wenn das ehrlich die richtige Antwort ist. Nicht jedes Projekt braucht ein Framework.

Was wir Kunden sagen, die „lieber X" wollen

Manchmal kommt ein Kunde mit einer klaren Meinung: „Wir wollen es in MERN" oder „Unser CTO sagt Django." Wir nehmen diese Meinungen ernst. Ein paar Dinge, die wir erwidern:

• Wenn Kunde oder Inhouse-Team das langfristig wartet, neigen wir stark zu deren Stack. Eine Codebase in unvertrautem Stack ist eine Zukunftssteuer, die sie uns nicht danken.
• Wenn der Stack nicht zum Problem passt, sagen wir das. Wir haben Jobs abgelehnt, bei denen der verordnete Stack dem Kunden geschadet hätte.
• Wenn der Stack zum Problem passt, aber nicht unsere stärkste Seite ist, sind wir auch dabei ehrlich. Wir bilden uns fort, holen einen Experten dazu — oder lehnen ab.

Tech-Entscheidungen sind keine Modeentscheidungen, wenn man die nächsten fünf Jahre den Code pflegt.

Kurzfassung

Laravel + PostgreSQL ist unser Default, weil es der schnellste ehrliche Weg für unser Team ist, eine wartbare Web-App in KMU-Größe auszuliefern. Es ist nicht universell der beste Stack. Es ist der beste Stack für die Form der Arbeit, die wir am meisten tun. Wenn Sie mit uns über ein Projekt sprechen, erwarten Sie das als Startpunkt — und erwarten Sie, dass wir offen widersprechen, falls Ihr Projekt einer der Fälle ist, in denen ein anderer Stack ehrlich besser ist.

Original Source: https://devlk.com/blog-details.php?slug=warum-wir-laravel-und-postgres-als-standard-waehlen