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. That decision opened a whole new world. Suddenly I could design and build the actual app, iterate and test with immediate feedback, and do it all myself. After years of handing designs over and hoping, it was a breath of fresh air.

Designing for more than myself

The design was a step-by-step process, and the first step had nothing to do with screens. I wanted to understand the core user flow and the why behind it: who the customer would be, not just the user, and what they actually needed.

I had to be honest about a trap here. I wanted this app for myself, and "I am the user" is comfortable thinking that quietly narrows a product until it fits exactly one person. So I kept the wider user base in mind at every decision, asking whether a choice served people like my friend, not just people like me.

Feature by feature, the app started to develop its own identity and its own feeling. That's the part of solo building nobody tells you about: 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's still for everyone else.

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, Caliper stopped being my app and started being theirs, which is exactly the point of a beta. Real usage punctures assumptions quickly. Flows that felt obvious to the person who designed and built them were not obvious to people meeting them cold, and that gap between designer and user is the most useful thing a beta can show you.

The solo setup changed what iteration meant in practice. On a team, a piece of tester feedback becomes a ticket, waits for a sprint, gets handed off, and ships on the next release train. Here, the distance between hearing about a problem and putting the fix in testers' hands was however long it took me to redesign the flow and rebuild it. The cycle compressed from weeks to days, which meant the flows got far more rounds of refinement than the calendar would suggest.

The clearest 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 instantly more reliable, and the lesson was an old one worth relearning: the first clever idea is a hypothesis, not a decision, and testing is how you find out which.

The other half of the discipline is saying no. Testers keep asking for a direct connection to their cars through Bluetooth dongles, and I think it's a great idea. I've spent a lot of time thinking about it, and it stays on the shelf anyway, because for a one-person team it's a minefield of support issues. With feedback arriving from TestFlight and in public, the job isn't collecting requests. It's separating patterns from one-offs, fixing the underlying flow instead of bolting on another setting, and protecting the identity the app has developed. Doing it alone just removes anywhere to hide from the decision.

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 the channel the beta grows through, and it has quietly become a second feedback loop. Designing in public keeps you honest the same way designing for a friend does.

Where it's headed

Caliper is getting closer and closer 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 is, honestly, the most fun I've had making anything: the full distance from a friend's passing question to an app on real people's phones, with every screen, decision, and line of Swift along the way mine.