Building software inside a motorcycle dealership taught me this
The unexpected lessons from developing a production system while sitting inside the business it serves.
Building production software while sitting inside the business that uses it changes everything about how you build.
When a salesperson couldn't find a feature, they'd walk over to my desk. When a PDF layout showed the wrong field position, I'd see the printed copy on their desk the same day. When the internet went down (common in semi-urban Sri Lanka), I'd hear about it immediately.
This feedback loop is brutally effective. It's also uncomfortable — there's nowhere to hide behind a ticket queue or a sprint board. The software either works for the person using it, or they tell you to your face.
Things we got right because of this proximity: the bill editing flow with automatic inventory reconciliation, the encrypted PII storage that didn't slow down search, and the bilingual PDFs that warranty managers actually preferred over the previous paper forms.
Things we got wrong the first time: the dashboard metrics (too many numbers, not enough context), the user permission model (too rigid for a small team where roles overlap), and the mobile layout (most staff accessed the system from their phones despite having desktops).
The takeaway: if you can build software inside the business it serves, do it. The product will be better, and you'll learn things no requirements document could tell you.