← Back to Blog

Caliber Is Live: We Launched the Product Our Data Supported, Not the One We Planned

Caliber went public at caliberstats.com after our own review showed the model didn't beat the closing line. What we cut, what we built instead, and the launch-weekend engineering behind it.

LaravelOctober 8, 20266 min readBy Joseph Rajewski
Caliber Is Live: We Launched the Product Our Data Supported, Not the One We Planned

Four weeks ago we published Caliber, Six Months In, a look at our sports-analytics SaaS while it was still in private beta. That post was about infrastructure: one small droplet, a scheduler instead of a queue cluster, and three silent data bugs. This one is about the harder decision. Caliber is now live at caliberstats.com, and the product that launched is not the one we planned to sell. The full build is written up as a case study.

The review that changed the pitch

Caliber was built around a projection model. The beta landing page promised what most products in this space promise: find the edges the market misses, backtested lines, long-term profit. Before going public we did what we tell clients to do with any claim on a marketing page. We checked it against our own data.

The model did not beat the closing line. It produces reasonable projections, and we have the grading history to show it, but "reasonable" is not "profitable," and the beta copy implied the second. So we rewrote the product's positioning around the parts that hold up under scrutiny, and we cut every claim that didn't. The removed list included "Edge Detection," "Historical Backtesting: 50,000+ lines showing which edge profiles produce long-term profit," and a stat strip built on those numbers. Each one was either a profit claim we could not support or a feature that, at the time, only admins could see.

What survived is narrower and more honest: tools for sportsbook promotions, not picks. Profit boosts, bet insurance, bonus bets, and boosted parlays have real, calculable value when you price them against fair odds. That is math, not prediction. Caliber now finds the best bet for each promo, sizes the stake, and tracks how each promo strategy actually performs, with a flag when one stops earning. The projections are still there, framed as research with a public track record, good or bad.

The irony is not lost on us that one of the redirect domains pointing at caliberstats.com is caliberpicks.com.

Launch weekend, by the numbers

The repositioning came with a lot of building. Launch weekend itself (October 2 and 3) touched 309 files: about 8,800 lines added and 2,700 removed. The highlights:

  • Paid plans, live payments. Three tiers: Single Sport at $9.99/month, 3 Sports at $19.99, and All Access (all 14 sports) at $29.99, with 6-month and annual options. Checkout is embedded on caliberstats.com rather than redirecting to a hosted page, and themed to match the app. A 7-day money-back guarantee is enforced in the product, with a consent checkbox at checkout and a guarantee column in the admin view.
  • Per-sport paywall with a swap rule. Single and 3 Sports subscribers can change their sports without paying again, within limits. Without that constraint, the cheapest tier becomes a slow path to the most expensive one. It is a small config block that protects the top tier.
  • Free calculators as the front door. Profit boost, bonus bet (with hedge), and bet insurance calculators are public, prerendered pages built for search. They are the honest version of a lead magnet: useful on their own, and a natural step toward the paid finder.
  • 14 sports of live scores, up from 3 (NBA, NHL, NCAAM), with scoreboard logos for every league.
  • Account operations a real business needs: login lockout with admin alerts, password reset, subscription emails (welcome, plan changed, sports changed, canceled) with light and dark layouts, plus admin tools to suspend accounts and email individual users.

Making it fast for people who aren't us

A beta used by its builders on fast connections hides performance problems. Google's PageSpeed test on the launch build hid nothing: mobile 72, with a 4.7-second Largest Contentful Paint. The headline only painted after the app's JavaScript ran, while competing with 178 KB of analytics script on a simulated slow 4G connection. We have written before about which Core Web Vitals actually matter, and this was a textbook case of the one that does.

The fixes were unglamorous and effective:

  • Static hero that matches the app. The HTML now ships the same headline markup React renders, so the largest element paints at first paint and React swaps in an identical element with no layout shift.
  • Analytics after the page, not before it. Google Analytics loads after window load and idle time, with events queued until it arrives.
  • An icon font of 35 icons instead of 1,400. A CDN icon library (22 KB of render-blocking CSS plus a 156 KB font) became a self-hosted subset of the icons the app actually uses: 4.9 KB total.
  • Code-split the logged-in app. The dashboard, admin, and checkout load after sign-in, cutting the main bundle from 372 KB to 205 KB (110 KB to 65 KB gzipped). The free calculators stay in the main bundle because they are the search landing pages.

The result, on the same simulated slow 4G connection:

Page (mobile)BeforeAfter
Home72, headline at 4.7 s98, headline at 2.0 s, no layout shift
Bonus bet calculator82100, headline at 1.1 s, 0 ms blocking time

Desktop was already at 98. None of this is novel, and it is the same playbook we used to get 100 PageSpeed on this site. All of it is the kind of work that gets skipped when a product is only ever opened by the people who built it.

And then we upgraded the framework

The day after launch, Caliber moved from Laravel 10 to Laravel 13, along with Sanctum 4, Carbon 3, and PHPUnit 12. We wrote about why we picked Laravel for this product when the bet was still unproven, and the upgrade is the clearest evidence for the part of that argument about staying on a supported release. The ordering was deliberate. Laravel 10 is past end of life, so the upgrade was not optional, but it also was not something to ship on the same day the payment switch flipped. Keeping them apart kept the variables apart: if anything broke on Saturday, we knew it was the framework and not the payment flow.

What we'd tell a client launching a beta

  1. Audit your marketing claims against your own data before launch. If the numbers don't support the pitch, change the pitch. Unsupported profit claims in regulated or semi-regulated categories carry real advertising-rule and chargeback risk, on top of the credibility cost.
  2. Test performance as a stranger would. Slow phone, cold cache, no login. The number you get will be worse than the one you feel.
  3. Separate risky changes from launch. Launch, stabilize, then upgrade. A framework upgrade and a payment go-live in the same deploy makes every bug ambiguous.

Six months in, we said the case for Laravel was that it scales down gracefully. Launch added a second lesson. The best outcome of building the analytics was discovering what the analytics could not honestly claim. Building in public means publishing that part too.

If you have a beta that needs to become a business, with payments, security, performance, and claims that hold up, get in touch. We just did it for ourselves.

#laravel#saas#case-study#launch#caliber

Need help with your project?

Let's discuss how Digital Pixel can help bring your vision to life.

Get in Touch