Building RaceTwin: Lessons in Forward-Deployed Engineering

I've been building RaceTwin, a small app that generates training routes matched to the terrain of a specific goal race. Somewhere in the middle of building it, I began to see a connection between the work I was doing and forward-deployed engineering.

My background is in analytics. This isn't an account of holding a forward-deployed engineer role, and building an independent app isn't the same as deploying software inside a customer's organization. It is an account of the product, engineering, and design decisions that made the connection meaningful to me.

The connection to forward-deployed engineering

Palantir describes forward-deployed engineering as getting engineers close to the problem and feeding what they learn back into the product. That proximity is the part that resonates with me.

On RaceTwin, I wasn't starting with a complete specification. I had to move between deciding what was worth building, how to build it, and what it should feel like to use. At this stage, those weren't separate jobs done by separate people. They were one continuous judgment call, made over and over, usually with incomplete information.

Product decisions: knowing what the app is actually for

My background is in analytics, not product management. But a lot of the real work on RaceTwin has been product judgment: what should this app actually do, and for whom?

The idea started from a specific observation: an endurance athlete with a small analyst team using past competitors' GPS data to prepare for a race in a way most runners never get access to. But "make that accessible" isn't a product yet.

Getting from there to something buildable meant a lot of narrowing. I decided the app should focus on long runs and race-specific training rather than trying to be a general fitness tracker. I had to decide which races to support first based on where demand and usable data existed. And I had to accept that a feature idea, however clever, wasn't worth building just because I had a good argument for why someone might need it.

Most of that narrowing didn't come from a plan. It came from noticing when an assumption I was building on turned out to be wrong, and being willing to change direction rather than defend the original idea.

Engineering decisions: deciding what not to build

The instinct, early on, was to build everything myself, including recording a run's GPS data directly in the app. That ran into reliability problems fast.

The better engineering question wasn't only how to fix the tracker. It was whether I needed one at all, given that many of the runners I had in mind already owned a GPS watch they trusted.

That question changed the architecture I wanted to pursue: generate a route, hand it off to a compatible device or running platform, and use permitted integrations to bring completed-run data back where available. The details still depend on device support, API access, and testing. The important decision was to separate route preparation from run recording rather than assume RaceTwin had to own both.

That is the engineering judgment this project has demanded. Not simply "can I build this?" but "should I, given what already exists and what the runner actually needs?"

UI and UX decisions: following the real constraint

Some of the most important interface decisions came from checking assumptions against reality instead of trusting the original design.

I'd planned for a route to display on a runner's watch. Then I checked my own watch and found it couldn't display a map. That was a real, physical constraint I hadn't accounted for.

The next step wasn't to force the original plan. It was to study how existing running apps handle the split between a phone and a watch. That pointed me toward a lightweight, phone-based way to view a route when the runner's watch can't show it, rather than treating watch-based maps as universal.

A separate issue surfaced while testing my own generated routes. Some passed through streets that didn't match my local understanding of where I would feel comfortable running. A technically valid route isn't automatically a route someone will trust.

That moved route review ahead of new features. It also made the limits clear: I can't promise that a generated route is safe. Local knowledge, road conditions, crossings, and a runner's own judgment matter. A bad first experience can end someone's relationship with an app before it has had a chance to prove useful.

Research: not building around a guess

When I didn't know whether a shared route library or per-user route generation would scale better, I started researching how established mapping and activity products handle coverage and repeated computation.

The useful question was not "how do I cover everywhere?" It was "what needs to be computed again, what can be reused, and where do I have enough reliable coverage to serve someone well?"

That shaped the direction for RaceTwin: start with useful coverage where runners can actually test the product, then expand deliberately as demand appears elsewhere. A shared library and caching are design options to evaluate, not proof that the scaling problem is solved.

None of that came from expertise I already had. It came from being willing to stop, research an unfamiliar area, and let what I found change the plan instead of proceeding on a guess because research felt like a detour from building.

What I'm still learning

I don't have this fully figured out. A friend training for Boston told me directly that he trains differently, and that terrain-matched routes aren't how he thinks about race preparation.

That's real feedback. I'm treating it as real rather than explaining it away. A working app is not the same as a validated need, and one runner's response is not a verdict on every runner either. It is a reason to ask better questions about who this is for.

What I do know is how to make the next decision more honestly: check assumptions before building around them, look at how others have solved the same constraint, separate a promising idea from a validated one, and do the research when the answer isn't obvious.

That combination of product judgment, engineering judgment, design judgment, and willingness to learn is what building RaceTwin has asked of me so far. It is also why forward-deployed engineering interests me: the responsibility reaches beyond implementing a feature to understanding whether it helps in the situation where it will actually be used.

Explore RaceTwin or see more of my work.