How Fantasy Shipped LIV Golf in 72 Days

When a LIV Golf event goes live, the app has to keep pace with a broadcast watched around the world. A score changes the instant a putt drops, and the app has to change with it, in sync across television, streaming, and the web. We built and shipped the mobile app that does that in 72 business days, from the first day of the engagement to the App Store, in time for the league's first event of the season at the end of January 2026.

Clients ask us about one thing more than anything else, so let me deal with it up front. This is not vibe coding. Vibe coding is when you let an AI improvise a solution and take whatever it gives you, which means the result is unpredictable and usually overbuilt, inconsistent, and light on security. We do the opposite. We're on the hook for a system that behaves and looks exactly the way we designed it and that holds up to enterprise standards for security and architecture.

We didn't start with LIV Golf. From the middle of 2025 we ran a careful set of experiments on two other client projects, Mars Veterinary Health and Panasonic Well. We were trying to find a dependable way to let AI do real development work instead of treating it as a clever autocomplete.

LIV Golf is a global golf league, and the product had to work during events held all over the world. These aren't simple broadcasts. Each event is a simulcast that runs across television and digital platforms at once, streaming services included, so the app had to stay in step with everything else happening around a live tournament.

AI wasn't confined to one corner of the project. It showed up in every layer of the stack, so let me walk through them.

This is the part people picture, and we built a careful pipeline for it. Designers worked in Figma, with their files structured so a machine could read them cleanly. From that structured design, AI built each piece as a small, self-contained component. We reviewed every component on its own in Storybook, checking it for accessibility and visual accuracy before it went anywhere near the app. That gave us an experience assembled from high-quality parts that matched the designs exactly.

A live golf product needs the client's own staff to publish stories, scores, and updates while an event is underway. We turned the requirements from our design, UX, and business teams into specifications, then used AI to build both the underlying content system and the dashboard the staff would run it from.

We did not let AI run loose. Moving fast made review more important, not less, so we built it in at several points.

There is a fair worry about AI-written code, which is that it produces more of everything, defects included, and just shoves the problem downstream into review. Our process is built to prevent that. The specification constrains what the AI can produce before it produces it, so there's less to catch later, and the layered review catches what is left. The bugs people associate with AI code tend to come from letting it improvise with neither a specification in front of it nor a real review behind it. We did neither.

People assume the lesson here is that AI lets you run a smaller team. That's not what happened. We scaled the team up, and the payoff was how much that larger team could produce.

Those weeks were peaks, not the whole story. Across the mobile build the team merged about 700 reviewed pull requests, holding a steady week-after-week pace long after the app went live. The website added roughly 480 more. That is close to 1,200 reviewed, merged changes across the two builds, and the pace held for months rather than spiking for a single week before a deadline.

The people mattered as much as the tools. We staffed senior. Plenty of agencies lean on junior talent, and junior people are the most likely to produce AI slop and the least able to tell it apart from good work. Experienced engineers catch it. Our leads also stayed hands-on instead of hovering above the work, writing critical parts of the product, reviewing code, and merging changes themselves.

Our process didn't hold still. It changed more than once during LIV Golf, because the tools and the models underneath us kept improving while we worked.

So what does all of this add up to? AI ran through the entire project, from the screen down to the infrastructure, and the result was a large, complicated product built faster and to a higher standard than the old way would have allowed.

What happens next is that these techniques stop being special. Spec-driven development, the thing we leaned on hardest, is already on its way to being something everyone does. The frontier models can now do much of what our hand-built process did a year ago, and the gap keeps closing. So the edge can't be the technique itself. It has to be the ability to improve the technique faster than anyone else, to treat our own process as something we research and rebuild constantly and feed straight back into live client work. LIV Golf is where we got good at that, and we are still getting better.

It has changed how we describe ourselves, too. Fantasy designs and builds your product, but that's not the whole of it. We're also a process R&D partner, which means part of what you're buying is a delivery process that keeps improving while it runs. The technology under all of this turns over every few months. You can't solve for that once and move on. You have to keep adjusting to it, and that's the part most teams aren't built to do.

This is the first piece we're publishing on how we work, and more are coming. In the ones that follow, we will go deeper into the parts we only touched here: how design becomes code and code becomes design, how we prototype in working software instead of static mockups, and how product management changes when AI is in the loop.