BuffrHQ

Commercial route-optimization APIs charge per request, and that cost scales badly against a price a solo operator will pay.

So the owner's dashboard has an Optimize Route button: a nearest-neighbor heuristic over haversine distance, computed locally and anchored to the earliest scheduled job. The planner at the top of my home page is the same algorithm. Jobs missing coordinates go to the end of the list instead of quietly disappearing from it. On the phone, where detailers actually are, the day simply follows the schedule.

The drawn route calls a free public routing service for a road-following polyline, with a straight-line fallback if it is slow or unreachable, so the map degrades to useful rather than to blank. Turn-by-turn navigation is handed off to Apple Maps or Google Maps. I have no business trying to out-navigate them, and no detailer wants me to.

In hindsight it is the one feature I would cut entirely (more on that below).

Chose

Nearest-neighbor ordering on the owner's dashboard, behind an Optimize Route button; navigation handed to the maps app they already use.

Rejected

A paid optimization API, and building turn-by-turn navigation in-app.

The cost

The tour is not optimal, and at three or four jobs a day there is little to optimize. On the phone, stops simply follow the schedule.

Detailers rarely remember names. They always recognize the car. Matching the lookup key to how the user actually thinks was the highest-leverage product decision in the app: point the camera at a plate and the returning client comes up.

Recognition itself is a solved problem sold as an API, and it is not where my advantage lives. The app captures a frame and hands it to my backend, which calls a commercial ALPR service. The token never ships to the client. In the bundle, anyone can pull it out of the IPA and spend my quota.

The engineering that mattered was everything around the call. A confidence threshold, below which the app shows what it read and asks the user to confirm instead of silently searching for the wrong plate. A manual entry path that is always visible, never a fallback you have to discover. Recognition fails in rain, at angles and on novelty plates, and a feature that only works in good conditions is one people stop trusting. And a region selector, because plate strings are only unique within an issuing state and two clients can genuinely share one.

The interesting part of integrating an ML service is rarely the call. It is deciding what to do when it is unsure.

Chose

Buy recognition, proxy it server-side, and design the interface around the failure case.

Rejected

On-device OCR, and shipping the vendor token inside the app.

The cost

A network round trip, a per-scan cost, and a hard dependency on somebody else's uptime.

The obvious move is to integrate a card processor and take a cut of every job. I chose not to. Onboarding a solo operator into a payments platform means underwriting, KYC, payout delays, chargeback exposure and a compliance surface I would be carrying alone.

Detailers already get paid through Cash App, Venmo, PayPal and Zelle. So the invoice generates a QR pay page with whichever of those the business has configured, the customer pays through a channel they already trust, and the detailer marks it settled. Tips are chosen by the customer at pay time rather than pre-set by the detailer, which converts better and is less awkward for both of them.

It is a smaller-looking feature that removed an entire category of risk from a one-person company.

Chose

Four payment handles behind a generated QR pay page.

Rejected

Card processing, and revenue from a take rate.

The cost

No payment revenue, and settlement stays a manual step. Reconciliation is the detailer's job.

Access is gated on two independent axes: what your role allows, and what your subscription tier includes. A feature has to clear both.

That is over-engineering for launch, and it was, right up until the first team account, at which point retrofitting it would have meant auditing every screen in the app.

What made it survivable in production was a deliberate fail-safe: if the permission set cannot be loaded, a small set of account-essential screens stay reachable. An empty permission set rendering a dead app is a much worse failure than briefly showing someone a button they cannot use.

Chose

Two-axis permissions in the first release, with a fail-safe floor.

Rejected

Ship single-user, add roles when a team asks for them.

The cost

Weeks of work before a single team existed, and a check on every screen to keep correct.