By Will Gibson, Principal Product Manager, Podium
In the world of sportsbook technology, speed, scale, and precision are everything. At Podium, we build platforms that power the global betting industry, from real-time racing data to odds modelling and analytics. But the tools we build to help ourselves innovate internally are just as important as the products we supply to our customers, and this is a key part of my role at Podium to ensure we remain at the forefront of what we do.
That philosophy came to life recently with our Racing API UI project: a proof-of-concept that quickly evolved into a hugely valuable internal tool, transforming how we engage with and showcase our horseracing data.
The Problem: Complex Data, Unseen Potential
Podium’s Racing API delivers huge quantities of detailed, deeply structured data – a fully populated meeting can span 40,000 lines of JSON, and let’s be honest, that’s a dry read. Whether you were a salesperson looking to demonstrate the richness of the data in the API, an operations team member monitoring our output, or a developer testing new features, getting to the data you wanted could require a bit of effort, and a bit of knowledge of the API. It was all there, including the ability to filter and minimise data responses, but there was a fundamental UX problem to be solved in terms of helping people get straight to what they need.
The product need was clear: build a web-based UI that exposed the richness of our data in a clean, simple way. But by our traditional delivery models, the UX and design process, dev cycles, QA, and stakeholder reviews, made this a 6 to 12-week job. And like many companies optimising for output, dedicated resources simply weren’t available.
The Solution: Product-Driven, AI-Assisted Development
Instead of waiting for delivery resource that may never become available, I took a different approach. There’s AI assisted UI creation tools out, but I felt you could take it a step further by integrating the UI design and the code creation into one single process. Using Vercel, I realised I could integrate our API into their UI creation tool, and once you’ve got the two systems talking to one another, it becomes a question of “What data do you want to display, and where do you want to display it”
Within three weeks, working in short daily bursts (the free version gets you ten requests a day), a functional v1 was live. It included:
– Secure API credential authentication
– Retrieving data from our stages endpoint
– Live race card and event responses, including auto updates
– Entrant metadata and silks
– Tertiary data analysis not possible in the native responses – things like overround calculations for races, or searching for processing failures in the data stack.
– Swift iteration around UI improvements or changes
– I could easily share the updated versions of the app with colleagues for swift review and feedback.
What We Learned (and Why It Matters)
• AI-Enhanced Product Development Works, When Done Right
I didn’t want to throw up a UI proof of concept. I wanted to build a viable product that could be handed to the business to use. It was an example of how AI can compress traditional product cycles, from UX ideation to development, into minutes instead of days. As a product manager I always have the fear around failing to capture every feature, but in this world, if you find you’re missing something, that’s just another round of prompts. It is agile in the truest sense of the word.
• Empowered Product Managers Build Better, quicker MVPs
Product-led development using AI enabled rapid iteration, reduced the risk of miscommunication, and allowed a clearer vision to be executed directly, without bottlenecks. There’s less back and forth between users and designers, in a really good way. If the MVP isn’t what they were expecting, you can turn around an update in an hour rather than a week. The threshold you can achieve for an MVP is so much higher, because you’re not sucking up dev and UX resource in iterating.
• Visible data is valuable data
Making our Racing API data visible in a UI helped us to uncover some data quality issues. Without this tool, those errors might have reached customers unnoticed. It’s now an essential QA and review layer, adopted by developers, product manager and operations.
• Good Enough Isn’t Production Ready
The code worked but it wasn’t to Podium’s standards. AI-built code still needs developer review, refactoring, and QA test suites before it can be productionised. Whilst the code that was generated worked it wasn’t efficiently written, and our developers still had to invest time in making this align with our coding standards, getting in onto github, and integrating it within our existing test and deployment pipelines.
• Internal Tools ≠ B2C Products
This approach worked because the UI was designed for internal users and needed to be good enough, as opposed to best in class. In my eyes, the app that I produced wasn’t ideal for polished, customer-facing platforms – brand, performance, and UX fidelity will still require input. However you can provide a great foundation that covers the needs of your internal users.
Outcome: Tangible Value at a Fraction of the Cost
We logged ~160 hours across product and dev (about five developer weeks) to this from idea to deployed. That’s a fraction of the ~500 hours we estimated a standard delivery would take. The UI is now live on an internal company, integrated into our dev stack, and used across teams to explore data, run reports, and validate real-time API responses.
More importantly, it’s a blueprint for a new kind of product innovation at Podium, one where empowered individuals, smart tools, and pragmatic scope can unlock value faster than ever before.
Explore More
Podium is redefining how sportsbook data is built, visualised, and delivered. Whether it’s high-frequency racing APIs, embedded pricing services, or internal tools that accelerate development, we build for performance at every layer.
Connect with Will here: https://www.linkedin.com/in/will-gibson-41aa5010/
