Case study · Web app · AI
gambeta.ai
Optimization, redesign and security for an AI prediction platform, while it kept running.
Visit the site ↗
- 5,000+
- registered users
- 1,200+
- published, auditable predictions
- 70%+
- hit rate on highest-confidence picks
- 37 → 58
- mobile PageSpeed
- Client
- Gambeta.ai
- Country
- Argentina (audience in 18 languages)
- Industry
- Sports · AI sports analytics
- Services
- Performance optimization · UX/UI redesign · Security audit and hardening · DevOps
- Technologies
- Cloudflare Pages
- Cloudflare Workers
- Supabase (PostgreSQL)
- JavaScript
- esbuild
- GitHub Actions
The client
Gambeta.ai is a free platform of AI-generated sports predictions. It covers more than 38 football leagues, plus tennis, baseball, basketball and other sports in beta. Its promise is transparency: every pick is published before the match and stays in a public record, hits and misses alike.
The project
The product had grown very fast and was in production, with thousands of users and changes several times a day. That pace came at a cost. The site loaded slowly on phones, the interface had piled up sections and styles that didn't fit together, and there were security risks that, on a platform with a public track record, could hurt trust in the brand.
Our work rested on three pillars: making the site fast, making it look and work better, and making it secure. All without stopping daily operations.
The challenge
- Very poor mobile performance
- PageSpeed scored 37 on mobile, with a 12.4 s LCP and 3.8 s of main-thread blocking. For a site people check on their phone right before kickoff, that was critical.
- Heavy assets
- More than 900 team crests added up to 65 MB, a hero video of over 3 MB loaded with high priority, and dictionaries for 18 languages were always downloaded, even though each user reads only one.
- A cluttered interface
- The home page had redundant sections and the prediction cards were hard to read, especially on mobile.
- An exposed attack surface
- Admin credentials had default values, internal endpoints lacked robust authentication, and source code with internal comments was published in production.
Performance optimization
We ran a full audit with Lighthouse and PageSpeed, which produced a plan of 10 independent tasks, prioritized by impact and risk.
- Images
- We reprocessed the 900+ crests without touching the code. They went from 65 MB to 16 MB (−75%) and stayed sharp on high-density screens.
- Hero video
- We re-encoded it from 3.25 MB to 743 KB and changed how it loads.
- Per-language loading
- Each user downloads only their language instead of 820 KB of dictionaries.
- JavaScript
- We moved inline JS into cacheable files, deferred third-party scripts (Google, analytics, Supabase) and reorganized initialization. The longest main-thread task dropped from 5 s to 0.45 s.
- Data
- The home page now downloads 4 times less data to show picks and results.
- Visual stability
- We fixed the critical CSS that caused layout shifts on desktop (CLS of 0.377).
UX/UI redesign
- Prediction cards
- We redesigned them with a clearer 4-block structure, built mobile-first.
- Match preview pages
- The pick in the hero, stats panels, odds and H2H charts, and a share option.
- A simpler home page
- We removed 6 redundant sections and the main HTML went from 397 KB to 262 KB.
- Mobile navigation
- We fixed navigation, horizontal scrolling and results tables, always reflowing content for small screens instead of hiding it.
- Accessibility
- The Lighthouse score reached 97.
Security and hardening
- Admin authentication
- We removed the default credentials. Internal endpoints now fail closed when configuration is missing, the token travels in a header instead of the URL, and we rotated the secrets.
- Admin panel
- Browser actions are validated against the admin's real Supabase session instead of a shared secret.
- Database
- We reviewed row-level security (RLS) policies and view settings, and removed write permissions where they didn't belong.
- Track-record integrity
- We isolated and locked the records altered through unauthorized access, so the public record stays trustworthy.
- Clean production builds
- The pipeline strips internal comments, sourcemaps and debug logs, and stops the deploy if any slip through.
- Content Security Policy
- We implemented it with origins verified in real time, and added WAF rules to block internal routes.
How we worked
We worked in sync with the client's team, in the same time zone. Each optimization had its own branch and pull request. Automated checks run before every deploy, and a script verifies production afterwards. That way the site improved while it kept publishing predictions every day.
The results
- Mobile PageSpeed from 37 to 58
- With LCP down from 12.4 s to 5.3 s and main-thread blocking (TBT) from 3,870 ms to 920 ms.
- Less than a third of the weight
- In images and video.
- Accessibility 97, best practices 96 and SEO 92
- In Lighthouse.
- A clearer, more consistent interface
- Designed for phones.
- A smaller attack surface
- No default credentials, real authentication and no internal code in production.
- A solid base to grow
- More than 5,000 registered users, over 1,200 picks in an auditable record and a hit rate above 70% on highest-confidence predictions.
Conclusion
In a product whose value is trust, performance, design and security are part of the offer, not details. With Gambeta.ai we showed that a platform can be transformed while fully operating, without stopping it: with before-and-after measurements, incremental changes and automated verification at every step.
Does your platform need to be faster, clearer or more secure? Let's talk →