This blog is based on a conversation Test Double Senior Software Consultant Jed Schneider had with Traingent Software Engineer Amaury Silverio, and the video is an excerpt from the same.
Everyone building on AI is starting to sound the same
Spend a week reading AI product announcements and the pattern becomes hard to miss. New tooling, same foundation models. Agents, workflows, memory: the currency of every modern agentic system. The marketing copy is generic enough that you start to suspect an LLM wrote it.
Differentiation is getting thinner, and anyone who's lived through a platform shift recognizes where this usually goes. Technology arrives, everyone reaches for the same new capability, and the winners turn out to be the teams who understood something about their specific domain that the platforms couldn't see. The teams who thought the new technology was the edge typically weren't around a few years later.
That's the frame I brought into my work with Traingent, the small team building Ride with Dave, a cycling-focused AI assistant. The frame got reinforced faster than I expected once I started looking at what they'd already discovered before I showed up.
What the platforms normalized away
Cycling is a crowded market at the app level. Strava, Training Peaks, Garmin Connect, a dozen others. Most ride data originates in the same exchange format: the .fit file that devices like Garmin head units produce to record a ride. You'd think the space was fully explored.
It isn't, and the reason is in the file format itself.
The FIT protocol (invented by Garmin) is self-describing. Each file contains not just the data, but also the schema for the messages inside it. That means every file from every user can carry different information based on which devices were connected and what activity was completed. If your head unit paired with a Bluetooth chest strap that captures respiratory rate, that's in the file. If you ride electronic shifting (and the shifting data shows up on your head unit), every gear change is in there. If your heart rate monitor records HRV, you've got that too. A single file can carry dozens of unique message types alongside the common ones like speed, distance, and location.
The variance is massive. Two riders can produce files with completely different signal sets depending on what bike they rode and what they had connected that day.
Traditional platforms do what platforms have to do: normalize. They find the common denominator across all their users and build features on top of that intersection. Speed. Heart rate. Power, if it's available. GPS and elevation. Anything else gets flattened or ignored because it's too fragmented to build a UI around.
The normalization is what creates the opening.
An AI-native product can take the opposite approach. Rather than asking "what signals does everyone have?", it can ask "what signals does this rider have, and what can we learn from them?" The agent notices that respiratory rate is in the file, decides whether it's relevant to the question being asked, and surfaces insights that no dashboard could have anticipated. A chat interface accommodates variance that a graph can't, because the system doesn't have to commit to one visualization for everyone.
The product takes a different shape than what the incumbents built. It only becomes possible because two things happen at once: AI collapses the cost of per-individual reasoning, and someone on the team knows enough about cycling to spot what the platforms had been leaving on the table.
Domain knowledge as a debugging tool
When Dave Mosher first mentioned he was working on something involving fit files, I recognized the format immediately. I've been in and around cycling software for a long time. I applied for a Garmin SDK membership about a decade ago, back when it was a $10,000/yr program, so I had opinions about what was in those files, how they were structured, and what you could reasonably expect to find inside them. Even with that background, I was surprised by some of the relationships and correlations Rikky and Wayne pulled out of their early prototypes.
That kind of familiarity turns out to be useful in ways that are hard to anticipate until you're deep in the work.
When we'd get output from an AI prototype parsing a ride file, I could tell at a glance whether the numbers were plausible. A velocity of 40 in a certain context is almost certainly not miles per hour; that's very fast on a bike, outside of a descent. Probably kilometers per hour. Possibly meters per second, depending on where in the pipeline the conversion was happening. If the AI returned 40 mph for a recreational ride on flat ground, I knew something had gone sideways before I even looked at the code.
That's domain expertise functioning as a debugger. Not a formal one, just an intuition that says "that number doesn't belong in that range" fast enough to catch a problem before it compounds. It's what an experienced woodworker does when a cut doesn't look quite right, or what a nurse does when a patient's vitals are technically fine but something feels off. The knowledge isn't only factual; it's a feel for what's probable.
Amaury, one of the core engineers doing a lot of the hands-on work, described how having people on the team with that kind of feel changed the pace of iteration:
"It helps us iterate quickly, maybe more quickly than if I, for example, wasn't familiar with the cycling world. It helps me look at data differently. It helps me figure out what these raw data files that we often work with through Garmin and Oura actually contain."
A lot of teams underrate this. Domain expertise doesn't only help you ship the right features. It helps you notice when the software is lying to you, at a speed that regression tests and monitoring dashboards can't match.
Building for one person, not for a hundred million
The work Rikky Singh and Wayne Marley had already done before Test Double was even in the conversation made me confident there was something of value to bring to market. A lot of that confidence came from their willingness to bet on per-individual reasoning rather than per-cohort dashboards.
From a traditional platform perspective, you can't really build for individuals. You design for the set of signals everyone has, because that's what supports a coherent UI. You can't ship a visualization that only appears for riders who happen to have electronic shifting and a respiratory rate signal on that particular day. You'd end up with an interface that changed arbitrarily, which nobody wants to ship.
AI as the computation layer flips that constraint. Instead of designing a UI for the normalized subset, you design a conversational interface that can reason over whatever signals happen to be present. The agent looks at what's there, decides what's relevant to the question being asked, and surfaces insights specific to a rider at a specific point in time.
"Best" changes meaning under that model. A traditional cycling platform tries to be best for the average user, and ends up with something like "Great job out there! You really pushed the pace today on your 13.2 mile ride." It sounds generic because the major platforms have already thrown most of the interesting data away by the time the response gets built. A product like Dave is trying to be best for you, with the raw source data, given what you asked. The shape of the product follows from the shape of the compute.
That's where Rikky's "inch wide, mile deep" framing for Traingent becomes concrete. Going deep isn't only about narrowing your market. It's about committing to a quality of response that only makes sense if you're reasoning about one person at a time, which only became economically feasible because of what AI changed about the cost structure.
Domain shapes the architecture, not just the features
One of the early decisions on Ride with Dave was whether to use RAG (retrieval-augmented generation) as the memory and recall layer. This was last summer (2025), when RAG was the default answer to almost any memory question in agent development. Even when well-intentioned, group-think bleeds into technical decisions on any specific product.
Pushing back on RAG as the primary data retrieval mechanism became a vital trust-building moment for both teams. It was a hard set of conversations to have, and to win the technology direction back from the loudest voices on the internet. I pushed back because RAG didn't fit the data retrieval problem we had, not because RAG is wrong.
RAG works well when you have semantic relationships between the things you're storing (documents, conversations, source code) and you want to find similar items by meaning. The corpus also needs to be large enough that it doesn't fit in the model's context window, or large enough that paying for that many tokens isn't viable. It works great for a coding agent that needs to find similar Python functions in a codebase, because the semantic structure of code maps reasonably well to vector embeddings.
Cycling data is different. When you're dealing with GPS points, speed samples, and cadence readings, there's no semantic relationship between one number and another. They're just numbers. Embedding them as vectors and traversing them semantically is the wrong shape of solution. A traditional database with a good query engine does the job better, faster, and more predictably.
The principle I ended up articulating to the team: never ask the LLM to add things up. Ask the LLM to write you a function to add things up. Let the compute layer do the math, deterministically. Let the language model do the language, which is what it's for.
That architectural call only makes sense if you understand both the domain (cycling data is numeric, not semantic) and the capability boundary of the tools you're using. Language models are unreliable at arithmetic at scale. Neither half of that decision could have been made from the outside. It took someone with enough cycling background to know what the data actually looked like, and enough AI architecture experience to know when the default pattern was a mismatch.
Whose lived experience counts as expertise
There's a question underneath all of this that doesn't get asked often enough. When we talk about domain expertise as a defensible moat in AI, who do we mean?
The implicit answer in most product conversations is the obvious one: the expert who's been in the field for twenty years, the industry insider, the person with the credentials. That answer isn't wrong, but it is incomplete.
On the Traingent team, cycling expertise isn't one thing. Rikky and Wayne are lifelong competitive cyclists. I raced for over a decade, including some national championships in road, mountain, and cyclocross. Amaury rides too, but his relationship with cycling is different. He's more urban than competitive, more fixed-gear than road race. He sees the sport from an angle the rest of us don't naturally occupy.
That variance turns out to be useful. The postcards feature in Ride with Dave (where riders can turn a ride into a shareable image with Dave overlaid on it) benefited from Amaury seeing cycling as culture and expression, not only as training data. A product built entirely by competitive cyclists might not have prioritized a feature like that. A product built entirely by casual riders might have missed the depth in the training data. The team has both, and the product is better for it.
Domain expertise in vertical AI isn't only about being the deepest expert. It's about having enough different kinds of lived experience in the room that you can see the domain from multiple angles. The moat is made of people, and specifically, people who bring different things to the work.
That's harder to hire for than "find me a cycling expert." It requires building a team deliberately, with an eye for the combinations and not only the credentials. It's also where the durable advantages in this era are going to come from.
What this means for how you build
The moat question in AI isn't really about the technology. It's about who's on your team and what they bring to the work. If your differentiation lives entirely in your prompts or your model selection, a competitor will match it within a quarter. If it lives in the combination of lived experiences informing what you build and how you build it, that's much harder to copy.
Domain expertise in the AI era isn't only about knowing your users. It's about letting that knowledge shape your architecture, your data pipelines, your debugging intuition, your sense of what's worth surfacing. The expertise doesn't stop at the product layer; it goes all the way down.
None of that is about finding the single expert who knows everything. Expertise is distributed. Different kinds of lived experience count. The teams who take that seriously are the ones who'll still be here in five years, building things the platforms couldn't see, for people the platforms couldn't serve.
Jed Schneider is a Senior Software Consultant at Test Double, with experience in product development, data engineering, observability, and agentic systems.
Amaury Silverio is a Software Engineer at Traingent and an urban cyclist. They are building intelligent assistants with purpose, personality, and persistence.
