Inspiration

I’m a triathlete, and I wanted a better way to look back at my races. Finish times are part of it, but I also want to see how I’ve improved, where I placed, and which performances stand out.
That’s where RaceSignal started: bringing my race history together and making sense of the results.
I also work at RevenueCat, helping app developers grow their subscription businesses. Shipaton was a chance to get back into building, put the advice we give customers into practice, and experience the same challenges firsthand.

What it does

RaceSignal helps runners and triathletes collect their results, track their progress, and prepare for their next race.

history: Find and import results from supported providers, or add a race manually.
Stats: See personal bests, age-group podiums, and placement percentiles, with filters for sport and year.
details: Review finish times, available splits, and overall and age-group placements.
Race Prep: Keep an upcoming race and its preparation checklist in one place.
Signal: Ask questions about your performance using your race history as context. You can also attach screenshots from training apps to give it more information.
Races, Stats, and Race Prep are free. Signal includes three free asks in total, and Premium includes 40 asks per month on a monthly or annual subscription.

I built RaceSignal with React Native, Expo, and TypeScript. Supabase handles authentication, the database, and backend functions. Signal uses Anthropic’s Claude API, and RevenueCat powers subscriptions.
I used Claude Code and Codex throughout development for implementation, debugging, design exploration, and testing.
I made the product decisions and tested on a physical iPhone. Feedback from other athletes helped shape the final experience.

Making race data consistent. Different events have different checkpoints and split structures. A parser that worked with sample data needed more work once I tested it with real triathlon results.
Handling incomplete imports. One unavailable result could stop an entire batch. I had to make sure valid results could still come through and failed imports could be retried.
Getting sign-in right. In one case, signing in worked, but the app wouldn’t move to the next screen until I reopened it. That was a good reminder to test the full flow, not just whether the API call succeeded.
Making Signal useful and reliable. That meant readable race times, questions that matched the athlete’s sport, clear consent before sharing data, and retries that wouldn’t count the same question twice.

Watching someone use the app for the first time helped more than another round of polishing on my own.
Athletes pointed to Stats as the most valuable screen. Seeing where they placed gave their race history more meaning.
Their feedback also helped bring back visible filter pills and a dedicated upcoming-race card.
Passing automated tests doesn’t mean the app is ready. Real accounts, real results, and people using it without instructions exposed the issues that mattered most.

I built something I wanted to use myself, with race history, stats, and race prep available without a subscription.
I’m proud of the less obvious details too: recovering from incomplete imports, giving results useful context, and keeping AI suggestions grounded in the available data.
I also spent a lot of time making the app easy to explore without needing a walkthrough.

Next, I want to get feedback from more runners and triathletes, support more race results, and make Signal’s analysis more useful as people build their race histories.

Leave feedback in the comments!

Log in or sign up for Devpost to join the conversation.