Revised August 2026. An earlier version of this post described parts of the architecture as we had sketched them during planning rather than as we shipped them. This version matches what actually runs in production. We think the corrected story is more useful, and franker, than the original.
Caliber is a multi-sport predictive analytics SaaS we built end to end: a modeling engine that generates projections across more than a dozen sports, grades them against closing lines, and surfaces pick recommendations with confidence grading, wrapped in a React dashboard with line-movement alerts and bankroll tracking. It runs on Laravel. This post is an honest account of why, and of how little of Laravel it turned out to need.
What we were optimizing for
Four things, in priority order:
- Time to first production data. A predictive model is worthless until it has real games flowing through it. The gap between first commit and first ingested game needed to be days, not weeks. It ended up being three: first commit February 24, first production data February 27.
- A pipeline that runs itself. Caliber's work is rhythmic: pull scores during game hours, pull odds through the day, grade and recalibrate overnight. The system had to run that rhythm unattended.
- A small team that could hold the whole thing in its head. The stack had to be productive for a very small senior team, with no room for infrastructure that needs its own babysitter.
- Cost discipline. The product needed to prove its model before it earned a real infrastructure budget. Every architectural choice had to survive the question: does this pay rent at validation scale?
What we looked at
Node/Express + Prisma. Fast to prototype, but the ecosystem for scheduled work, authentication, and admin tooling is fragmented. We would be gluing together five libraries to get what a mature framework gives you in one.
Django. Strong ORM, battle-tested, and Python is the native language of the modeling world. A defensible choice here. We had more recent Laravel shipping experience, and the framework-level conveniences we cared about tilted Laravel.
Ruby on Rails. Excellent developer experience, and we would have been fine here. The honest reason we passed: our own recent experience and the long-term hiring pool both favored PHP.
Laravel + React. Our final choice. A mature, opinionated backend with first-class answers to the problems we knew we would hit, and a frontend stack we use across client work.
The Laravel features that actually mattered
Most framework comparisons list features nobody uses. Here is what earns its keep in production, and the list is shorter than we expected.
The scheduler, above everything
Caliber's entire pipeline is artisan commands on Laravel's scheduler: a live-score ingester that runs every minute during game hours, odds pulls several times a day, grading and model recalibration overnight. There is no queue, no worker fleet, and no message broker, because nothing in the workload needs one. No user is waiting on ingestion, so a scheduled command that runs to completion beats a queue we would have to operate.
This was the biggest surprise of the build. We went in weighing Laravel's heavy machinery: queues, Horizon's worker dashboards, Telescope's debug panel. We deliberately deferred all of it, with a simple rule: adopt each piece when the workload demonstrates the need, not when the architecture diagram looks impressive. Six months of production later, the need has not materialized, and adding a new nightly pipeline stage is about ten lines in one file.
Eloquent, used lightly
Games, projections, grades, closing lines: the data model is real but not exotic. Eloquent keeps the pipeline code readable, and we drop toward the query builder where an aggregation gets serious. The discipline is knowing that Eloquent's ergonomics make it tempting to overuse; more on that below.
Sanctum for API auth
The React dashboard talks to the Laravel API with Sanctum handling authentication. Minimal configuration, no OAuth dance, no hand-rolled token logic. It is one of five production dependencies, and it has never demanded attention since setup, which is the highest compliment an auth layer can get.
Tinker as a production instrument
artisan tinker over SSH is our production debugging story: inspect real data, test a hypothesis, verify a fix, all from a laptop without a debug deploy. On a data product, the ability to interrogate production state interactively is worth more than any dashboard we deferred.
What we built
The architecture, in full:
- Laravel 10 API serving JSON to a React dashboard
- Five production dependencies: guzzle, sanctum, tinker, phpspreadsheet, and stripe-php
- One DigitalOcean droplet: 1 vCPU, 1 GB of RAM, the $7-a-month tier
- Native nginx and PHP, no containers, no orchestration
- Deploys as a git bundle over SSH
- $0 in data costs: every feed we ingest (ESPN, the official MLB StatsAPI, MoneyPuck, Barttorvik) is free and public
That is the whole diagram. The modeling layer is where the engineering effort lives; the infrastructure's job is to stay out of the way.
The gotchas
Being honest about where the choices cost us.
Minimalism means no dashboards. Skipping Horizon and Telescope means observability is logs, the database, and tinker. That trade is right for this team size, but it puts the burden of noticing problems on discipline rather than tooling. On a data product, the failures that matter are silent ones, and we have had to build our own guards for data sanity rather than inheriting them from the ecosystem.
Eloquent is tempting to overuse. The ergonomics are so good that you can end up with twenty queries behind a single view without noticing. Without Telescope watching, the discipline has to come from code review and from knowing when to reach for the query builder.
Ecosystem lock-in is real, but smaller when you use less. Sanctum and tinker are Laravel-shaped, and the scheduler idiom is too. Five dependencies keeps the surface small, but nobody should pretend a Laravel codebase ports anywhere for free.
Would we choose it again?
Yes. For a small team shipping a data product fast on a validation budget, Laravel was the right call, though not for the reason the framework's marketing would suggest. The heavy machinery is genuinely good, but what won us over is that Laravel scales down: a scheduler, a handful of artisan commands, five dependencies, and a $7 server is a legitimate production architecture, and the framework never charges you for the parts you leave switched off.
Where we would think harder:
- A real-time product (live collaboration, chat, streaming dashboards) would push us toward a websocket-native runtime for that layer.
- A Python-heavy team building the same product should probably choose Django and keep the modeling and the framework in one language.
For the Caliber profile, a scheduled-pipeline analytics SaaS built by a small senior team, it still looks like the right call from here.
If you're evaluating Laravel for a SaaS build and want to talk through your architecture, get in touch.
