MileMinder started with a specific frustration: PCP and lease drivers are expected to stay inside an agreed mileage allowance, but most people only find out they have a problem when it is already expensive.
If you are 4,000 miles over your contract at handback, that is not a vague administrative inconvenience. It is usually a bill. The underlying maths is simple: start date, end date, allowance, current reading, and excess mileage rate. What is missing is a tool that keeps that relationship visible without asking people to maintain a spreadsheet.
That was the gap I wanted MileMinder to fill. Not a generic vehicle tracker. Not fleet management software. A focused answer to a practical question: am I on track?
The Problem
PCP and lease mileage is easy to ignore because it does not hurt every day. The risk compounds quietly.
You might know your annual allowance, but that does not mean you know whether today’s odometer reading is good or bad. A reading of 18,000 miles is fine for one agreement and a problem for another. It depends on how far through the contract you are, how many miles you started with, and how much headroom remains.
Most drivers handle this in one of three ways:
- They do the maths occasionally in a spreadsheet.
- They guess and hope it balances out.
- They wait until the finance company tells them at handback.
None of those are good product experiences. They demand too much effort or provide the answer too late. MileMinder is built around the opposite assumption: the useful answer should always be current and obvious.
The Solution
In plain terms, MileMinder tracks where you are against your mileage allowance.
You add your vehicle, contract dates, allowance, starting mileage, odometer readings, and excess mileage rate. MileMinder turns that into a live view of your position: whether you are under or over the expected pace, how much allowance remains, and what your likely excess charge could become if your driving pattern does not change.
It also supports reminders and alerts, because the point is not just recording mileage. The point is making the future bill visible early enough that you can still act.
That focus matters. A lot of software becomes hard to use because it starts with a broad category: “car management”, “personal finance”, “tracking”. MileMinder starts with a sharper job: help a PCP or lease driver avoid being surprised by excess mileage charges.
How It Is Built
MileMinder is a Go backend with a SvelteKit frontend, deployed as a single production service.
The backend is written in Go 1.25. Go is not the most convenient language for quickly sketching web products, but it is very good at building reliable services that are simple to deploy and operate. I care more about predictable behaviour than framework magic.
The frontend is SvelteKit 2 with Svelte 4, TypeScript, Vite, Tailwind CSS, Chart.js, and date-fns. It is built as a static app and served by the Go binary rather than running as a separate Node service in production.
The calculation logic lives on the backend, so the server remains the source of truth for mileage and allowance calculations. The frontend presents the product; it is not where the important business rules live.
Storage is intentionally simple. MileMinder currently stores data as flat YAML files rather than using a database. In the hosted product, each user has their own server-side data directory, with Fly.io persistent storage mounted at /data.
That is a product-stage decision. A database will make sense if and when usage needs it. Until then, flat structured files are easy to inspect, easy to back up, and remove a whole class of operational complexity.
Authentication is handled server-side. MileMinder has accounts, login, bcrypt password hashing, opaque server-side sessions, protected routes, and rate limiting on auth endpoints. That is table-stakes product work, but it is also the difference between a demo and something I am comfortable putting in front of users.
Email is sent through Resend over SMTP from mail.mileminders.com, with SPF, DKIM, and DMARC configured. That detail matters. Password reset links, mileage alerts, reading reminders, and owner signup notifications only work as product features if the emails actually land.
Deployment runs on Fly.io. Production lives at mileminders.com, with TLS handled by Fly at the edge. There is also a separate staging app at staging.mileminders.com, protected behind HTTP Basic Auth.
CI/CD runs through GitHub Actions. Pull requests run Go build, vet, and tests, plus frontend checks and builds. Pushes to main deploy production; pushes to staging deploy staging.
That might sound like overkill for a small product, but it is the line I want even on solo work. If something is live and users can rely on it, it deserves production discipline.
What Is Next
MileMinder is live in production, not a prototype sitting on localhost.
The current work is about watching usage, tightening the product around workflows people actually repeat, and improving the points where setup or reminder behaviour can be clearer. The useful feedback now is whether a driver can arrive, understand the product quickly, add their agreement details, and trust the numbers enough to keep using it.
That is the part of building products I care about most: getting past the attractive diagram and into the uncomfortable detail of whether the thing works for someone who did not build it.
MileMinder is also a useful proof point for how I think about software. I enjoy architecture, but architecture only matters when it helps something ship, stay healthy, and serve a real user. This is the maker half of “Engineering Lead & Maker” made concrete: product, infrastructure, operations, delivery, and go-to-market joined up in one working system.
Try MileMinder at mileminders.com, especially if you have a PCP or lease car and want to know where your mileage is heading before handback.