QRmo

Think of the corner bodega, the family taqueria, the boba shop two doors down. That business scans in and gets a real storefront rather than a list of links: categories, products, prices, themes, a contact card. It is reached by QR code, which is how these owners actually hand out a URL. Printed on a banner, taped to the register, stuck in the window.

The surface is larger than that description suggests. There is the storefront builder itself, a link-in-bio layer with its own design controls for colour, type, buttons, header and wallpaper, and a set of operator tools covering a weekly events planner, reviews and feedback, and marketing and preloader overlays. Analytics, billing, staff and usage sit alongside them. It runs as an Nx monorepo: four applications over three shared libraries, on Supabase for data, Clerk for auth and Sanity for editorial.

The metric was never builder capability. It was time-to-first-publish. A shop owner does not want to design a page, they want a page, and every axis of freedom is another decision standing between them and being live.

So I timed the real flow instead of guessing at it, step by step: onboarding three to five minutes across six questions, store creation one to two, adding products five to ten by hand, customising two to three, publishing thirty seconds. Eleven to twenty minutes, and the largest single block was manual product entry, the part I had spent the least design effort on.

That reframed the roadmap. The fix was not a better canvas. It was spreadsheet import with intelligent column mapping, categories derived from the data, defaults good enough to skip, auto-save in place of a save button, and one-click publish straight to a QR code. Target: three to four minutes.

The general lesson I took: I had been optimising the part of the flow I found interesting rather than the part that was costing users the most time. Timing the flow is cheap and I should have done it first.

The positioning question was whether QRmo is one page per business or one page per location. Link-in-bio tools assume a single page, which quietly fails the businesses most worth having: the ones with three branches.

So a workspace publishes a hub that lists its stores, and each store keeps its own QR storefront underneath. One directory, n storefronts. A single-location shop never sees the hub and loses nothing; a three-branch operator gets a structure the single-page tools cannot express.

It is also the reason workspace sits above store in the data model rather than being bolted on later. Multi-tenancy is very hard to retrofit and fairly cheap to assume from the start.

Test coverage is thin, and I would rather say so than let the repository imply otherwise: five specs and four end-to-end files against roughly three hundred source files. The pricing, entitlement and publish paths are exactly the kind of logic that fails silently, and they are not covered.

Every other project in this portfolio makes the same argument: pull business rules into dependency-free modules so testing them costs nothing. This is the project where I did not follow it. The builder grew fast, the rules stayed embedded in components, and the tests never got written.