Designing and Building Caliper

Caliper started with a question from a friend. She wondered whether there was an easier way to keep track of her car's maintenance, to learn about her car, and to have everything to do with it in one place. There wasn't one she liked. I wanted to experiment, so I opened Figma and started designing one.

Today, Caliper is a full maintenance companion: a car health view that sorts what needs you first, a twelve-month cost forecast, a logbook with receipt scanning, automatic trip tracking with tax-ready mileage exports, and seasonal tire reminders that watch the weather. But it began as a much smaller idea.

The plan was always going to hit the same wall every designer's side project hits: I can't afford a developer. This time, instead of letting the idea die in a Figma file, I decided to try building it myself with Claude Code. It changed how I work. I could design a screen, build it, and have it on a tester's phone the same week, instead of handing off a Figma file and waiting.

Designing for more than myself

The first step had nothing to do with screens. I wanted to understand the core user flow and the reason for it: who would pay for this, who would use it, and what they needed.

The risk was that I wanted this app for myself. If you design for yourself, the product slowly narrows until it fits one person. So at each decision I asked whether it served people like my friend as well as people like me.

Feature by feature, the app developed its own identity. Without a team to average out the taste, the product becomes very clearly yours, for better and worse, and you have to keep checking it still works for everyone else.

Quick Log, a single sheet for capturing mileage, fuel, bills, parking, documents, and appointments from anywhere in the app.

Learning the unglamorous parts

Shipping an iOS app involves a lot that never appears in a designer's portfolio. I became an Apple developer for the first time, which was exciting, and then met App Store Connect, which was a massive headache and a steep learning curve. I got it done, got the app into TestFlight, and brought beta testers on board.

The loop: test, learn, ship

Once testers were in, they started finding the things I couldn't see because I'd built them.

Working alone changed how fast that feedback turned into fixes. On a team, tester feedback becomes a ticket, waits for a sprint, gets handed off, and ships on the next release. Here, the gap between hearing about a problem and putting a fix in testers' hands was however long it took me to redesign and rebuild the flow. Days instead of weeks, so the flows got far more rounds of refinement than the calendar would suggest.

The biggest example is auto trip tracking, a feature that exists because of a tester. Caliper started life as a maintenance tracker. Then a beta user asked whether it could log his trips for tax purposes, and the first solution arrived while I was driving to the gym, looking at CarPlay: why not use the car's Bluetooth connection to trigger the start of a trip? So I built exactly that.

Real-world testing took about a week to kill it. The Bluetooth trigger wasn't reliable enough, and the build itself had been trying to tell me the same thing. On the first hot day of the Vancouver summer I spent two hours iterating in my parked car, laptop on my knees, and when I climbed out, my phone slid off my lap and hit the tarmac. Spiderweb of cracks. I chose to read it as an omen. After a week of testing with real users, I scrapped the Bluetooth build and rebuilt the feature around motion detection instead. It was more reliable straight away. My first clever idea had been wrong, and it took real testing to show me.

The tax-ready mileage export, born from one tester's request: pick the authority and the period, and Caliper builds the PDF.

More recently, a tester asked where to find their saved places. They were in the app, just buried. Around the same time, I went looking for the tires on my own car and couldn't find the entry point either. That made me take a step back. As I'd added features, some had ended up deeper than they should have been, so I went back to the basics of information architecture and rethought the hierarchy of the whole app.

The other half is saying no. Testers keep asking for a direct connection to their cars through Bluetooth dongles, and I think it's a great idea. It stays on the shelf anyway, because for a one-person team it's a minefield of support issues. With feedback coming in from TestFlight and in public, most of the work is telling patterns apart from one-offs, and fixing the underlying flow instead of adding another setting.

Building in public

Eventually I built up enough courage to start talking about Caliper on Threads: posting features as I shipped them, sharing the journey, showing the work in progress. People were interested. People wanted to try it.

Close to 100 testers later, that's still how the beta grows, and it's become a second source of feedback.

Where it's headed

Caliper is close to the final product, and the App Store launch is coming soon. There's a full feature tour at calipercar.com, which I also designed and built. It's the most fun I've had making anything.