Case study 01
Bizzar
A multi-vendor operating system for local markets, built end to end for the vendors least likely to ask for help.
Context
Local markets and bazaars run on single-stall weekend vendors: a coffee cart, a bakery table, a used-book stand. Almost every tool built for retail assumes the opposite: a permanent storefront, a POS terminal, a technical owner who can configure a menu system. Nothing was built for someone setting up a folding table for four hours a week.
The problem
I watched two people run a coffee cart at a 300-person mosque bazaar. They took orders by hand, wrote them on cups, and apologised to customers who had waited 20 minutes for a drink. I talked to other vendors afterward and the pattern held: the busier the stall, the further behind it fell, and the people running it had no time to look for a better way to take an order, let alone build one.
Why this and not something else
The obvious build was a shareable order form, one link per vendor. That fixes one stall for one afternoon and leaves the organiser with no view of the market as a whole, and it still assumes a vendor is willing to be the technical owner of a form.
I built for three roles instead: organiser, vendor, and customer, on one platform. That is more to design and build, but it is the actual shape of a market: someone runs the event, several people sell inside it, and the software has to reflect that or it does not fit how a bazaar works. I also made the smallest tier free. A tool the coffee cart cannot afford does not solve the problem I watched happen.
Decisions and tradeoffs
QR-based ordering, not an app: a customer scans a code at the stall and is ordering in under 30 seconds, with nothing to download and no account required to buy a coffee.
The orders board updates over Supabase Realtime, so a new ticket reaches the vendor's screen in under a second, close to as fast as someone shouting an order from the counter. That mattered more than any other feature, because the entire point was replacing the cup someone had already started writing on.
Payments run through Stripe Connect with split payouts, so money reaches each vendor's own account directly rather than pooling and requiring a manual reconciliation step later. Loyalty stamp cards and gift codes shipped, but deeper campaign and analytics tooling was deferred to keep the ordering path itself fast to build and fast to use.
Constraints
The free tier had to be genuinely usable, not a crippled trial, because the vendors who needed it most were the ones least able to pay for software before they had proof it helped. Payments had to be trustworthy from the first transaction: real KYC through Stripe Connect, not a placeholder I could soften later. And every screen had to work one-handed, on a phone, at a folding table, with a line of customers waiting.
Outcome
Bizzar is live at bizzar.app and taking real orders. A new ticket reaches a vendor's screen in under a second, payouts split automatically to each vendor's own Stripe account, and the smallest vendors pay nothing to get started.
The numbers that will matter next, vendors retained past a first event and orders processed per market, do not exist yet. I would rather say that plainly than claim traction I cannot show.
What I'd do differently
I built the three-role model, organiser, vendor, and customer, before I had proof an organiser actually wanted a dashboard of their own. It was the right structural call, but I made it on my own judgment rather than validating it with an organiser first. I also underweighted how disruptive Stripe's KYC onboarding step is in the moment, at a busy stall, with a line forming. A vendor signing up mid-event should not have to stop and produce a document.
Open to technical product management roles.