Tiendas
One online store core and a CLI that turns it into a new client store, now running Rodar MDQ and BiciTienda MDQ.
Small shops in Mar del Plata kept asking for the same thing: a catalog, a cart, a checkout, orders and an admin they can run themselves. The first one, 3:23, was a frontend on mock data. Building each new store from scratch would cost weeks, and copying the last one by hand would carry the last client's brand, copy and photos into the next.
Three decisions that shaped it.
- 01
The template is generated from a live store
Why. Rodar MDQ is the reference store. The CLI exports its last commit with git archive, strips Rodar's photos, copy and Cloudinary URLs, lays a placeholder brand called Faro on top, and checks that every migration and db script arrived intact. The starter is never edited by hand, so it can't drift from code that runs in production.
Trade-off. A core fix has to land in Rodar first. A few Rodar leftovers in core files are swapped out by a list of string replacements, which only warns when a string goes missing.
- 02
Copy the core, don't share a package
Why. new-store copies the starter into its own git repo, with its own Neon database and Vercel project. Brand words, routes and modules live in config and a lexicon, so BiciTienda could add sizes and colors, appointments and customer accounts without touching Rodar.
Trade-off. A fix doesn't reach stores that already exist. Each one gets it by cherry-picking the commit by hand.
- 03
Every integration has a local stand-in
Why. Without env vars the store uses PGlite instead of Neon, writes emails to a local outbox, pays through a sandbox page and opens the admin with a dev PIN. A new store runs with migrate, seed and dev, and I can show it to a client before anyone creates an account anywhere.
Trade-off. Two code paths per integration. The sandbox payment page had to be locked out in production, and PGlite can hide a difference from Neon until deploy.
Tiendas
One online store core and a CLI that turns it into a new client store, now running Rodar MDQ and BiciTienda MDQ.
- Role
- Architecture and full build
- Stack
- Next.js 16, TypeScript, Tailwind 4, Drizzle, Neon Postgres / PGlite, React Email, Go
Small shops in Mar del Plata kept asking for the same thing: a catalog, a cart, a checkout, orders and an admin they can run themselves. The first one, 3:23, was a frontend on mock data. Building each new store from scratch would cost weeks, and copying the last one by hand would carry the last client's brand, copy and photos into the next.
Three decisions that shaped it.
The template is generated from a live store
Why. Rodar MDQ is the reference store. The CLI exports its last commit with git archive, strips Rodar's photos, copy and Cloudinary URLs, lays a placeholder brand called Faro on top, and checks that every migration and db script arrived intact. The starter is never edited by hand, so it can't drift from code that runs in production.
Trade-off. A core fix has to land in Rodar first. A few Rodar leftovers in core files are swapped out by a list of string replacements, which only warns when a string goes missing.
Copy the core, don't share a package
Why. new-store copies the starter into its own git repo, with its own Neon database and Vercel project. Brand words, routes and modules live in config and a lexicon, so BiciTienda could add sizes and colors, appointments and customer accounts without touching Rodar.
Trade-off. A fix doesn't reach stores that already exist. Each one gets it by cherry-picking the commit by hand.
Every integration has a local stand-in
Why. Without env vars the store uses PGlite instead of Neon, writes emails to a local outbox, pays through a sandbox page and opens the admin with a dev PIN. A new store runs with migrate, seed and dev, and I can show it to a client before anyone creates an account anywhere.
Trade-off. Two code paths per integration. The sandbox payment page had to be locked out in production, and PGlite can hide a difference from Neon until deploy.