Next.js marketplace
A two-sided marketplace for venue-based brand discovery
Wellocated needed a marketplace, not a storefront: two sides to onboard, a booking product that is not a cart, and a purchase that begins in a physical venue rather than on a product page. We delivered it end to end, from product strategy and UX through engineering and deployment.
Book a callWhat made this hard
A conventional ecommerce build has one seller, one catalogue and one path to checkout. A marketplace has none of those. Venues have to be onboarded, verified and given tools to manage what appears in their space. Brands have to find those venues, book placement in them, and see what the booking returned. The platform sits between the two and has to stay credible to both, which is mostly a question of whether each side can see the state of things without having to ask someone.
The second complication is that the commerce does not happen on the platform. Someone encounters a brand in a venue and buys it there. Everything the software does upstream is in service of a moment that happens in a room, and at that moment the software’s job is to get out of the way.
What we built
- Venue onboarding and management, with the operational tooling to run it at scale
- Brand placement booking, the two-sided transaction the marketplace exists for
- Marketplace operations: the administration and reporting both sides depend on
- QR-to-checkout purchasing, turning in-venue discovery into an immediate sale
- Product strategy and UX, before any of the above was built
- Deployment and the infrastructure it runs on
Why the path from scan to paid had to be short
QR-to-checkout is easy to describe and unforgiving to build. The person scanning has already decided they are interested, so every second and every tap after that is attrition. They are standing in a venue rather than sitting at a desk, they may be on a poor connection, and they will not create an account first.
So the constraint drives the architecture rather than the other way round: render fast on a mid-range phone, ask for the minimum, and put nothing between the scan and the payment sheet that is not strictly required. It is the same argument the rest of this site makes about speed, in the one setting where nobody argues with it.
How the engagement ran
Strategy
We started on the product rather than the stack: who the two sides are, what each needs to see, and which parts of the model were still open questions. Marketplaces fail on the model far more often than on the code.
Design
UX for both sides, which in a two-sided product means two distinct applications that happen to share a domain. What a venue needs to see and what a brand needs to see overlap much less than people expect.
Build
Next.js across the front, with the booking and operations systems behind it, built in increments against a deployed environment rather than a demo branch.
Deploy
Deployment and the operational side of running it, so what was handed over was a working system rather than a repository.
What this page does not include
No performance figures, revenue numbers or venue counts, because none have been cleared for publication. We would rather this page describe accurately what was built than carry numbers we cannot stand behind. If you are evaluating us and want specifics, ask on a call and we will tell you what we are permitted to.
What this project shows
Custom & Headless Development Beyond the Platform
Next.js storefronts, custom commerce platforms, technical SEO and AI integration for teams the theme layer no longer fits.
Tell us what your store needs to do.
Send a short note about the platform you're on and what's in the way. You'll get a reply from an engineer, usually within one business day, not a sales sequence.