Killing the license-plate OCR feature before shipping it.

The parking app has a feature that isn't in it: automatic license-plate recognition, so an attendant could point a phone camera at a vehicle instead of typing the plate number in by hand. I built it. It's not shipped. It's the kind of feature that demos beautifully and then fails exactly where it matters — a scratched or muddy plate, bad lighting under a parking structure at night, an angle the model wasn't trained on.

Why "mostly works" isn't good enough here

The app exists to track which vehicle owes what, and to generate real earnings reports off that — date-range totals, per-vehicle amounts, the numbers a lot owner actually checks against cash in hand. A plate-scan feature that's right 90% of the time doesn't save an attendant time; it adds a step where they now have to double-check the scan against the vehicle anyway, and it puts a wrong plate number into a report someone is going to treat as ground truth. A feature that undermines trust in the one thing the app is for is worse than no feature at all.

What shipped instead

Manual entry, with a fast, deliberately simple flow, plus a manual "mark as out" override an attendant can always fall back on when anything about a vehicle doesn't match what the system expects. Boring, but it doesn't lie to the person relying on it. The reporting side — the actual earnings tracked, per vehicle, per date range — is where the real product value sits, and it only works if the data going in is trustworthy.

The rule I took from it

A feature that's technically impressive but not reliable enough for the one job the app has to do isn't a feature yet — it's a research project wearing a feature's clothes. It stays out of the shipped product until it can be trusted the way manual entry can be, not because the tech isn't interesting, but because a parking lot owner's trust in the numbers is the actual product.