How Fantasy Shipped LIV Golf in 72 Days
A live broadcast doesn't wait
THE SHORT VERSION
Fantasy built and shipped LIV Golf's mobile app in 72 business days, then its website, by running AI through every layer of the build while keeping human review on every change.
A live broadcast doesn't wait
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.
In the week the mobile app shipped to the store, a team of five merged 88 pull requests, every one of them reviewed first. Months later, when the LIV Golf website launched, a team the same size merged 102 in its final week. Teams that size do not usually move that fast, and they almost never maintain their quality while doing so.
What made the difference was treating AI as core infrastructure across the whole project, augmenting the team at every phase rather than in a single part of it.
AI at every level
When people hear that an agency used AI to build something, they usually imagine one moment. A designer hands over a mockup, and AI turns it into working code. That happened on LIV Golf, too, but it was just a small piece of the job. Focusing on the Design-to-code process is important (and an evolving topic that we will return to in the future), but we feel this story is broader and deeper.
We used AI at every level of the engineering work, from gathering requirements and shaping the technical architecture to the code itself. We built the designs so that AI could turn them into code, and we checked the interface automatically, with generated tests, as it came together.
We used a method I'll explain in a minute to build everything underneath the app too: the service that feeds it live scoring, the system the client's staff use to publish during an event, the personalized feed every user sees, and the cloud infrastructure that keeps all of it running during a global broadcast. We've gotten better at this on every project, and LIV Golf is where it came together.
This is not vibe coding
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. How we keep that control while still moving fast is the rest of the story.
First, we had to learn to trust it
We didn't start with LIV Golf. From the middle of 2025, we worked on two other client projects, Mars Veterinary Health and Panasonic Well, and on both we found a dependable way to let AI do real development work that went beyond clever autocomplete.
What we arrived at is called spec-driven development. Before the AI writes a line of code, you write a detailed description of what you want, the patterns it should follow, and the rules it has to obey. The AI then builds from that description.
It's the difference between handing a contractor a blueprint and telling them to build a nice house. Once you control what the AI knows and give it a real specification, the quality climbs and the output stops surprising you.
Mars and Panasonic settled the question for us. AI could handle front-end development, the part of the app people see and touch, and it could start handling the work behind it, as long as we stayed disciplined about what we fed it and wrapped the output in a careful process. Having proved the approach on both, we felt confident stepping up to the 72-day LIV Golf challenge and taking it somewhere much harder.
What the LIV Golf build actually required
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.
The mobile app is where the clock was tightest. We shipped it to the App Store in 72 days, counting from the first day of the engagement through design, build, and release. That number is easy to misread, so let me be exact. It covers the whole engagement for the mobile app, design included, and it's the mobile app alone. We did not build all of LIV Golf in 72 days.
It was two products, not one. The mobile app came first, built in React Native with Expo and Unistyles, a common way to ship a single app to both iPhone and Android. Once it was live and we were supporting it in parallel, the design team rolled straight from the mobile work into the website, and web development got underway in February, built in Next.js. The website launched later that spring. We ran two separate teams of five and kept the same senior technology leadership across both, which is part of why the second build went the way it did.
A fixed launch date on a build that large is the kind of problem most agencies solve by throwing bodies at it, or by quietly cutting scope. We took a different route.
AI SHOWED UP AT EVERY LAYER
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.
Thinking, before we built anything
Some of the most useful AI work happened before a line of app code existed.
Our architects designed the system, and they used AI to stress-test that design and find its weak spots. We did not hand the architecture to a model. We built it ourselves and used AI to make a stronger version of it.
The same went for platform decisions, where we put content systems side by side, Sanity against Contentful against Payload. AI didn't make the call, but it translated vendor responses, ran deep research, and turned noisy inputs into clear evaluation criteria so we could. It drafted our documentation too, though left to its own devices it runs relentlessly wordy, so part of the craft was holding it to only what mattered.
Between editing their output and drawing architecture diagrams in Mermaid, a text-based diagramming tool, we got aligned with the client's technical stakeholders within weeks, not the months this would have taken a few years ago.
Turning designs into code
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, working up from the smallest building blocks to larger assemblies.
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.
Building the content system
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.
Building the live data layer
A golf app is only useful if it knows what's happening on the course, and all of that data came from the client and their partners.
We built a set of middleware to pull it together. At the center sat a GraphQL gateway, a single service the apps could query for anything they needed instead of talking to a dozen data sources directly. We built it on Apollo and Fastify and backed it with a Redis cache that held the latest data, abstracting away the client's various stats, real-time feeds, tournament data, and third-party partners. The apps talked to this backend for frontend (BFF) over plain HTTP, and we generated their data-fetching code automatically from our queries, then cached it with React Query, which removed a whole class of tedious, error-prone work without costing us type safety.
Running alongside the gateway was a real-time service built on server-sent events, or SSE, a lightweight way for a server to push updates the instant they happen. Any client, web or mobile, could subscribe, and the moment a score or an event status changed, every subscriber heard about it at once.
Building the personalized feed
Every user got their own feed, which we called For You. We built it on Elasticsearch, a fast search and indexing engine, so we could serve relevant results quickly and keep tuning them as someone interacted with content. That drove an endless, TikTok-style scroll in the mobile app.
Before we committed to the approach, we used AI to run a quick proof of concept that confirmed it would hold up under heavy real-world use, with people constantly marking content as seen.
Building the cloud infrastructure
The servers and services that run everything were written as code, with Terraform, Terragrunt, and GitHub Actions, so they can be rebuilt and scaled on their own. We spread them across regions so the system stays up under load and recovers from trouble without us during a worldwide event. AI helped build this layer too, out to the automated pipeline that tests and ships new code.
So none of this lived only on the screen. The same approach ran from the infrastructure at the bottom to the build pipeline at the top, with AI in the loop the entire way and people watching it.
Why we still trusted the result
We did not let AI run loose. Moving fast made review more important, not less, so we built it in at several points. Every pull request, the package of changes a developer submits, went through an automatic pipeline of checks first: linting, type checking, and other static analysis that catches errors and enforces consistency before a human looks at anything.
First, and automatically, a separate AI reviewer went over every change and flagged problems, including the kind of mistakes our own method can introduce, a layer most teams don't have. After that, another engineer reviewed the change and signed off before it merged, the way they would on any enterprise project.
We chose carefully where to spend human attention. Routine, low-risk work could run almost entirely on AI, while anything risky or important got real eyes on it. None of that speed removed responsibility. Every change that shipped had a person who signed off on it and went through full QA, even after the code was committed.
There is a fair worry about AI-written code
Which is that it produces more of everything, defects included, and that the extra volume 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.
What this let the team do
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.
Because AI let us hand off work quickly, give one person oversight of a whole area, and bring new people up to speed in days, we could grow to meet the scope and still move faster than a traditional project of the same size.
At its peak the engagement ran with a tech director, a tech lead, two product managers, and a technical program manager, plus four engineers and a QA engineer on mobile, and four engineers, a QA engineer, and a QA analyst on web.
Come back to those launch-week numbers, because they carry the argument. In the week the mobile app shipped, its team of five merged 88 pull requests. When the website shipped, its team of five merged 102. Every one passed the automated checks, and the higher-stakes changes passed human review on top of that, scaled to how critical the feature was.
A conventional team that size, working the conventional way, can't keep that pace at that level of rigor.
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's 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 obvious question
Would this have taken a bigger team without AI?
Probably not a smaller one, and maybe a larger one. But headcount is the wrong way to think about it, because adding people is never free. When an agency is staring down a hard deadline, the usual move is to quietly trim the product vision to protect the date and the budget.
Bigger teams tend to make that worse rather than better. They add some throughput while wearing down quality and consistency, and past a point another engineer just pushes the bottleneck somewhere else, usually back upstream to the question of what to build at all.
A senior team with AI behind it doesn't hit that wall as fast. We still had to think hard about what to build. We could just build it, and rebuild it, much faster, without cutting quality to make the date. For years our conversations with clients have started with what they would have to give up. This one started with how much we could actually do.
For years our conversations with clients have started with what they would have to give up. This one started with how much we could actually do.
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.
Manageable scale came down to one idea
We treated the codebase as a shared brain. The rules, the architecture, and the standards lived in the code itself, so AI enforced them across everyone's work, and anyone who pulled the latest code pulled the latest thinking along with it. The AI could check whether a component already existed before someone rebuilt it, which kept the work consistent and stopped people from quietly duplicating each other.
It also made onboarding fast. A new engineer was usually opening reviewed pull requests by their third day on the project and fully productive after that, because the codebase itself explained how the code worked and how it was organized around the task in front of them. Review got easier too, since the same tools could point out where someone had misunderstood something before a human reviewer ever saw it.
The ground kept moving while we built
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.
You can't stop a team mid-deadline and have everyone relearn their craft. So the habit that mattered most was writing down what we learned as we went, in plain files checked into the project, so our systems and our people got smarter together.
That turns a project into a place where research and development happen continuously, and it lets a lesson from one project travel out to the next one, or to someone waiting between projects.
The advantage was the habit itself, learning fast and passing it around, more than any particular tool we happened to be using that month.
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're still getting better.
It's 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'll go deeper into the parts we only touched here:
1 - How design becomes code and code becomes design
2 - How we prototype in working software instead of static mockups
3 - How product management changes when AI is in the loop
Ready to build what's next?
In the meantime, if you're ready to build or scale your system for the next era, our team are ready to help.