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.

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 don't usually move that fast, and they almost never hold their quality while they do. What made the difference was using AI across the whole build rather than in a single part of it.

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, and it was the smallest piece of the job. Focusing on it tells you almost nothing about what AI actually did here.

We used AI at every level of the engineering work. We built the designs so that AI could turn them into code, and we checked the interface automatically 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.

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.

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.

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.

Those two projects 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. By the time LIV Golf came along, we were confident we could take the approach somewhere much harder.

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 business days, counting from the first day of the engagement through design, build, and release, in time for the season's first event at the end of January 2026. That number is easy to misread, so let me be exact. It covers the whole engagement for the mobile app, design included, not just the coding, and it is the mobile app alone. We did not build all of LIV Golf in 72 days. We shipped the app, kept iterating on it, and carried the work into the website from there.

It was two products, not one. The mobile app came first, built in React Native, 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, a popular framework for fast, modern websites. 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. We took a different route.

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, to choose the right one. AI also helped us write documentation at the right level. Left to their own devices, large language models are relentlessly wordy, so part of the craft was holding them to only what mattered. Between editing their output and using AI to draw architecture diagrams in Mermaid, a text-based diagramming tool, we got aligned with the client's technical stakeholders quickly.

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. The same pipeline ran for the mobile app and the website.

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, which held the latest data and let us abstract away from the client's various stats and real-time feeds. The apps talked to that gateway over plain HTTP, and we generated their data-fetching code automatically from our queries, then cached it with React Query. Generating that code instead of writing it by hand 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 4U. 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, 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.

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. After that, another engineer reviewed the change before it merged, the way they would on any serious project. Then we added a layer most teams don't have. A separate AI reviewed the work and flagged problems, including the kind of mistakes our own method can introduce. 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 had signed off on it.

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.

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. That is a real team. What matters is how much it produced in the time it had.

Come back to those launch-week numbers, because they carry the argument. A pull request is a single, self-contained change submitted for review. In the week the mobile app shipped, its team of five merged 88 of them. 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 and continuing to ship at that rhythm 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 numbers also show the process improving as it went. The mobile team worked out practices mid-build that the web team inherited, which is part of why the web build ran even hotter in its final stretch.

The obvious question is whether this would 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.

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.

A lot of what made the scale manageable 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.

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 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.