This blog is based on a conversation Test Double Co-Founder & CEO Todd Kaufman had with Traingent Co-Founder & CEO Rikky Singh, and the video is an excerpt from the same.
Rapid prototyping is great, but you also have to prepare for scale
A client reaches out with a prototype. It works and feels impressive and solves an interesting problem. And now they're asking us to make it stable and scalable because they're about to take their first credit card payment.
We see this all the time.
There's nothing wrong with the prototype, but you also have to prepare for real users and scale. The cost of getting to a working prototype has dropped so far that the bottleneck has moved somewhere else entirely.
If you want to get to a durable product for sustainable growth, you have to recognize that getting to a prototype in and of itself does not solve everything. Even if you can now do it more quickly. You need to make sure you’re building the right thing in the first place. If you don’t it can bite you later on when the bet was wrong because you didn’t validate with users early enough.
Most of the industry is still operating on the old assumptions.
Rikky Singh, Co-Founder & CEO of Traingent, spent a chunk of his career inside that loop at Accenture, working with Fortune 100 enterprise software customers. He described the common pattern directly:
"The typical traditional approach would have been writing a PRD that then got translated to a TRD that then went into sprint planning. And then a few days or weeks later, out comes this thing that you put in front of the user and the user goes—that's not what I was talking about. That's actually, you guys completely missed my point."
Agile was supposed to fix this, and for some teams it did. For a lot of teams it didn't, because they adopted the ceremonies without adopting the mindset underneath.
I'm a little embarrassed to admit I did plenty of Agile consulting back in the day. And the most common failure mode I watched up close was scrummerfall: daily standups, two-week sprints, retros, all of it, but the team still treated the whole thing like a giant Gantt chart. They knew exactly what they should be building on day one, and the sprints were just an organizing device for the sequencing.
That pattern is what can AI makes unaffordable even though it feels cheap. If you already know exactly what you should build, you can now build it in a weekend. That’s great. But if you don't truly know what you should build (and most teams don') you are about to generate a lot of wrong code, fast.
Taste is what's left when outputs are free
Rikky mentioned a quote in our conversation that struck a chord:
"Taste is the only remaining moat."
He doesn't know who to attribute it to. Neither do I. But the observation is right. You can take a screenshot of a competitor's app and feed it to Claude or Codex and get back a credible replica. You can describe a product in a paragraph and get a working prototype. The production of software is no longer where the defensibility lives. The defensibility is upstream, in the judgment about what's worth building. And downstream, in the ability to ship it in a way that actually holds up.
It goes back to the adage of building the right thing, in addition to building the thing right.
Ride with Dave, the product Rikky and his team at Traingent built with our support, is a good example of what that looks like in practice. Cycling is already a crowded space. Strava alone has north of 180 million users. We didn’t start with how do we build another cycling app. Instead they examined where does the existing market leave something on the table, and what would it look like to go deep there.
Rikky framed the choice this way:
"Strava started off as primarily a cycling and running app as a way to share those activities with the network. But very quickly it became a Facebook of all sporting. And it became a mile wide and an inch deep. We actually have the inverse perspective with Dave. General vertical products are going to be an inch wide and a mile deep. They're going to know one thing very specifically well."
This is iwhere vertical AI products win: not by being horizontal replacements for existing platforms, but by being deeply, unreasonably competent inside a narrow domain where a general-purpose tool can't go. Getting that right requires taste. It requires knowing the domain well enough to know what matters, and what doesn't, and what the existing players are ignoring.
That's not a problem you can solve with better models or more tokens. And you can’t just vibe code prototype your way there.
Backlogs become history books
"We ship so fast that tickets become history books and not planning tools."
– Rikky Singh
If you're shipping in hours what used to take days, and in days what used to take weeks, then the backlog you wrote on Monday is stale by Thursday. Not because anyone did anything wrong, but because the ground moved. The question is no longer "what did we plan to do this week?" It's "what did we learn by shipping something on Tuesday, and how does that change what we should do on Wednesday?"
That's a different operating model than most companies run on. Most product teams still build from a backlog that was written a quarter ago, prioritized a month ago, and refined a week ago. By the time a feature reaches engineering, it has already survived three rounds of planning theater and nobody wants to throw it out. So it gets built, whether or not it's still the right thing.
Traingent didn't operate that way on Ride with Dave. Their planning process, as best I could describe it from the outside, was something like: here's the core capability we think we need this week, let's see what it tells us, and then next week's plan is whatever that result suggests. Not a backlog—a direction of travel with reversible decisions stacked along it.
Rikky's described to me how that maps to his own work style:
"My co-founder and I actually still did write down user stories and epics in that very first gate. But we quickly found as we got going that there were so many interdependencies, and as you start to build non-deterministic software, that backlog goes out the window. So we started by turning that backlog into sort of core functionalities that were needed in layers of the pyramid."
Core functionalities in layers, compared to what we’re used to in development of tickets and sprints with burndown charts. Instead it’s chunks of capability that unlock other chunks of capability, built in a sequence that keeps the thing learnable.
This is not a rejection of planning, but the unit of planning has changed. Fine-grained ticket planning made sense when the cost of building was high enough that you needed to budget it carefully. When the cost of building drops below the cost of planning the build, you have to plan differently. You plan experiences, not tickets. You plan reversible decisions, not roadmaps.
The prototype-to-production bridge, built both ways
Something that surprised me about the Traingent engagement, and that I've started seeing in other AI-native product work, is how much of the product design now happens inside the prototyping environment itself. Rikky isn't writing specs and handing them to engineers. He's prototyping features in AI Studio, getting working code out the other end, and handing that code to Wayne Marley and the Traingent engineering team to industrialize into the production architecture.
Again, this is different than what most software engineering teams are used to. A lot of the iterative development has been able to be pulled forward into prototyping. But you have to be intentional about how to make that work in later stages.
On the engineering side, that only works because the harness is there to absorb it. Wayne Marley described the connection from the other direction in a separate conversation with our Principal Consultant David Mosher:
"Using AI tools like Google AI Studio for prototyping, and then having that environment integrated with our GitHub environment—that code is also visible through our IDEs, through GitHub. So it allows less technical people like Rikky to go through and design completely new features on their own. And then when they're at a point of maturity, that code base is available to our coding agents, and we can begin to plan the industrialization of that code."
The prototype and the production system are not two separate worlds anymore. They're two ends of the same pipe. In order to be ready for launching to paying customers and then scaling, you have to bring all of what used to be later conversations forward to the rapid prototyping stage. That changes how a product CEO and a CTO need to work together. It also changes what "partnership" between a client and a consultancy actually has to look like, which I think is also worth sharing.
What partnership looks like when the ground is moving
A lot of the client conversations I used to have were time-and-materials conversations. How many hours will your consultants spend on my project per week, how many weeks, what's the total. Fair enough—that's how the industry priced itself for a long time, and for a lot of engagements it's still the right structure.
That model is not holding up as well in AI product work.
The scope of what's possible keeps expanding. The clarity about what the MVP actually is keeps wobbling. The cost of building dropped, but the cost of building the wrong thing rose. In that environment, a fixed bag of hours against a fixed backlog isn't quite the right container for the work. And it’s not helpful to the client. What ends up mattering more is whether the incentives are aligned.
Rikky shared with me something that I've thought about a lot:
"Partners need to start with, are those incentives aligned? And be selective about the partnerships you invest in. Because if you want to do them well, you can't have a Rolodex of partners. There should be a handful that serve a very critical purpose, and where there's a shared understanding of what success looks like on both sides."
From the Test Double side, we went into the Traingent engagement knowing it wasn't going to be a standard 12-month embedded consulting arrangement. Traingent is a small team on a tight budget shipping a novel product. The goal wasn't to extend our presence. We are most successful when our clients no longer need us, because we set them up to run on their own, with the right architecture and harness in place, and to be available when they needed deeper expertise.
That shifted how we staffed it. Instead of assigning one or two consultants for a block of time, we rotated in the right subject matter expert at the right phase—Dave Mosher for architecture, Jed Schneider for scaffolding depth, specialists when they were useful. Traingent wasn't paying for a team to keep warm. They were paying for the specific expertise that matched the problem they were on that week.
Rikky said this best:
"As a founder, I live the mantra of ‘firm beliefs loosely held.’ We have conviction in how we believe the product should work,, but you should use first principles thinking and your judgment from deliveries like this across a number of clients to say, hey, we get where you're trying to go. Maybe consider this approach instead."
Firm beliefs, loosely held. That's a good description of what partnership in this kind of work has to be. You come in with a strong point of view. You listen for the cases where the point of view needs to change. You debate in the open, because trust and aligned incentives make that safe. And you ship something together that neither side would have shipped alone.
What I'd want a leader to take from this
The old planning machinery doesn't survive contact with AI product work. Waterfalls don't. Scrummerfall doesn't. Even well-run Agile, applied to a backlog that can't keep up with what the team is learning, doesn't. The unit of planning has to shift upstream—to the shape of the experience, the layers of capability, the reversible decisions—and you have to be willing to let tickets become history books.
The partnerships that work in this environment are the ones where both sides are honest about incentives up front. I'd rather have a client tell me they need to run on their own in six months than have them tell me they need us indefinitely and find out later it wasn't true. The shape of the engagement changes when you start there. So does the trust.
The next few years are going to sort out who is building durable AI product companies and who is shipping margin-negative experiments. Rikky and I both suspect the ones who stay standing will be the ones who took taste seriously, who stayed close to their users, and who chose their partners the same way. We'll see. I'd be curious what you're seeing too.
Todd Kaufman is the CEO of Test Double, a 100% employee-owned software consulting company that has been remote since 2011. Test Double helps organizations solve complex technical challenges through people, process, and technology consulting.
Rikky Singh is Co-Founder & CEO at Traingent, and he is building the next interface for AI. Traingent builds intelligent assistants with purpose, personality, and persistence, and they are in private preview for Ride with Dave.
