Why I didn't reach for Laravel to build a hospital management SaaS.

The hospital management SaaS runs on a custom PHP MVC. No Laravel, no Symfony, nothing off the shelf. Whenever that comes up, the assumption is usually that it's a "not-invented-here" thing, or that I just hadn't gotten around to learning a framework. Neither is true — I use Laravel elsewhere, including on the credentialing SaaS. The decision for the hospital product was specific to that product.

Who actually runs this software

A hospital management system doesn't get bought by a DevOps team. It gets bought by a small or mid-size hospital or clinic, and it runs wherever their IT guy — if they have one — can get it running: often shared hosting, sometimes an old on-prem box nobody wants to touch, occasionally a VPS someone set up years ago and half-forgot about. That environment is the actual constraint, not a technical preference. A framework with a deep Composer dependency tree, specific PHP-extension requirements, and version-sensitive tooling is a bet that the hosting environment on the other end is modern and well maintained. For this category of buyer, that bet doesn't hold.

What a framework buys you, and what it costs here

Laravel earns its keep when a team is large, the app's surface area is huge, and the priority is developer velocity across many contributors. None of that describes this product. It's a well-scoped domain — patients, appointments, billing, records, staff roles — where the MVC boundaries are simple enough that a framework's routing, ORM, and service-container machinery add indirection without adding much velocity. What it does add is more moving parts to keep patched, more surface area for a version bump somewhere in the dependency tree to quietly break a client's install, and a heavier runtime footprint on hardware that's already the weakest link.

The actual tradeoff

Custom MVC means writing more scaffolding by hand up front — routing, request handling, the parts a framework gives you for free. What it buys back is full control over exactly what runs, a dependency footprint I can audit in an afternoon, and an install that behaves the same on a five-year-old shared hosting plan as it does anywhere else. For a product whose buyers are hospitals, not tech companies, that trade is the right one. It wouldn't be for every project on this site — it's the right call specifically because of who has to run it.