Weighted Comparison Study: Node.js vs. PHP Laravel
:::info Mirrored record · Original source: internal comparison study, August 2026 This page reconstructs an internal weighted-criteria study comparing Node.js and PHP Laravel as the platform's backend language/framework, produced before ADR: Fastify for Shared Engines (which assumes Node.js as settled and addresses a separate, narrower question — Fastify vs. NestJS within Node). :::
:::caution Reconstruction gap — read before relying on this page This page was reconstructed from the original conversation's actual tool-call content, not from a paraphrase, and 7 of the study's 9 weighted criteria are reproduced in full below with their original scores and justifications. Two minor criteria (10% of total weight combined) could not be fully recovered and are not included — the study's own final weighted totals (Node.js 3.80/5.00, Laravel 3.25/5.00) are stated with confidence since they were given directly in the original conversation, but the row-by-row math in the table below will not sum to exactly those totals as a result. Treat the missing 10% as a known gap, not a silent approximation. :::
1. Purpose
A structured, weighted comparison of Node.js and PHP Laravel as the platform's backend runtime, produced after the team's backend experts in both stacks debated the choice informally. Nine criteria, weighted to total 100%, each scored 1–5 for both technologies with a written justification per score.
2. Completed Scoring & Argument Table
| Criterion | Weight | Node.js | Argument — Node.js | Laravel | Argument — Laravel |
|---|---|---|---|---|---|
| Performance & Scalability | 20% | 4 | Node.js's asynchronous model (event loop) is inherently suited to typical SaaS workload: a high volume of short concurrent requests rather than heavy computation. This aligns directly with the platform's need to stream real-time notifications over WebSocket (built on Postgres LISTEN/NOTIFY) without reserving a separate thread per open connection — something harder to achieve with the same efficiency in a traditional process/request model. Not scored higher because no actual benchmark exists yet on the target infrastructure. | 3 | Laravel Octane (over Swoole or RoadRunner) substantially narrows the performance gap versus traditional PHP-FPM by keeping the application in memory between requests, but requires additional engineering discipline to avoid state leakage between consecutive requests — a risk not present with the same severity in Node.js. Long-lived connections also need Laravel Reverb, a newer and less production-proven component than its Node counterpart. |
| Current Team Experience & Real-World Productivity | 20% | 3 (flagged — provisional) | No real data exists on the actual years of experience or number of production projects each team member has delivered in either stack. This score is a neutral placeholder (assumed parity) pending real input from the backend lead. | 3 (flagged — provisional) | Same caveat applies here. This is the one criterion in the whole study recommended NOT to be taken at face value without direct review from the backend lead — it depends entirely on internal knowledge not available at the time, and it carries a heavy weight (20%) that deserves real verification, not an assumption. |
| Architectural Fit with Already-Documented SaaS Decisions | 15% | 5 | Every architectural decision documented so far — the pluggable-module manifest convention in the entitlements engine (auto-discovery at boot, encapsulated Fastify plugins), the real-time bridge over Postgres LISTEN/NOTIFY, the job queue on pg-boss/BullMQ, and shared TypeScript types with React — is already built around Node.js specifically, at zero extra cost. Nothing needs to be redesigned because nothing changes. | 2 | Switching doesn't break tenant isolation (RLS is independent of the API layer), but it does require rebuilding three components documented in detail in the Entitlements Engine SRS: automatic module discovery at boot (currently built on registering Fastify plugins), the real-time bridge (would need Laravel Reverb instead of WebSocket-over-LISTEN/NOTIFY), and the automated lint rule that blocks direct cross-module imports (built around Node/TypeScript's module system). The low score reflects real, costed rework — not a mere preference. |
| Long-Term Maintainability & Readability | 10% | 4 | TypeScript gives compile-time static type checking and lets the same type definitions be shared between the Fastify backend and the React frontend without duplicating data shapes — eliminating a whole class of bugs (response-shape mismatches between the two sides). Docked slightly because JavaScript/TypeScript's flexibility can let structure drift across the team without strict ESLint/tsconfig discipline. | 4 | Laravel's conventional structure (Convention over Configuration: Models/Controllers/Requests/Migrations) makes another developer's code faster to read for any new PHP hire, since conventions are near-universal across Laravel codebases. Docked slightly because PHP, without full and disciplined type hints, doesn't offer the same static-check rigor TypeScript does — especially for data models shared with the frontend. |
| Ecosystem & Available Libraries | 10% | 4 | npm offers mature, ready integrations for exactly what this platform needs: official payment-gateway SDKs, mature WebSocket libraries, and natural integration with validation tooling shared with React/Flutter (Zod/Valibot). Docked because some Arabic PDF/report-generation packages in Node are historically less mature than proven PHP alternatives. | 4 | Laravel has very mature packages built specifically for admin-heavy SaaS needs: Cashier for subscriptions/billing, strong Excel/PDF packages (Maatwebsite/Excel, DomPDF), and ready admin panels (Filament/Nova) that could speed up the Super Admin dashboard specifically. Docked because these packages assume Laravel's traditional synchronous model, and their integration with real-time event streaming is weaker than Node's. |
| Initial Development Speed (Time-to-Market) for the MVP | 10% | 3 | Building typical CRUD screens (properties, clients, contracts) in Fastify requires more explicit code (route definition, input validation, service layer) compared to Laravel's ready-made generators, unless an equivalent internal code-generation layer is built first. Claude Code narrows this gap in both stacks, but doesn't eliminate it without an actual side-by-side measurement on one equivalent story. | 4 | Artisan commands (make:model, make:migration, make:controller --resource) and Eloquent ORM let a full CRUD screen (model + validation + routes) be built in noticeably less time than the equivalent hand-written Node code. This is directly relevant given that a large share of AMAAR's scope (77 stories in the real estate portal alone) is standard CRUD screens rather than complex logic. |
| Future Developer Availability in the Job Market | 5% | 3 (flagged — provisional) | Needs local field confirmation: the regional Node.js developer market tends to skew toward frontend/light full-stack work rather than deep, dedicated backend specialization, which could make hiring an experienced Node backend developer specifically somewhat harder when scaling up later. | (not recovered) | (not recovered — see reconstruction gap note above) |
| (criterion not recovered — approx. 5–10% weight) | — | — | (not recovered) | — | (not recovered) |
Amber-flagged scores are provisional pending real data from the team; unflagged scores are grounded in documented technical facts or well-known stack characteristics.
3. Overall Weighted Result
| Technology | Weighted Total (out of 5.00) | Note |
|---|---|---|
| Node.js (Fastify) | 3.80 / 5.00 | Leads by a clear margin, driven mainly by architectural fit and performance. |
| PHP Laravel | 3.25 / 5.00 | Ahead on initial development speed and developer availability, but that doesn't offset the architectural-fit gap. |
Gap: 0.55 points in favor of Node.js — a meaningful gap, not a tie, but not an overwhelming one either.
4. Sensitivity Analysis — Does the Result Hold Up Under Different Real Data?
The only two criteria relying on a provisional assumption rather than a documented fact are "Team Experience" (20%) and "Developer Availability" (5%) — together 25% of the total evaluation weight. The methodological question: could changing just these two numbers flip the result in Laravel's favor?
- Worst case for Node: if the team's actual Laravel experience turns out much stronger (5/5 instead of 3/5) and the Laravel hiring market really is excellent (5/5 instead of 4/5), Laravel's total rises — but Node.js (3.80) still leads even under the most generous possible assumption on just these two criteria.
- Conclusion: the result does not hinge on the two unverified criteria alone. The real driver of the gap is "Architectural Fit" (a 3-point gap × 15% weight = 0.45 points) and "Performance" (a 1-point gap × 20% weight = 0.20 points) — both grounded in facts already documented in the project, not personal preference.
- In other words: for the recommendation to actually flip, the team would need to challenge the architectural-fit criterion itself — either by showing the cost of rebuilding the real-time bridge and module-discovery mechanism in Laravel is much lower than estimated here, or by accepting that cost in exchange for some other benefit (e.g., dev speed far higher than estimated) whose value exceeds that 0.45-point weight.
5. Recommendation
Keep Node.js (Fastify) as the primary backend layer for the project, for the following combined reasons:
- The decisive gap isn't a general technical preference for Node over Laravel — it's the real rework cost of components already built and documented (the real-time bridge, the pluggable-module standard in the entitlements engine, the automated module lint rule).
- Sharing TypeScript between the backend and the React frontend is a compounding advantage that grows in value with every new vertical built (medical, education, tourism), in line with the goal of building reusable components across the whole team — not a one-off fix specific to AMAAR.
- The result holds even under very optimistic assumptions for Laravel on the two unverified criteria (team experience and hiring market), which reduces reliance on data not actually available at the time.
Three conditions attached to this recommendation before final sign-off (per the original study): a real audit of the team's actual Laravel-vs-Node experience distribution (replacing the provisional parity assumption); a simple real performance benchmark on the target infrastructure (replacing the estimate); and an actual discussion session where the team's strongest Laravel advocates are invited to challenge this evaluation directly, rather than it being ratified as-is.
:::note Where Laravel has a real case Recorded separately from the neutral study document, as commentary rather than a scored criterion: if the team's Laravel experts are meaningfully deeper than the Node experts, actual delivery speed for the first few sprints could be faster in Laravel — and early velocity matters for a small team on a tight timeline. Laravel's batteries-included ecosystem (auth scaffolding, Eloquent, admin tooling) is genuinely mature for CRUD-heavy work, which is a large share of what AMAAR is. Laravel Octane also closes much of the raw-performance gap that used to favor Node, so "Node is faster" is a weaker argument today than a few years ago, and shouldn't be leaned on without a real benchmark. The weighting (20% performance, 20% team experience, 15% architectural fit) was deliberately built so team experience could outweigh a purely technical preference if the gap were large enough — that the study didn't flip on this basis reflects the actual weight of the architectural-fit facts, not a thumb on the scale. :::