RunTools

Developer & Designer | 2025–Present

Tools: Next.js, TypeScript, Tailwind CSS v4, Framer Motion, Vitest, Playwright, Capacitor Platform: Web, iOS, Android · runtools.app · github.com/harvzheng/run-tools

Overview

RunTools is a browser-based collection of running calculators and utilities I built for myself — and for any runner who's tired of Googling a different tool every time they need a quick answer mid-training.

The Problem

As I got deeper into running, I found myself reaching for tools constantly: pace converters before a workout, race predictors when planning a training block, weather adjustments before heading out in summer heat. The tools existed online, but the experience of finding and using them was frustrating.

Most running calculators I found had one or more of these issues:

• Scattered across different sites — no single place had everything, so I'd Google each tool every time
• Desktop-first layouts — I'm usually checking these on my phone, already outside or about to head out
• Bloated with ads and sign-up walls — I just want a quick answer, not an account
• Inconsistent UX — every site works differently, and few match how I actually think about the inputs

I wanted something fast, focused, and always in my pocket.

Exploration

My first instinct was to find an existing app that solved this, but nothing quite fit. Running apps like Strava and Garmin Connect are great for logging, but their built-in calculators are limited or buried. Standalone calculator sites had the right functions but bad UX.

I realized the gap wasn't in the math — the calculations are straightforward. The gap was in how the tools were packaged and accessed. I wanted a single, lightweight hub where every tool felt consistent and was designed for mobile-first use.

Since I could use AI tools to build and iterate quickly, I decided to build my own.

Key Design Decisions

Client-Side Everything

Every calculation runs in the browser — no server roundtrips, no accounts, no analytics. This was a deliberate choice to eliminate hosting costs entirely and keep the app fast. It also means the tools work offline once loaded, which matters when you're checking something at a trailhead with spotty signal.

The only exception is the weather-based tools, which fetch local conditions via a weather API using your device location.

Metric and Imperial Flexibility

Running is a sport where the US uses miles and most of the world uses kilometers — and many runners think in both depending on context. I made unit toggling a first-class feature so you can seamlessly switch between metric and imperial without re-entering values.

Recently Used Tools

With a growing collection of calculators, I didn't want the home screen to become a wall of options. I added a "Recently Used" section that surfaces the tools you reach for most often at the top. It's a small thing, but it means the app gets faster the more you use it.

Modular Architecture

I didn't know upfront exactly which tools I'd want — the suite grew organically from my own training needs. So I designed the codebase to make adding a new tool as easy as possible: each calculator is a self-contained module with its own inputs, logic, and UI. Adding a new tool doesn't require touching shared code.

This modularity paid off quickly. For example, after a run in high heat, I realized I wanted a heat-adjusted pace calculator that factored in temperature and dew point — not just temperature alone, which is what most existing tools use. I was able to describe my mental model for how the calculator should work to an AI coding assistant and have a working version integrated within minutes.

AI-Assisted Development

The modular architecture was my design decision from the start — I knew the tool suite would grow organically, so I structured the codebase so each calculator is a self-contained module that can be added without touching shared code. That architectural choice is what makes the rapid iteration possible.

I'm dogfooding RunTools as a UX designer who also runs. Every time I use a tool during training, I'm evaluating the experience: Is the input order intuitive? Does the result display make sense at a glance on my phone while I'm stretching? Are there gaps — things I wished I had mid-run that don't exist yet? This ongoing use surfaces real UX issues that I then fix or build out.

AI accelerates the implementation of ideas I've already validated through use. When I identify a gap or a UX problem, I describe what I want to a coding agent and iterate until the experience matches my expectations. The key distinction: the domain decisions are mine, AI makes them real faster.

A concrete example: after a run in high heat, I realized I needed a heat-adjusted pace calculator. Most existing tools only factor in temperature, but as a runner I knew that dew point is actually the more important variable — high dew point means your sweat can't evaporate, which tanks performance even at moderate temperatures. That domain insight came from my running experience. I described the mental model for how the calculator should work, including the dew point weighting, and had a working version integrated within minutes.

This workflow means the app evolves directly from real training experiences rather than hypothetical feature lists. I'm both the developer and the primary test user, so the feedback loop is immediate: use the tool, notice a problem, fix it, run again.

CI/CD and Deployment

The project has a full CI pipeline via GitHub Actions that runs on every push and pull request: linting, type-checking, Vitest unit tests, a production build, and Playwright end-to-end tests — all in sequence so nothing ships if an earlier step fails.

For web deployment, Vercel handles production deploys automatically on push to main. For mobile, I use Capacitor to package the Next.js static export into a native iOS app. A one-shot prep script checks prerequisites, builds the static site, syncs to Capacitor, and sets up the Xcode project — from there I archive and distribute via TestFlight.

I also integrated a Claude Code GitHub Action so I can mention @claude on issues or PRs and get AI-assisted code changes directly in the repo, which fits the rapid iteration workflow.

Current Tools

The suite includes pace converters, race time predictors, heart rate zone calculators, split calculators, heat-adjusted pace calculations, and more — with new tools added as training needs arise.

Outcomes

• Built a tool I use multiple times a week during my own training
• Zero ongoing server costs — everything runs client-side
• Packaged for iOS and Android via Capacitor for native app distribution
• Modular architecture allows new tools to be added and shipped in minutes