Nobody puts “point-of-sale system” on a vision board. It’s not the kind of project you brag about at a dinner party the way you’d brag about shipping an AI product. And yet The Manor Restaurant’s management platform — full-stack, e-commerce, payment integration, the whole operational stack a real restaurant actually runs on — turned out to be one of the most technically demanding builds I’ve shipped.
Here’s why: a restaurant doesn’t get to have a bad night because your software had a bad night.
Where the real complexity lives
Inventory has to reconcile against orders in near real-time, or a kitchen ends up promising a dish it can’t make. Payment integration has to handle a chaotic mix of cards, transfers, and the occasional “network is down, let me call you back” moment without losing track of what was actually paid. And all of this has to run on hardware and connectivity that a fintech app in a controlled office environment never has to worry about — a tablet at a host stand, a spotty router, a dinner rush that doesn’t pause for a retry loop.
The design principle that saved the project
Assume the network will fail mid-transaction, because it will, on a Friday night, during the rush. Every payment flow was built with idempotent retries and a local-first order state that reconciles once connectivity returns, rather than a naive “call the API and hope” approach. Boring architecture. Absolutely load-bearing.
What building “unsexy” software taught me
The projects that look the most mundane from the outside are often the ones where sloppy engineering hurts real people the fastest — a server not getting paid correctly, a kitchen making the wrong dish, a customer double-charged during a busy Saturday night. I’ve come to actually prefer this kind of work. There’s nowhere to hide behind a clever abstraction. It either works when it’s busy, or it doesn’t, and everyone finds out immediately.