Why We Build on Laravel and Vue: A Technical Deep-Dive

If you are evaluating us as a vendor, this is the article for you. Every studio has a default stack. Ours is Laravel on the back end, Vue 3 on the front end, glued together with Inertia.js, deployed as a single monolith. This is a deliberate engineering position, not a habit. Here is the reasoning, including where it breaks down.

The architecture in one paragraph

One repository. One deployable. Laravel handles routing, auth, validation, database access, queues, and scheduled jobs. Vue renders the UI as single-file components. Inertia replaces the REST/GraphQL layer entirely: a controller returns a page component and its props, Inertia delivers them over the wire, Vue renders. No API versioning, no client-side router fighting a server-side router, no duplicated validation logic, no token refresh dance. You get an SPA user experience with server-side simplicity.

// A complete "page" in this stack. No API endpoint, no fetch, no serializer.
public function index(Request $request)
{
    return Inertia::render('Invoices/Index', [
        'invoices' => Invoice::query()
            ->where('team_id', $request->user()->team_id)
            ->latest()
            ->paginate(25),
    ]);
}

That is the whole data layer for that screen. Multiply the deleted boilerplate across 40 screens and you understand where our delivery speed comes from.

Why a monolith at SME scale

The dominant architecture conversation of the last decade — microservices, separate SPA + API, serverless functions — was driven by companies with hundreds of engineers and traffic measured in millions of requests per minute. SME software is a different problem class:

Dimension	Typical SME app	What that implies
Concurrent users	5–500	One well-tuned server, or two behind a load balancer
Team touching the code	1–3 developers	Coordination overhead of services exceeds their benefit
Deploy frequency	Daily to weekly	One pipeline, one rollback path
Data volume	Fits comfortably in one Postgres/MySQL instance	Joins beat network calls
Budget	€6.000–€50.000 total	Every infrastructure layer is a cost multiplier

A separate SPA + API doubles the surface area: two repos or a monorepo with tooling, CORS, an auth token strategy, API contracts, two deploy pipelines, and a class of bugs (stale contracts, race conditions between deploys) that simply cannot exist in a monolith. For a five-person logistics firm's order-tracking tool, that overhead buys nothing. It just makes the invoice bigger and the bus factor worse.

Monoliths also scale further than the conference talks admit. Laravel with Octane (Swoole/FrankenPHP) sustains thousands of requests per second on commodity hardware. Basecamp, Shopify's core, and GitHub all run majority-monolith. Your SME app will not be the thing that outgrows this pattern.

Batteries included: what you don't pay us to build

The strongest practical argument for Laravel is what ships in the box or as first-party packages. Each item below is something that, in a Node/Express or Go project, is either a third-party dependency to vet or a week of custom work:

• Auth and authorization — session auth, password resets, email verification, 2FA (Fortify), OAuth/social login (Socialite), policies and gates for per-record permissions.
• Queues and background jobs — database, Redis or SQS drivers, retries with backoff, failure handling, a monitoring UI (Horizon). Sending 2.000 invoices without blocking a request is a 10-line job class.
• Realtime — Laravel Reverb gives WebSockets (live dashboards, notifications, presence) with first-party server and client. No Pusher bill, no Socket.io glue.
• Scheduled tasks — cron expressed in code, versioned with the app.
• Validation, mail, PDF-adjacent tooling, file storage abstraction (local/S3), rate limiting, signed URLs, encryption — all first-party, all documented in one place.
• Testing — Pest/PHPUnit with database factories and HTTP testing built in. Our projects ship with feature tests covering the money paths.

The economic point: when a client pays for "user accounts with roles", they are paying for configuration and policy logic, not for us to reinvent session management. That is a large part of why a custom app with us costs meaningfully less than what the Portuguese market typically charges for bespoke software (often €15.000 and up at agencies).

The hiring and bus-factor reality

Technology choices are hiring choices with a delay. If your studio disappears or you bring development in-house, who maintains the code?

PHP and Laravel have deep talent pools in Portugal and Europe generally — Laravel is consistently among the most-used back-end frameworks in developer surveys, and Vue is one of the two mainstream front-end frameworks. Any competent Laravel developer can open one of our projects and be productive in days, because the framework enforces conventions: controllers live in one place, jobs in another, the ORM is the ORM. Compare that with a hand-rolled Node service where every architectural decision was local to the original author.

This is the bus-factor argument for boring, convention-driven technology: the framework is the documentation. We write project-specific docs too, but the strongest guarantee we can give a client is that their asset is maintainable by a market, not by a person.

Where TypeScript fits

We write the Vue layer in TypeScript with typed Inertia props, so front-end data contracts are checked at build time. Tooling is Vite — sub-second hot reload, standard everywhere. We deliberately do not chase framework churn; Vue 3's Composition API has been stable since 2020, and Laravel does one major release a year with published upgrade paths. Predictable upgrades are a feature you feel in year three, not week one.

When we would choose something else

Honesty section. This stack is our default, not our religion:

• Content/marketing sites with no application logic. A five-page brochure site does not need a framework runtime. We keep those lean — that is what our Essential tier is for.
• Heavy computational workloads. Real-time video processing, large-scale ML inference, high-frequency data pipelines — PHP is the wrong tool. We would put Python or Go behind a queue and keep Laravel as the orchestration layer, or say the project is not for us.
• Offline-first mobile apps. Inertia is a server-driven pattern. A field app that must work without connectivity needs a local-first architecture, which is a different project shape (and a different budget).
• Existing team, existing stack. If your in-house team lives in Django or Rails, adding a Laravel codebase to your estate is a cost, not a gift. Stack fit includes organisational fit.
• Genuine hyperscale ambitions with funding to match. If the plan is 100 engineers in three years, your constraints are not SME constraints and your architecture should be designed against them, not against ours.

What this means for your evaluation

Questions worth asking any vendor, us included: How many moving parts does the proposed architecture have? What happens if you disappear — who else can maintain this? What ships from the framework versus what gets built from scratch (and billed)? What is the upgrade story in three years? Our answers are: one deployable; any Laravel developer in a large European talent pool; auth, queues, realtime and scheduling ship free; and one predictable major upgrade per year.

If you have a project to evaluate against this stack, describe it in our estimator and you will get a concrete scope and number to react to — faster than you would expect.