I'm building the "Kayak of running shoes": Runometry, 841 shoes, 6 languages, zero ads
I built a running shoe comparator with Claude Code and a swarm of agents: 841 shoes, 6 languages
Comparing running shoes is a mess: specs scattered everywhere, prices that move daily, and comparators that match a racing flat with a max-cushion trainer. So I built Runometry, a running shoe knowledge base with price comparison.
What surprised me is not the product. It's the speed. With Claude Code and parallel agents, a project that would have taken a small team months is live in 3 days of work, in six languages, with a catalog of 841 shoes. Here is the concept, the business model, the stack, where it stands and what comes next.
The problem
- Specs live on brand sites, review blogs and videos, each with its own vocabulary (stack, drop, weight, "super foam", carbon plate).
- The same shoe can have very different prices across retailers, and they change all the time.
- Most comparison tools compare things that should never be compared.
Result: 15 open tabs and no idea if you're overpaying.
The concept
Runometry answers two questions: which running shoe fits me, and where is it cheapest right now.
Live today at runometry.com:
- 841 shoes with structured specs (weight, drop, stack height and more) across 16 brands: ASICS, Brooks, HOKA, Nike, adidas, Saucony, On, Mizuno, New Balance, Salomon, Topo Athletic and more.
- Browse by category: daily trainers, max cushion, stability, tempo, racing, trail.
- A comparator that refuses nonsense: only genuinely comparable shoes can be matched.
- Match-up pages ("Brooks Ghost 18 vs Mizuno Wave Rider 30") generated from the catalog.
- Guides and data articles, like a count of which brands and models are behind recent running records.
- 6 languages: EN, FR, DE, ES, IT, NL.
The editorial rules: ratings are editorial, prices are checked regularly, AI-generated content is reviewed before being treated as fact, and commissions never influence ratings. At exactly equal price, a partner is listed first. That's the only advantage a partner gets.
Built with Claude Code and agents
This is the part that changed my mental model of what one person can ship.
- Claude Code as the daily driver. I describe the feature, the constraints and the conventions, the agent plans, edits across the codebase, runs the build and fixes what breaks.
- Parallel agents. While one agent builds the comparator logic, another generates page templates, another handles translations, another writes data validation. I review diffs instead of typing everything.
- Data work at scale. Normalizing hundreds of shoes, checking spec consistency, filling gaps, translating into six languages: tasks that used to be weeks of grinding become a pipeline I supervise.
- Fast iteration loops. An idea in the morning, in production by the afternoon. The cost of trying something dropped so much that I try more things.
What I still do myself, and what no agent replaces: deciding what to build, defining the data model, setting quality rules, reviewing everything that touches facts, and killing features that don't earn their place. Speed without review produces confident garbage, especially on specs and prices, which is why the review step is part of the product promise.
[Add your real numbers here: time from first commit to launch, number of agent sessions, etc. Concrete figures make this section much stronger.]
The stack
- Angular + AnalogJS for static rendering and file-based routing. I love Angular, and with signals, standalone components and the modern toolchain it has never been this pleasant.
- Spartan (spartan.ng) for UI components, shadcn-style, accessible and fully customizable. It gave me a clean, consistent design system without fighting a heavy component library.
- Tailwind for styling.
- Cloudflare for hosting the static output, with an image CDN serving WebP.
- Multilingual routing with hreflang, planned from day one.
- Claude Code for most of the implementation work.
I considered migrating to Nuxt. I didn't: staying on the stack I know best, plus agents that handle the boilerplate, beat a rewrite.
The business model
Simple on purpose:
- Affiliate commissions. Retailer links on each shoe page. I have access to the Awin network and I'm applying to brand programs directly, comparing networks on commission, payment reliability, product coverage and feed freshness.
- No display ads for now. UX and organic traffic first.
- Later: clearly labelled sponsored placements, alerts or premium data, once the base product is solid.
Someone comparing two shoes is a few clicks from buying. High intent, clean monetization.
The market
Running is big, growing and gear-obsessed. Runners rotate pairs, chase releases and talk about drop and stack like car fans talk about horsepower. Super shoes made a commodity into an enthusiast category.
Competition exists: review sites, brand sites, big retailers, generic price comparators. My angle: clean specs, honest comparisons and price intelligence in one UX, in six languages, in a market mostly served in English.
Where it stands
Early. The catalog is live, the comparator and match-up pages work, guides and data articles are out, and a backlink outreach campaign to running blogs in six languages is in progress.
- Traffic: none
- Indexed pages: WIP
- Revenue: $0
Next features
- Daily price tracking per shoe and per retailer.
- Price history charts on every shoe page, to expose fake discounts.
- Price drop radar: the biggest recent variations in one table, like flight fare changes.
- Price alerts: choose a shoe, set a target, get an email.
- More data-driven content linking to shoe pages and the comparator.
The long game: yield management for shoes
Airlines and hotels have used yield management for decades. Running shoes fit the pattern: seasonality (spring marathons, Black Friday), yearly model cycles that push the previous version down, size and color availability, and retailers repricing against each other.
With enough daily data, the goal is to tell you when to buy:
- "This model usually drops 20 to 35% a few weeks after its successor launches."
- "Today's price is in the bottom 10% of the last 12 months."
- "This retailer repriced twice in the last 10 days."
A historical price dataset is a moat: nobody can go back in time to collect it. Every day without collection is data lost, so that comes first.
What I learned
- Agents multiply a clear vision. They don't replace having one.
- Structured data is the product. Specs and naming took more care than the UI.
- Restrict comparisons. Constraints create quality.
- Multilingual from day one is cheap if planned, painful if retrofitted.
- Backlinks are the bottleneck, not content. Hence this post.
Feedback welcome
- Runners: what makes you trust a price comparison site?
- Indie hackers: experience with Awin, Rakuten or direct affiliate programs on a niche site?
- Devs: how would you build the price history pipeline cheaply (feeds, APIs, scraping)?
Try it: runometry.com. Tell me what's broken and which comparison you'd want to see.
Tim, solo founder. More updates on my profile.
Love the rule that a partner only gets listed first at exactly equal price, that's the kind of thing that makes people trust a comparison site. Small heads up: there's a leftover placeholder in the Claude Code section ("Add your real numbers here"). Would really like to see those numbers, especially how many agent sessions it took.
The moat angle is compelling, and I’d prioritize freshness and trust before breadth. For a v1 price-history pipeline, store daily snapshots per retailer/size/condition with the source timestamp plus a stale/error flag; expose “last checked” and a price-change audit so users trust the comparison. You could seed demand with a few model pages featuring 30-day charts and ask running clubs to sanity-check them, rather than waiting on broad backlink outreach.
As someone who trains a lot, the "racing flat vs max cushion trainer" mismatch is the most real problem here. Every comparison site lumps them together. The hard part will be trust in the data with prices moving daily. How often do you refresh prices, and do you show when a price was last checked? That one detail would make me trust it over a review blog.
Six languages is also six retail markets. A runner in Germany needs prices from shops that ship to Germany, in euros, and that retailer list looks nothing like the one in Spain or the Netherlands. The number I'd track per language: of the 841 shoes, how many have at least two current prices from retailers in that country. If DE is at 600 and NL at 90, the NL pages are spec sheets with an empty price box, and that tells you which market to push first and which match-up pages to hold back.
The page count is the part I'd watch, because it multiplies fast: 841 shoes, plus match-up pages for comparable pairs, times 6 languages, on a brand-new domain. Google will discover far more URLs than it decides to crawl, and a lot will sit in "Discovered, currently not indexed" for weeks.
We run UtilitySEO in 7 languages on a site at DA 3, so we see this from the inside. Every translation is another page Google has to choose to index, and hreflang only helps if every language version points back to every other one.
What I'd consider: index the match-ups only where people actually search for that pairing, and keep the rest noindexed until the domain has earned some trust. Fewer, stronger pages get crawled faster.
How many of your sitemap URLs show as indexed in Search Console so far?
Three days to build is the easy part. With 841 shoes and prices that move daily, the moat is how fresh the catalog stays and whether people trust it. What is your plan for keeping specs and prices current, and does zero ads mean affiliate revenue only?
respect the zero ads angle. i am in a similar sports niche (practice film app) and the long catalog + SEO grind feels right when paid ads would burn the wrong users. curious which language markets convert first for you.
3 days for 841 shoes in 6 languages is the right benchmark for what parallel agents actually unlock. The data collection problem is embarrassingly parallel - each shoe's specs from 3 sources don't need to wait for each other. Traditional approach is a weekend project that turns into weeks of de-duplication.
The 'zero ads' call is interesting. If it's affiliate links you're still in ads territory from a user trust perspective, just deferred to the click. The comparison tools that stay clean are usually subscription (premium filters, price alerts) or B2B API.
Question: how are you handling spec standardization? Stack height and drop are easy to parse from structured data, but 'super foam' and 'carbon plate' vary wildly in what they actually mean across brands. Is that a manual tagging layer or something you're handling with the agents?
Comparison products die when they match things that should not be compared. Calling out racing flats vs max-cushion is the actual product, not the shoe count.
We see the same failure mode in community directories: a giant list that treats every Discord server as interchangeable. Cards only work if they say who it is for before the join button.
841 shoes with zero ads is a strong constraint. Are you ranking by fit-for-use (distance, cushion, drop) first, and price second?
With zero traffic and revenue so far, what’s the first signal you’ll use to validate that runners trust Runometry enough to make a purchase decision through it?
It’s only been live for three days, so honestly there’s no user signal yet — it would be too early to draw any conclusions from traffic or conversions.
For me, the first validation is much more basic: someone searches for a shoe, finds the exact model, gets a clear comparison of where it’s available and at what price, and has a good experience. If that works reliably, that’s the foundation.
I think the features that could really differentiate Runometry over time are price history and price alerts. They give people a reason to come back even when they’re not actively looking for a new pair.
So for now, I’m mostly focused on getting that core experience right rather than trying to optimize metrics with no meaningful user base yet.
The core search-and-comparison experience is a concrete validation point, even before traffic gives you useful conversion data. If you’re open to it, what’s the best email to reach you on?
Sure, you can reach me at contact@runometry.com. Just out of curiosity, what would you like to discuss? I noticed you’ve posted quite a few comments today, so I just want to make sure this isn’t an automated or spam outreach.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.