OurCar: What I Learned Building a Custom App for My Family

A few months ago, I built a small app called OurCar. It is not on the App Store. It will never be on the App Store. Its entire user base consists of four people who share a surname and a driveway in suburban Australia. And yet, building it taught me more about software, family logistics, and the limits of consumer apps than any product I have shipped professionally.

This is a piece about why building tiny, purpose-built tools for the people you live with is one of the most underrated uses of programming skill — and what I learned doing it.

Why I built it in the first place

Our household runs on one car shared between three drivers. The chaos is predictable: who has it tonight, when is the rego due, has anyone topped up the windscreen wash, did Mum remember the service was booked for Thursday, and — the eternal question — who left the tank on empty?

We tried the usual things. A shared calendar. A WhatsApp group. A whiteboard on the fridge. None of them stuck, because each one solved a slice of the problem and ignored the rest. The calendar handled bookings but not the running list of small maintenance tasks. WhatsApp surfaced messages then buried them. The whiteboard worked beautifully until somebody wiped it.

What pushed me over the edge was, of all things, a CNBC piece on getting out of a car loan in 2026. We were considering refinancing, and I realised we had no shared, agreed source of truth on what the car cost us each month — fuel, insurance, the loan, services. The information existed, but it was scattered across four phones and two banks. A car is one of the largest financial commitments most Australian households make, and we were managing it with vibes.

So I spent a weekend building OurCar.

Lesson 1: The constraint of "just us" changes everything

When you build for strangers, you spend most of your time on edge cases. Onboarding flows. Password recovery. Dark patterns to keep retention up. Accessibility for users you will never meet. Privacy policies. App Store screenshots.

When you build for your own family, all of that vanishes. There is no signup. The four user accounts are hardcoded. "Authentication" is a PIN on the home screen because we trust each other and the app lives on our home Wi-Fi. The interface is in the dialect of our household — the car is called "Trev" because my sister named it after Trevor Chappell, and the app calls it Trev too.

That sounds trivial, but it is the single biggest lesson. Software written for a known, finite audience can be radically simpler than software written for the public. Whole categories of complexity disappear. You can ship in a weekend what would take a startup six months, because you are not solving for everyone — you are solving for Mum, Dad, my sister and me.

Lesson 2: Off-the-shelf apps optimise for the wrong thing

Before building OurCar, I tried to find an existing app that did what we needed. I went down some genuinely strange rabbit holes. There is a whole ecosystem of car-adjacent software, including the kind of bizarre Apple CarPlay apps BGR has rounded up — meditation tools, weirdly specific weather apps, things you never knew you wanted. The market is enormous.

And almost none of it is built for households. It is built for individual drivers, or for fleets. There is no middle tier — no good "three people sharing a Hyundai i30" software — because that audience is too small to monetise and too specific to genericise.

This is a pattern I now see everywhere. Take language learning, an area where consumer apps are more polished than just about anywhere else. Both PCMag's 2026 roundup of language learning apps and The New York Times' guide reach the same conclusion from different angles: the "best" app depends on the learner. There is no universally correct choice. Duolingo gamifies. Pimsleur drills audio. Babbel structures grammar. Each one optimises for a particular kind of user.

Family software is the same, only worse, because every family is its own dialect. The optimal app for our household is one that knows Trev, knows Mum hates push notifications, knows Thursday is bin night which means the car needs to be off the kerb. No commercial app is ever going to know that.

Lesson 3: The interesting features are the boring ones

OurCar's killer feature is not clever. It is a single screen showing: who has the car right now, who has it next, the current odometer reading, and the next three things that need doing (service, rego, tyre rotation). Tap any of them to mark done or reassign.

That's it. The fancy stuff I planned — fuel cost analytics, a maintenance graph, integration with our bank — I either cut or never built. Nobody used them in testing, where "testing" meant my sister rolling her eyes at the kitchen table.

The feature that actually changed our lives was the most boring one: a shared, authoritative answer to "who has the car tonight?" That is the entire job. Everything else is decoration.

The lesson here is one professional product teams know but constantly forget: the value is almost never in the feature you are most excited to build. It is in the unglamorous, central thing the people in front of you actually need.

Lesson 4: Build for the person who hates apps

My mother is the most important user of OurCar, and she does not enjoy apps. If the home screen takes more than a second to load, or asks her to sign in again, or shows her a notification she didn't ask for, she will stop using it within a week.

Designing for her forced a discipline I rarely apply at work. No popups. No "rate this app". No streaks, badges or other gamification borrowed from the Duolingo school of engagement-farming. The app opens, shows the answer, and gets out of the way.

If you are building something for your family, assume your hardest user is the one who has the least patience for software. Design for them, and everyone else benefits.

Lesson 5: It does not have to last forever

OurCar might be obsolete in two years. We might sell Trev. My sister might move out. The app might break when I update my phone and I might not bother fixing it.

That is fine. Family software is allowed to be temporary. It does not need a five-year roadmap or a sustainable business model. It needs to solve a problem for the people you love, right now, for as long as the problem exists. That is a freedom professional software almost never has, and it is liberating.

The case for the household app

If you can write code, even badly, I would gently push you to build something small for the people you live with. A chore tracker. A shared shopping list with categories that match your actual supermarket. A weekly meal planner that knows your kids will not eat capsicum.

You will write worse code than you do at work. You will skip tests. You will hardcode your sister's name. And the people using it will, in small daily ways, have a slightly better life because of it.

OurCar is four screens, runs on a Raspberry Pi in the hallway cupboard, and will never make a cent. It is also the most-used piece of software I have ever written.

Related on Bleen

Sources