An honest write-up of the stack we reach for by default, what it earns us on small and mid-size SME projects, and the situations where we deliberately pick something else.

We get asked a surprising amount about our default tech stack. Usually it is framed as "why not Next.js?" or "why not Django?" or, every so often, "why not write it in Go?"

Every stack is a set of trade-offs, and ours is too. This post is the honest version of why we reach for Laravel + PostgreSQL on most SME client builds, what those choices earn us, and the handful of situations where we deliberately pick something else.

The actual reasons, not the marketing ones

Our defaults for a typical small-to-mid-size client project look like this:

• Backend / web framework: Laravel (PHP 8.x).
• Database: PostgreSQL.
• Front-end: Blade + Alpine.js for admin and operational UIs; React when a page needs a real app-like feel.
• Hosting: a single VPS for smaller builds, moving to a managed provider when scale demands it.

These are not the objectively-best choices for every project. They are the objectively-best choices for the kind of work we do most: internal tools, booking and inventory platforms, custom CRMs, client portals, dashboards, and SME-scale e-commerce.

Why Laravel

Three practical reasons, in priority order.

1. It is boring in the good way. Laravel has been production-stable for a decade. The ecosystem has settled. The patterns for auth, queues, mail, validation, and admin dashboards are all solved problems with well-maintained packages. We are not inventing wheels on someone else's budget.

2. Shipping speed compounds. Our team can stand up the scaffolding for a new internal tool — users, roles, basic CRUD, email, a job queue — in a single afternoon. That is not because we are faster typists; it is because the framework gets out of our way for exactly those patterns that every business app needs.

3. Hiring is realistic in this region. There is a healthy population of mid-level PHP / Laravel developers in Sri Lanka and across the region. If a client ever wants to take the project in-house, we can hand it off without asking them to hire a unicorn.

We also like Eloquent for 80% of queries and are fine with raw SQL for the other 20%. Dropping down to SQL when Eloquent makes a query ugly is not a sin; it is maintenance hygiene.

Why PostgreSQL

PostgreSQL is our default database for reasons that are technical but matter at the business layer:

• Real transactions, real constraints. A double-booking, a duplicate invoice, a negative stock level — these should be impossible at the database level, not policed by the app. Postgres makes that easy with constraints and exclusion indexes.
• JSON as a first-class column. We can store semi-structured data (form responses, audit payloads, integration webhooks) without abandoning relational discipline. It means we can defer "do we need a separate table for this" decisions until we know the answer.
• Generated columns, CTEs, window functions, full-text search. The toolbox for reporting and analytics is deep. A lot of "we need a BI tool" conversations end when the client sees what Postgres can do with a CTE and an index.

MySQL / MariaDB would be a reasonable alternative; we use it when a client hosts on a provider that strongly prefers it. We just start from Postgres because the defaults are saner and the constraints are stronger.

Where we deliberately pick something else

Our stack is not a religion. There are real cases where we start from a different place:

• Content-heavy marketing sites (lots of pages, editorial workflow, SEO-first): we build these in WordPress or Statamic when the client wants editorial autonomy, or in Next.js + a headless CMS when static performance matters more than editorial agility.
• Real-time collaborative apps (think: multiplayer dashboards, chat, presence indicators): Laravel is workable with broadcasting, but if real-time is the core of the product we start from Node.js + a proper socket framework.
• Data pipelines and ML workloads: Python, always. Laravel would be the wrong tool even if we tried to force it.
• Mobile apps: Flutter for cross-platform, native Swift/Kotlin for apps that must feel truly native on the platform. The Laravel backend often remains.

We are also fine shipping a small static site as plain HTML/CSS when that is genuinely the right answer. Not every project needs a framework.

What we tell clients who want us to "use X instead"

Sometimes a client comes in with a strong opinion: "We want it in MERN" or "Our CTO says Django." We take these opinions seriously. A few things we say back:

• If the client or their in-house team will maintain it long-term, we strongly bias toward their stack. A codebase maintained in an unfamiliar stack is a future cost they will not thank us for.
• If the stack genuinely does not fit the problem, we say so. We have walked away from jobs where the stack mandate would have hurt the client.
• If the stack fits the problem but is not our strongest, we are honest about that too. We will either skill up, partner with someone who is expert in it, or decline.

Tech choices are not fashion choices when you are the one supporting the code for the next five years.

TL;DR

Laravel + PostgreSQL is our default because it is the fastest honest way for our team to ship a maintainable SME-scale web app. It is not universally the best stack. It is the best stack for the shape of work we do most. If you are talking to us about a project, expect this to be the starting point — and expect us to push back on it openly if your project is one of the cases where a different stack is genuinely better.

Original Source: https://devlk.com/blog-details.php?slug=why-we-default-to-laravel-and-postgres-for-client-builds