How Gusto Built a New Product Line in 10 Weeks with Claude Code, No Jira, and No Docs

A five-person team inside a thousand-person R&D organization shipped a new product line in ten weeks. In this episode of How I AI, Gusto CTO and co-founder Eddie Kim explains how the team took Gusto Co-founder from a prototype he coded during a flight layover to a tier-one launch.

To do it, they threw out almost every standard process: no Jira, no Figma, no written specs, no standups, and no retros. Their entire operating surface was a persistent Zoom room, and their core development loop relied on Claude Code, which made it cheap enough to build a feature as working code before deciding whether it belonged in the product. See How to Build a New AI Product in 10 Weeks Using the 'No-Process' Method. See How to Fix Bugs Using an AI-Powered Test-Driven Development (TDD) Workflow.

This was a focused experiment, not a claim that every project should abandon its planning tools. Eddie shows how the team made product decisions without a PM, how Gusto Co-founder automates the tedious work before payroll, and how he uses an eval-first loop to fix bugs directly from customer feedback.

Building a new product with (almost) no process

The project began unexpectedly during a five-hour layover in London. After missing a connecting flight, Eddie used the time to prototype an idea with Claude Code. By the time he landed in San Francisco, he had a working demo to show a few senior engineers and a designer.

He shared a Loom of the prototype, and a small group of senior engineers and designer Katie Chen started riffing on the idea. The team formally kicked off the project during a company event in Denver. A single photo of their whiteboard session was the only durable planning artifact from the entire ten-week build.

No Jira, Figma, or written specs

The team stripped away nearly every coordination ritual. Instead of asynchronous documents and scheduled meetings, they relied on two tools to help them make decisions in real time.

"We had no meetings. We had no text specs. We had no Figma. We had no Jira board where we tracked stories or tracked work. We had no standups, no retros. We had nothing."

The entire process was held together by two things:

1. A 'perma-Zoom' room: This was a persistent, 24/7 video call. The remote team could join anytime to pair program, review a pull request, discuss a feature, or just work quietly together. It completely replaced scheduled meetings for the group.
2. Claude Code: The AI coding assistant dramatically reduced the cost of turning an idea into working software. This made it cheap to build something real that the team could evaluate together, rather than debating specs in a document.

The trash can method

The low cost of producing code completely changed how the team treated discarded work. Instead of a written proposal, an engineer could build an entire feature. The pull request itself became the proposal, and the team was perfectly fine with deleting it if they decided against the idea.

An engineer would build out an idea and open a review-ready pull request. The team would jump into the perma-Zoom room to discuss it, then either merge or close it on the spot. Even Eddie’s original prototype, the one he built on the layover, was discarded when the team decided to use a TypeScript and Cloudflare Worker architecture instead.

Designer Katie Chen used the same approach. She shipped a feature-flagged interface to production with canned responses, creating a skeleton of the UI. Engineers then replaced the mock data with real behavior, essentially breathing life into her design in place. This process worked so well that, according to Gusto’s DX data, Katie ranked in the 94th percentile for code throughput across the entire R&D organization, outperforming most classically trained engineers.

Automating the tedious 'work before the work' of payroll

Gusto Co-founder is a conversational agent for handling HR and payroll. The team intentionally designed it to work over SMS and Slack, recognizing that many small business owners are running their companies from their phones, not from behind a desk.

To show how it works, Eddie demonstrated the "work before the work" for a real customer: a massage spa in New York City. Before Co-founder, the owner had a painful, manual process to prepare payroll each week:

1. Export appointment data from MINDBODY.
2. Calculate service commissions and bonuses in Google Sheets.
3. Pool and divide tips among therapists.
4. Enter the final amounts into Gusto for payroll.

Gusto Co-founder automates these tedious preparation steps, turning a multi-tool, manual process into a simple conversation. Crucially, it still preserves the owner's final approval before the payroll is actually submitted.

Instead of manipulating a spreadsheet, the owner can now describe the rules in plain English:

"Hey, Gusto Co-founder, I need you to run my payroll. Look at this spreadsheet that's called Export from mindbody. And here's how I calculate it. You know, for every hot stone upsell, add $15 a bonus for that therapist. For every CBD oil add $20 bonus for that therapist, we pull tips. So just take the group tips amount and divide it by, how many therapists we have."

The agent connects to the spa's Google Sheet, reads the appointment data, calculates all the commissions and tips based on the rules, and presents the final payroll amounts for approval. The real value isn't just running payroll; it's automating the painful 'work before the work' while keeping the human in the loop for the final decision.

Fixing a customer bug with an eval-first loop

Eddie also showed how he, as CTO, jumps into the codebase to fix issues directly from customer feedback.

Test the failure before changing the prompt

Eddie noted that while he was never a strict test-driven developer for traditional code, it has become the standard way his team works on AI behavior. The process starts with a failing test:

1. Start with the evidence. The customer's bug report in GitHub, including the problematic conversation, serves as the description of the failure.
2. Provide context to the agent. Eddie opens Claude Code and dictates his request, pointing the agent to the GitHub issue.

His prompt explicitly requires the agent to reproduce the failure before proposing a fix, a key step in the eval-first loop:

"There's a customer issue that is outlined in this GitHub issue... Can you please read this issue and come up with a fix for the problem that's outlined here? I'd love for you to first write an eval that fails to show that you can reproduce this issue, then come up with a solution, and then prove that the solution works by showing that the eval now passes."

1. Reproduce and repair. Claude Code reads the GitHub issue, writes an evaluation that fails (proving it can reproduce the bug), proposes a code or prompt change, and then reruns the eval to show that the fix works.
2. Review the solution. Eddie inspects the agent's proposed changes for quality and concision. Only after his approval does he ask the agent to open a pull request.

This tight loop combines direct customer context, an agent-generated reproduction and fix, and essential human review. With reviewers always available in the perma-Zoom room, Eddie said the team’s median pull request review time was just nine minutes.

What made the experiment work

This 'no process' process is not a silver bullet. It worked because the five-person team was composed of senior, highly engaged people who were explicitly given permission to break the rules. Eddie also acknowledged that the ten-week launch required nights and weekends. The lesson is not to abolish all process everywhere, but that leaders can and should create a different, faster operating model for focused zero-to-one projects. To do that, they need direct, hands-on experience with the tools themselves.

Eddie's own behavior is the model here. He did not just hand down a prototype and a deadline; he worked as an individual contributor, merged production code, and operated inside the same tight feedback loops as the rest of the team. He was not an executive sponsor; he was a builder.

• What is worth copying is not the absence of Jira. It is the decision to replace speculative documents with software the team can inspect together. The no-process launch workflow works because the team is small, senior, and able to make decisions in the same room. The eval-first bug-fixing workflow is easier to borrow: reproduce the customer failure, make the smallest useful change, rerun the eval, and keep a human responsible for the merge. Both require leaders who understand the tools well enough to work inside the loop, not merely sponsor it.