The Trashcan Method: Why Speed Wins When You Stop Planning

Gusto CTO Eddie Kim suggests a counterintuitive idea: the best way to build a high-quality product is to get rid of the standard artifacts of software development. By dropping Jira, formal documentation, and design specs in favor of a trashcan method where code is treated as disposable, Kim’s team shipped a major product line in 10 weeks. This approach is not just about speed. It is a systemic change that uses the low cost of AI-generated code to prioritize iteration over perfection. For technical leaders and product managers, the advantage comes from moving from a planning mindset to a maker mindset, where immediate feedback loops replace the slow and often inaccurate process of upfront documentation.

The Hidden Cost of Perfect Processes

Most organizations treat code as a permanent asset. This forces teams to spend significant time on planning, documentation, and design specs to avoid wasted effort. Kim argues that this conventional wisdom is now obsolete. By treating code as disposable, teams can explore radical architectural changes without the emotional or temporal weight of sunk costs.

I call this the trashcan method of software engineering right now where you can actually trash all the code, start like a slash V2 branch and rebuild it from scratch. And it is totally reasonable to do because the cost of the code is so low.

-- Eddie Kim

When the cost of writing code drops, the trashcan method becomes a competitive advantage. It allows teams to build, validate, and delete features that do not meet the product bar. By refusing to document the why and how in static files, the team ensures the only source of truth is the code itself, which remains functional and up to date.

Why Immediate Pain Creates Lasting Moats

The trashcan method is uncomfortable because it requires moving away from traditional corporate safety nets. Kim’s team worked without PMs, standups, or Jira boards, relying instead on a perma-Zoom room that allowed for near-instant feedback. This creates a system where the bottleneck is not process but conviction.

The most interesting dynamic here is how this structure changes team composition. Because the team was small (four engineers and one designer) and the feedback loop was tight, the designer was able to ship production-grade code at a rate that rivaled senior engineers.

We took the time to pair with her, whereas I think a lot of engineers, what I hear them say is like, well, it just slows us down... and yeah, that is true in the short term, but now I think once you make that investment you have a support of software developer around her or any designer, I think dividends pay off really quickly.

-- Eddie Kim

By prioritizing the mentorship of non-technical contributors, the team expanded its total output. The system responds to this by normalizing high-frequency shipping, making the team faster than those buried under the weight of process and coordination.

The 10-Week Payoff: Shipping in Production

The team did not just build a prototype; they built in production from day one. They used a fake front-end experience behind a feature flag, which was then gradually replaced by real data models and backend logic. This creates a powerful feedback loop: the product is always live, and the team is always responding to the reality of the system rather than the theory of a spec.

This approach creates a clear separation between teams that plan and teams that materialize. While competitors are still debating the scope of a Q4 roadmap, teams using this method have already shipped, tested, and iterated through multiple versions of a product. The advantage is not just speed; it is the ability to learn from actual customer interaction while others are still guessing.

Key Action Items

• Implement the Trashcan Method: Start treating features as experiments. If a PR does not meet the product bar or architectural standard, delete it. Do not force-fit code that does not belong.
• Establish a Perma-Zoom or Virtual War Room: Remove the friction of scheduling meetings. Create a persistent space where the team can pair-program and conduct PR reviews in real-time.
• Prioritize PR Reviews for Non-Technical Teammates: Treat PRs from designers and PMs with the same urgency as engineering PRs (aim for under 10 minute turnaround). This creates a culture of shared ownership and technical growth.
• Adopt an Eval-First Workflow: Before writing code to fix a bug or add a feature, write a failing eval. Use this to prove the issue exists and to verify the fix once implemented.
• Shift Leadership Toward IC Work: If you are a technical leader, get back into the codebase. You cannot effectively set AI strategy if you are not feeling the friction and the power of the tools yourself.
• Audit Your Work Before the Work: Identify manual processes (like manual data entry or spreadsheet calculations) that customers perform to use your product. Build AI connectors to automate these steps directly into your workflow.