Supplier Portal

Venues order from multiple wholesale suppliers (the likes of Bidfood, Matthew Clark, LWC, Amazon Business), each with a different portal, different cut-off times, and no unified view of spend or order status.

Having worked inside some of the industry's busiest venues, this is a problem I've lived rather than researched secondhand.

Supplier Portal gives a venue one login and three routing strategies depending on what a given supplier actually supports: a formatted email, a direct REST API, or Playwright browser automation for suppliers with no API at all. It's deliberately scoped to ordering and supplier management, designed to plug in dedicated tools, like Bar Buddy for stock, rather than trying to do everything itself.

• Storing every supplier login somewhere that even the platform itself can't read in plain text, so a data breach couldn't expose a venue's supplier passwords.
• Handling suppliers with completely different levels of technical maturity from one system: some have a modern way to place an order automatically, some only accept a formatted email, and some need a booking made through their own website exactly as a person would, all routed correctly without the venue needing to know which is which.
• Running a proper permissions check on my own build and finding real gaps between what the system was supposed to allow and what it actually enforced, treated as something to fix, not hide.

Demo-complete isn't the same as done. Running a proper permissions audit against my own build surfaced gaps between what the data model allowed and what the API actually enforced: exactly the kind of thing that's invisible until you go looking for it.

Demo-complete: working end-to-end against realistic data (multiple suppliers, orders, products and team roles). What's left is largely operational (a couple of external integrations still to finish wiring up) rather than open product work.