CarFinder

A phone app that remembers where you parked.

Android MVP complete; production version in development planning

A hand holds a phone in a grassy park; the CarFinder guidance screen shows the car 119 feet away, and a parked car is visible in the distance.
Field test: walking back across a park toward the car, with the app showing 119 ft to go.

Why I built it

A few years ago, I wanted to build a car finder for forgetful people, like my 85-year-old mother, who still drove just fine but sometimes couldn't remember where she'd parked.

The basic idea seemed simple: detect when you're driving, recognize when you've parked, save the location, and guide you back to it later.

As it turned out, the problem was more complicated than that. The phone has to distinguish parking from ordinary stops, determine when a location is reliable enough to save, and guide you back using GPS and compass data that aren't always precise.

I initially tried building the application in .NET MAUI. Eventually, I abandoned that attempt.

When I began retooling my skills for AI-assisted development, I found a new reason to revisit the project: GitHub Spec-Kit offered a way to develop the application through a structured, specification-driven process. CarFinder became an ideal project for putting that approach to the test.

What it does

CarFinder is designed to remember where you parked and help you find your way back.

It monitors the phone's location and movement in the background. When it determines that you've parked, it records the location. Later, when you want to find your car, the app displays the direction and distance to the saved location.

The guidance interface is designed to account for uncertainty in the location and compass readings, rather than assuming the phone always knows exactly where the car is.

The CarFinder screen showing the word Driving.
Driving. The phone is at driving speed, so the app is watching for you to slow down.
The CarFinder screen reading: Sensing you will be parking soon.
Sensing you will be parking soon. You've slowed to parking speed. The app samples location more often and waits for confirmation that you've actually parked.
A narrow cone pointing from a person icon toward a car icon, labeled 119 ft.
Guidance, far away. The cone points from you toward the car, with the distance in the middle. Here the car is 119 ft away.
A wider cone pointing from a person icon toward a car icon, labeled 63 ft.
Guidance, getting closer. The same view as you walk. At 63 ft the cone is wider and the distance has counted down.
The CarFinder screen reading: You have arrived.
You have arrived. You're at the parked location.
A dialog asking: Do you see your car? with No and Yes buttons.
Do you see your car? Shown over the arrival screen. Yes and No both simply dismiss it.

How I built it

I used GitHub Spec-Kit and a Spec-Driven Development (SDD) process to build the Android MVP in Kotlin. I wrote no code myself; the implementation was produced through the AI-assisted development process.

I ran multiple rounds of analysis and refinement, partly to improve the application and partly to investigate what the process could reveal about software quality and technical debt.

It found real problems. For example, the analysis identified a background service that was supposed to increase GPS sampling as the phone approached a likely parking event but did not actually do so.

That was an important result. The process wasn't just generating code; it was helping identify discrepancies between what the application was supposed to do and what the implementation actually did.

What I learned

The experience taught me as much about the development process as it did about the application.

  • Structured analysis can expose implementation defects. Repeated analysis identified problems that weren't obvious from the intended design alone.
  • Human oversight needs context. AI agents can produce commands, results, and authorization requests faster than a person can evaluate their implications. I used a separate Claude Cowork conversation as an engineering overseer to help explain decisions and assess their consequences.
  • Requirements traceability needs to extend into implementation. Connecting tasks to a specification is not enough if code fixes can drift away from the intended behavior.
  • Complex requirements need structure. As systems grow, a flat representation of requirements becomes increasingly inadequate for preserving relationships across multiple levels of decomposition.

These observations led to my next project, SDD Agent, an effort to extend Spec-Driven Development with stronger requirements traceability, hierarchical validation, and oversight of changes that might affect application intent.

CarFinder Production: what's next

The MVP is a starting point, not the finished product.

The planned production version will expand the application beyond its initial parking-detection and guidance capabilities. Areas under consideration include smarter parking detection, parking history, map-based displays, and additional location-finding capabilities.

The longer-term vision also includes a companion smartwatch application that can help locate a paired phone.

The production requirements are being developed as part of my ongoing work on SDD Agent. This creates an opportunity to apply the lessons from the MVP to the next development cycle.

Project links

View the CarFinder MVP source code on GitHub →