The founding scene is not a garage. It is a five-hour commute through the Midwest, two software consultants comparing project scars, followed by dinner at a Chili's. Todd Kaufman had vetoed Outback Steakhouse as too expensive. This detail matters. Test Double, the firm Kaufman and Justin Searls started in 2011, has spent 15 years making restraint look like a strategy: save cash, avoid dependency, modernize in increments, and do not sell a client more machinery than the problem requires.
Today the Westerville, Ohio company has more than 100 consultants and says it has worked on more than 1,000 projects, from startups to Fortune 100 companies. Its menu now covers software delivery, product strategy, DevOps, legacy modernization, Rails upgrades, technical recruiting, due diligence, and practical uses of AI. In plain English, clients call when an important software investment is stuck: releases are slow, the codebase frightens its own maintainers, priorities multiply, cloud bills climb, or a deal needs technical scrutiny before money changes hands.
The customers named in its work include Gusto, GitHub, Zendesk, Betterment, Mode, Clever and Hospital Referral Services. The engagement shape varies, but the operating move is consistent. Experienced engineers and product managers join the client team remotely, learn the business constraints, ship alongside the people already there, and transfer the knowledge. Test Double's consultants average roughly 15 years of software experience; its product consultants average about 12. The premium is judgment acquired the slow way.
The first failure was the incentive system
Kaufman and Searls did not start with a novel programming technique. They started with an objection. At their previous consultancies, salespeople could promise a date, a scope and a team before the people doing the work had properly understood the problem. The project began with fiction already in the schedule. Consultants were rewarded for remaining billable; clients could become dependent; developers absorbed the consequences.
Their counter-design was a consultancy run closer to the code. Identify root causes instead of applying patches. Prefer quality that keeps future changes affordable. Give senior people enough autonomy to tell a client when the requested solution misses the actual problem. Then leave the team stronger, not merely with a new stack of invoices. Growth came through referrals, Searls's conference presence and a reputation in the Ruby on Rails community, rather than a giant sales engine.
The founders were cautious about the business underneath that ideal. They invoiced, got paid and banked as many months of payroll as possible in case demand disappeared. In a 2018 talk, when Test Double had about 45 people and 14 active clients, Searls described financial runway as the foundation that made confident hiring possible. Kaufman supplied the emotional argument: every hire could be a small developer rescue, offering capable people more autonomy, flexibility and a healthier relationship with work.
The owners are the people on the call
In April 2020, the founders made their oddest and most revealing move. They converted the business into an employee stock ownership plan. Workers receive shares over time without buying them, and the company is now 100 percent employee-owned. This was not a venture exit. It was a correction: Kaufman and Searls believed the widening team, not the two founders, was creating an increasing share of the value.
Employee ownership does not automatically produce good software or a democratic paradise. It does, however, tighten the story Test Double tells a buyer. The person advising you about an expensive modernization is not only filling a utilization target for distant shareholders. That person is one of the shareholders. The company later earned Certified Evergreen status, a designation for private, purpose-led firms designed to endure rather than race toward an exit.
What the work looks like when the slogan ends
Gusto offers the cleanest example. Its large Rails application needed an upgrade, but internal experts could not abandon feature delivery to do it. Five Test Double consultants entered the codebase, mapped the constraints and upgraded incrementally. They repaired 1,700 test failures, dealt with accumulated technical debt while moving, and rolled out on time and under budget without interrupting daily operations. A rewrite would have created one dramatic project. The less cinematic answer reduced the blast radius.
For an unnamed MedTech company juggling more than 50 microservices and Azure functions, the first thing to break was visibility. Troubleshooting took days, deployment coordination consumed time, and a lean team supported 235,000 daily requests. Test Double introduced structured logging, observability practices, clearer documentation and cross-team coaching. Time to first deployment fell by half. Use of a shared logging tool increased 62 percent across 68 projects. Problems that had taken days to diagnose were reduced to minutes, and one critical project arrived two weeks early.
The pattern is diagnostic before technical. What failed first was not necessarily Ruby, Kubernetes or Azure. It was the team's ability to see the system, agree on an outcome, or make a safe change. This is also why the firm acquired Pathfinder Product in November 2023, adding more than a dozen product consultants. Test Double had built a reputation for building things right. Pathfinder supplied more capacity to ask whether the team was building the right thing.
AI changed the speed, not the responsibility
By 2026, nearly every consultancy had discovered the phrase “AI transformation.” Kaufman publicly declined the costume change. Test Double would use AI, including agentic coding, but would not rebuild its identity around selling the tool. Its revised mission became sharper: improve the impact of software on the world, one organization at a time. Its 2030 vision added a scoreboard - 1,000 client outcomes produced through people, process and technology consulting.
That wording marks a genuine change of mind. The early firm could measure success through skilled consultants placed on good teams. The wider company now says a seat is insufficient. Before accepting the request, it wants to know what problem the client faces, what business change the solution should create, and how anyone will know it worked. AI intensifies the need. If a confused organization can generate code twice as fast, it can also pave the wrong road twice as fast.
Test Double's open-source Han project turns some of its working habits into a set of coding-agent skills: research a bug, challenge a proposed fix, document architecture, plan vertical slices, implement and report. Its older Standard Ruby project makes a related argument in miniature. The formatter is deliberately unconfigurable, removing style debates so engineers can spend attention elsewhere. Both tools package judgment, but neither claims the package eliminates the judge.
The stealable playbook
Save months of payroll before hiring ahead of demand. Autonomy is fragile when next Friday's cash controls every decision.
Ask what outcome must change before pricing the requested implementation. A clear “why” prevents polished waste.
Break the system into interruptible moves. Keep revenue-producing work alive while risk and technical debt decline.
Pair, document and coach as part of delivery. The handoff is part of the product, not an appendix written on the final day.
Open-source tools such as Standard Ruby and Han make a consultancy's opinions inspectable before the first sales call.
An ESOP is complex, but the underlying lesson travels: align the upside with the people clients trust to create it.
What does it cost? Test Double publishes no rate card, and its case studies rarely disclose engagement fees. The company says plainly that it is not the cheapest. The buyer's calculation is comparative: consultant fees versus delayed releases, failed upgrades, outages, cloud waste, hiring time and the opportunity cost of assigning scarce internal experts to neglected infrastructure. In one due-diligence project, the analysis identified $60,000 to $100,000 in potential annual savings. That is evidence of a value frame, not a universal ROI promise.
The same honesty defines the conditions where the model will fail. Senior embedded consultants cannot repair a system they are forbidden to understand. Knowledge transfer goes nowhere if no internal owner has the time or authority to receive it. An outcome-led engagement becomes theater when leaders refuse to choose among priorities. And a premium consultancy is a poor match when the actual requirement is interchangeable, low-cost capacity with a tightly specified task.
Good conditions
- The system matters to revenue or operations
- Internal experts are stretched, not absent
- Leaders can name a business outcome
- The team will pair and share context
Bad conditions
- Lowest hourly rate decides the purchase
- Access to users or code is restricted
- No one can own the handoff
- Every priority is equally urgent
Where Test Double fits
The market has global consultancies that can populate a transformation program with hundreds of people, niche Rails shops with deeper focus, staff-augmentation marketplaces built for price and speed, and internal teams that need no outsider once capacity returns. Test Double sits between the specialist and the strategic firm. Its Rails credibility gets it into difficult codebases; product management, DevOps, recruiting and due diligence let it follow the problem beyond the code.
Its sharpest difference is cultural, but not soft. Remote work since 2011 widened the hiring pool. Experienced consultants reduce ramp time. Employee ownership supports a longer horizon. The stated intention to avoid client dependency makes coaching economically awkward but strategically useful. None guarantees an outcome. Together they form a coherent reason for a buyer to choose Test Double over a cheaper body shop or a larger consultancy optimized for program scale.
The Chili's origin story survives because it contains the whole company in miniature: two practitioners, an expensive problem, a refusal to spend reflexively, and a long conversation about incentives. The technology has moved from Rails to cloud infrastructure to coding agents. The useful question has stayed put: who benefits from the way the work is arranged? Test Double's answer is unusually legible - the client should get a system it can live with, and the people who did the work should own the business they improved.