Apps

Two apps, built from blank files.

Product work is the third lane. Par-5 is live on the App Store and Why Not Run is heading there, both built the same way as everything else here — no framework underneath doing the thinking.

Par-5 app icon

Par-5

Every golf course in America, in your pocket.

The directory that maps 12,464 US courses by state and town, wrapped as a native app. Find what is near you, check a scorecard, and save the ones worth the detour.

  • Course search by state, town, or what is closest
  • Handicap, course handicap, score differential and Stableford calculators
  • Built on open data, with nothing invented to fill a page
Why Not Run app icon

Why Not Run

The indie running coach for iPhone.

Adaptive training plans from 5K to ultra that rewrite themselves as you train, calibrated to your own fitness rather than a fixed template off a chart.

  • Plans that recalibrate against what you actually ran
  • VDOT-based pace zones and a real coach voice
  • Apple Watch through Apple Health, with training data kept on the device
Coming soon to the App Store Read the case study whynot.run

Par-5 is live. Why Not Run is heading there. A card carries Apple's download badge only once there is a real listing behind it, because the badge may only be used unaltered and pointed at a live App Store page. Until an app has one, a line of type is the honest version.

Why a web studio ships apps

Because the interesting problems do not respect the boundary. Par-5 started as a directory of every golf course in America — 12,464 of them, mapped by state and town from open data, on static pages with nothing computed while a visitor waits. Once that corpus existed, the phone was the obvious place for it, so the same product got wrapped natively.

Why Not Run came the other way. The app existed first: adaptive training plans that rewrite themselves against what you actually ran, rather than a fixed template off a chart. The job was a product site that could explain that engine to a runner in under a minute without turning into documentation.

Both are the same lane as the client work, which is the point. Something that fits no category, built from a blank file, and still custom the whole way down.

How an app gets built here

Neither of these started as an app project, and that shapes how they are built.

Par-5 is a static site first. The directory is flat files generated ahead of time, with nothing computed while somebody waits, and the native app wraps that same product rather than reimplementing it. One corpus, one set of rules about what a page is allowed to claim, two places to read it. When the data improves, both improve, because there is only one of them.

Why Not Run runs the other way around. The training engine is the product and the plans are computed on the device, so the app carries real logic rather than being a shell around a website. The marketing site is a separate static build whose only job is to explain that engine well enough that a runner starts a trial.

Both ship to iPhone first. That is a resourcing decision rather than a philosophical one: one person shipping to one platform properly beats two platforms shipped badly, and Apple's review process is the harder of the two to satisfy. Android is a roadmap item for Why Not Run rather than a promise with a date on it.

Status, stated plainly

Par-5 is approved and downloadable now. Why Not Run is heading the same way. The card at the top of this page reads its status from a data file, so an app going live is a change to two fields there rather than a rewrite of the page.

The download badge appears only where there is a real listing behind it. Apple's badge artwork may only be used unaltered and pointed at a live App Store page, so Why Not Run keeps a line of type until it has one. A greyed-out or decorative badge would be a guidelines violation rather than a placeholder.

Twenty free minutes. Bring your worst website.

Or no website at all. A free 20-minute consult, a straight answer, and zero pressure either way.