A restaurant website with ordering that you RENT has a hidden expiry date. GloriaFood's is public: end of service April 30, 2027 - it says so on their own homepage, and there is no replacement product for their customers. Ten thousand restaurants are learning the word "migration" the hard way.

The alternative is boring, and that's the point: the website you own + ordering that runs on it. Three architectures people actually buy:

Aggregator-only (DoorDash/Uber Eats links): $0 build, 15-30% per order, and the customer belongs to them, not you. Great for strangers; brutal for regulars.

Rented ordering SaaS: a monthly fee plus per-module creep, someone else's domain in the guest's browser history, and an exit date you don't control.

Owned build: your domain, your site, your QR ordering embedded - a guest scans at the table, orders on their phone with allergen flags and modifiers, the kitchen sees it instantly. The platform beneath can be yours or mine; the relationship with the guest is yours either way.

I build exactly this lane from both sides: hand-coded restaurant websites (as part of the $799 tier or above), and the ordering engine itself - Platepoint is my own production SaaS: QR table ordering, kitchen display, allergen labels printed on tickets, per-venue branding on each client's domain. So the website and the ordering stop being two vendors pointing at each other when something breaks.

Honest boundary, stated in writing: your payments and invoices stay in your POS and billing stack; ordering stops at the kitchen ticket. That's not a limitation, it's why leaving is just peeling a sticker.