Situation
Australia’s hospitality beverage trade runs on manual relationships. A venue ordering craft beer, wine and spirits deals with each supplier separately — phone, email, order form, rep visit — then reconciles invoices against deliveries by hand across every supplier.
Suppliers face the mirror image of that problem. A craft brewery, winery or distillery selling into hospitality typically reaches venues one relationship at a time — a rep visiting or calling each account, quoting and taking orders individually. That limits how many venues a supplier can realistically reach beyond their existing rep network.
BevEx is a B2B marketplace built to replace that: venues order across multiple breweries, wineries and distilleries in one basket, at wholesale pricing, with fulfilment handled through an established third-party logistics partner. I ran this project alone using AI agents connected directly to the production database, the delivery board and the codebase.
Task
I needed to take a three-sided marketplace (venues, suppliers, fulfilment partner) with real payments, real logistics integration and real tax obligations to a live pilot, on my own, while:
- Keeping the specification, the delivery tracking and the running system consistent with each other, without a separate team to keep them in sync
- Resolving commercial and legal ambiguities — who is the seller of record, how stock availability is determined, when an account is allowed to transact — early enough that they didn’t surface as late-stage rework
- Giving AI agents safe, governed access to production infrastructure without that becoming a reliability or security risk
- Replacing the checks a design reviewer and QA analyst would normally provide with guardrails that hold up without anyone in the loop
Action
Resolved commercial ambiguity before building screens. Several questions had to be answered before any interface work could start, because the answers determined the data model — not the layout:
- Who is the seller of record? I decided the supplier is the seller, not the marketplace — BevEx facilitates and takes a commission but never takes title to goods. That decision determined how invoicing, payouts and buyer-facing copy all had to work, so I built the commission calculation as one shared function consumed by the invoice generator, the payment splitter and all three dashboards, rather than as separate logic in each place. When the commission rate changed later, it updated everywhere in one change.
- What counts as available stock? Inventory sits across two warehouses and is partly held back by suppliers commercially, with the third-party logistics system as the source of truth on a sync cycle. I enforced sellable quantity server-side at cart and checkout, derived per warehouse, rather than leaving it as a front-end check.
- When can an account transact? I gated account activation on liquor licence data at the database level, so it’s a rule the system can’t bypass rather than a form validation someone could skip.
Kept the spec, the board and the code from drifting apart. I maintained a single 1,152-line development plan (versioned to v2.44) that ships in the same commit as the code it describes, with every feature marked DONE, PARTIAL or NOT STARTED and PARTIAL items naming the specific gap remaining. I connected a Trello board directly into my working sessions so cards moved as part of delivery, not as a separate reporting step afterward. This meant the plan, the board and the running system stayed accurate to each other without me maintaining them three times.
Set up governed AI access to production. I gave agents access to the production database, staging database and delivery board through MCP servers, with an always-applied rule: schema changes go through one sanctioned migration path, a security check runs after every change, and a matching migration file gets committed each time. If a sanctioned tool looked unavailable, the rule was to stop and ask rather than improvise a workaround. I deliberately left one integration disconnected because its authentication flow risked disrupting the deployment pipeline.
Built the design system directly in code. There are no design files in the repository. I applied the brand by remapping colour tokens in the stylesheet so existing components picked up the brand without individually editing each one — the same approach let me ship dark mode as a token-layer change rather than a component-by-component pass. This meant no gap between what was designed and what shipped, though it’s a trade-off — it works because I can hold both design and engineering myself, and it forfeits the fast, disposable exploration a proper design tool gives you.
Replaced manual review with structural assurance. With no reviewer and no QA function, I relied on: row-level security policies for access control (doing the job a permissions matrix would in a conventional handoff), CI running lint/type-check/build on every push, scheduled dependency audits, a staging environment on its own database and domain in front of every production promotion, and error tracking, checkout funnel monitoring and uptime monitoring in production. I did not build an automated test suite — that risk is currently covered by static typing across the codebase, database-level constraints, staging, and monitoring. That’s a known gap and the clear next thing to fix before a team joins the codebase.
Result
Live production platform with a matching staging environment: three role-based experiences (buyer, supplier, administrator) each with dashboards, catalogue/product management, orders and reporting. Multi-supplier cart and checkout with split payouts, supplier-issued tax invoices generated automatically on payment, discount codes scoped by product and buyer, full-text catalogue search, bulk product import/export, and a searchable help centre. Genuine two-way integration with the logistics partner — suppliers, products and per-warehouse stock sync inbound, paid orders push outbound, availability scoped per buyer to their assigned warehouse.
By the numbers: 40 pages, 43 API endpoints, 58 components, 20 database tables across 48 migrations, ~32,000 lines of application code, 124 commits over five and a half months, 95 delivered board cards against 8 remaining in the backlog. One contributor, agent-assisted throughout.
Delivered conventionally, this scope would typically need a product manager, a designer, two or three engineers and a QA function over two to three quarters. I delivered it solo because the specification, delivery tracking and codebase never separated into artefacts that needed reconciling with each other — the usual overhead of keeping a team aligned wasn’t there to begin with.
What this demonstrates: most of the hard problems on this project weren’t visual — they were judgment calls (who’s the seller, what’s available, when can someone transact) that needed to be made precisely enough for a system to execute without further interpretation. That’s design and product thinking applied directly to a live codebase, without the usual handoff layers, and it’s the model I’d bring to a team: fewer artefacts, faster decisions, and the same rigour applied earlier in the process rather than caught in review.