Home Case study

Launchpad

A place to share prototypes, and a way to decide which ones to keep building.

Hand-drawn shelf supporting different ideas and forms on a shared foundation

The gap

By late 2025, people across Mod Op were using coding agents to build working apps. Sharing them was the hard part. Getting a prototype onto a URL still meant a hands-on deploy into infrastructure most people could not touch, so only technical colleagues could show their work, and only with help.

At the same time, I was leading an agency-wide listening tour, asking every team where AI could help them and their clients and where current processes were hurting. We listened most closely for ideas that would serve clients directly. Those conversations produced dozens of ideas for Innovation's 2026 roadmap, more than we could prioritize on paper. Getting stakeholders behind our choices needed evidence, and ideas alone were too theoretical for most people to react to. We needed a cheap way for the teams who would use a thing to try a rough working version of it first.

I built Launchpad to host those prototypes and organized the hackathons that first filled it.

What I built

The first version took me a couple of nights leading up to our February 2026 hackathon, and I shipped it to the team when we kicked off. I wanted the shortest route from finishing a prototype to letting someone else use it, which meant three requirements:

Shareable. A prototype needed a link colleagues in other offices could open. One that only runs on a laptop can't do its job as an alignment tool.

One codebase. Prototypes needed to live together so engineers could reuse work and connect apps that depended on one another.

Self-serve deploys. Six prototypes a day can't wait on an infrastructure request, and engineers shouldn't lose build time to it. Launching an app had to be a commit and a push.

Launchpad was a single repository anyone could commit to. Merging to main triggered an automated deployment to an internal environment behind Nexus sign-in, the same account employees already used for the agency's other AI tools. Each app carried a short block of metadata that added it to a browsable directory with its current status. An engineer could push a change and send a colleague the link.

The first sprint

We brought engineers from Innovation and Mod Op's technology group together for two weeks in February. Each morning I put a set of ideas on the board. Each engineer chose one, spent about four hours building it, deployed it, and recorded a demo to share at the end of the day. Then we did it again.

The team delivered more than 40 prototypes during that sprint. We opened the directory to the whole agency and invited feedback there, so colleagues could react to something they had tried rather than a description of it. That gave us far more specific input for prioritizing the roadmap.

One addition was unplanned. Early in the first week I wrote a Mod Op brand style guide as an agent skill in the repo, so engineers working with Claude could produce prototypes with a consistent look. After a few updates it became the brand skill shared with everyone on the agency's Claude Team plan, and it was folded into Mod Op's own Brand Agent in Nexus.

For several teammates, these two weeks were also their first chance to use a coding agent this extensively. They took the experience back to their teams and helped expand Claude Code use across the technology group.

What we changed in March

Two weeks was too long to sustain that pace, and design suffered when designers were not part of the build. For the second sprint, I shortened the schedule to one week and paired engineers with designers.

Joseph DiGiovanna and Javier Lopez upgraded Launchpad's deployment pipeline to handle the growing collection of apps, and we added a set of Claude slash commands to manage Launchpad apps so designers and developers could work on the same prototype using a shared vocabulary. The March sprint produced more than a dozen additional prototypes, including Nexus MCP, and the design work was noticeably stronger.

Using the work to make decisions

After the hackathons, Launchpad became the place where the agency could follow Innovation's roadmap. Anyone could see a prototype's status and leave feedback. Growth teams used it to find concepts worth raising with clients, and we weighed those conversations alongside internal demand and strategic fit.

When we decided to continue with a concept, we scoped its requirements, worked with the delivery team on engineering specifications, and then built an MVP through a joint design and engineering process. GEO and Audience Lab's digital-twin creative pretesting were among the first concepts to go through that work in 2026.

Client conversations

The week after the first sprint, we brought a prototype built around a client's brand into a meeting with them. It gave us something to use and discuss together instead of a deck, and showed our team's agility - the concept we demoed was based on an idea the client shared with us a few days before the hackathon. The reaction was extremely positive.

In a separate session with a CPG client, we demonstrated the GEO and digital-twin prototypes on that client's own brand data. The session led to a scoped engagement and requests for GEO support and creative development informed by Audience Lab. By August 2026, dozens of client accounts were in active pipeline conversations about concepts that had come through Launchpad.

Hand-drawn team looking across a landscape of ideas and pointing toward a shared direction

After the hackathons

Launchpad kept receiving work from the Innovation and Technology teams, and by August 2026 it hosted more than 70 prototypes. Everyone at Mod Op had access to the directory. Someone with a new build had a place to share it, colleagues could see what was being explored before it became a product, and other builders had somewhere to look for a starting point.