PAR-18

PAR-18 is a structured short-game performance app, closer to something like Strava or WHOOP for your wedges and putter than a scorecard. Nine stations, 10m to 80m plus a bunker shot, station par of two, challenge par of eighteen. That’s where the name comes from.

The point is purposeful practice. A fixed format and a par to beat put something on every shot, which is exactly what hitting balls at a practice green usually lacks.

Play a solo round in about 25 minutes and PAR-18 turns it into a PAR18 Rating, an Up & Down percentage, a Consistency score and a proximity-to-pin breakdown by distance, the same kind of round-over-round read Strava gives a runner. Or bring the pressure: add a mate by their PAR-18 Golf ID, play match play, and keep a running head-to-head record.

It’s the thing that used to happen in my mate’s spreadsheet, except the app is keeping score, doing the maths, and actually remembering it round to round, so you can see whether the practice is working.

One of the things I love about golf is getting out late in the afternoon with a mate, walking the course as the sun comes down, hitting some balls and having a chat.

A mate introduced me to a short-game competition, nine stations from 10m out to 80m plus a bunker shot, built to make practice actually mean something. The game was good. The way we were keeping score wasn’t. He had a spreadsheet open on his phone, tapping in numbers between shots.

I said something like, “I should build an app for that.” Then I actually did.

I researched the game and the problem, then explored the product with ChatGPT and Claude before writing anything. Claude Design helped me work out what the app should actually look like before I’d built a single real screen.

The first working version was built in FlutterFlow. It was useful because it proved I could turn the idea into something real pretty quickly. But it also got me thinking about what it would take to build the product properly in code, understand how everything fitted together and have full control over where it could go next.

So that’s what I did. I rebuilt it in TypeScript using Expo and React Native, with Supabase behind it. FlutterFlow did its job. It helped prove the idea. The next version taught me how much further I could take it.

PAR-18 is an iOS app written in TypeScript with Expo and React Native. Supabase holds the data, and the scoring runs server-side rather than inside the app itself.

People sign in with Apple or Google, subscriptions run through RevenueCat, and builds go out through Expo Application Services.

The distance between a throwaway comment and a working app has genuinely collapsed. AI helped me research the idea, argue with myself about the design, and write a large share of the actual code.

I still had to work out how the app should be structured, how data should flow, how to test it and when an AI-generated suggestion was wrong. Moving into code made those decisions much more concrete.

The result isn’t that understanding software matters less. It’s that one person who understands it can now take on a lot more of the journey themselves.