Tiendas
Un core de tienda online y un CLI que lo convierte en la tienda de un cliente nuevo. Hoy corre Rodar MDQ y BiciTienda MDQ.
Los comercios de Mar del Plata pedían siempre lo mismo: catálogo, carrito, checkout, pedidos y un panel que puedan manejar solos. La primera, 3:23, era un frontend con datos de prueba. Armar cada tienda desde cero llevaba semanas, y copiar la anterior a mano arrastraba la marca, los textos y las fotos del cliente anterior.
Tres decisiones que lo definieron.
- 01
La plantilla se genera desde una tienda real
Por qué. Rodar MDQ es la tienda de referencia. El CLI exporta su último commit con git archive, saca las fotos, los textos y las URLs de Cloudinary de Rodar, pone encima una marca de relleno llamada Faro y verifica que lleguen todas las migraciones y los scripts de base. El starter nunca se edita a mano, así que no se aleja del código que corre en producción.
El costo. Un arreglo del core tiene que entrar primero en Rodar. Algunos restos de Rodar en archivos del core se reemplazan con una lista de textos, que sólo avisa cuando un texto ya no está.
- 02
Copiar el core, no compartir un paquete
Por qué. new-store copia el starter en un repo propio, con su base en Neon y su proyecto en Vercel. Las palabras del rubro, las rutas y los módulos viven en la config y en un léxico, así BiciTienda pudo sumar talles y colores, turnos y cuentas de cliente sin tocar Rodar.
El costo. Un arreglo no llega solo a las tiendas que ya existen. Cada una lo recibe con un cherry-pick a mano.
- 03
Cada integración tiene un reemplazo local
Por qué. Sin variables de entorno, la tienda usa PGlite en vez de Neon, escribe los mails en una bandeja local, paga con una página de prueba y abre el panel con un PIN de desarrollo. Una tienda nueva corre con migrate, seed y dev, y se la puedo mostrar al cliente antes de que nadie cree una cuenta en ningún lado.
El costo. Dos caminos de código por integración. La página de pago de prueba tuvo que quedar bloqueada en producción, y PGlite puede esconder una diferencia con Neon hasta el deploy.
Tiendas
Un core de tienda online y un CLI que lo convierte en la tienda de un cliente nuevo. Hoy corre Rodar MDQ y BiciTienda MDQ.
- Rol
- Arquitectura y desarrollo completo
- Stack
- Next.js 16, TypeScript, Tailwind 4, Drizzle, Neon Postgres / PGlite, React Email, Go
- En vivo
- rodarmdq.com.ar ↗
Los comercios de Mar del Plata pedían siempre lo mismo: catálogo, carrito, checkout, pedidos y un panel que puedan manejar solos. La primera, 3:23, era un frontend con datos de prueba. Armar cada tienda desde cero llevaba semanas, y copiar la anterior a mano arrastraba la marca, los textos y las fotos del cliente anterior.
Tres decisiones que lo definieron.
La plantilla se genera desde una tienda real
Por qué. Rodar MDQ es la tienda de referencia. El CLI exporta su último commit con git archive, saca las fotos, los textos y las URLs de Cloudinary de Rodar, pone encima una marca de relleno llamada Faro y verifica que lleguen todas las migraciones y los scripts de base. El starter nunca se edita a mano, así que no se aleja del código que corre en producción.
El costo. Un arreglo del core tiene que entrar primero en Rodar. Algunos restos de Rodar en archivos del core se reemplazan con una lista de textos, que sólo avisa cuando un texto ya no está.
Copiar el core, no compartir un paquete
Por qué. new-store copia el starter en un repo propio, con su base en Neon y su proyecto en Vercel. Las palabras del rubro, las rutas y los módulos viven en la config y en un léxico, así BiciTienda pudo sumar talles y colores, turnos y cuentas de cliente sin tocar Rodar.
El costo. Un arreglo no llega solo a las tiendas que ya existen. Cada una lo recibe con un cherry-pick a mano.
Cada integración tiene un reemplazo local
Por qué. Sin variables de entorno, la tienda usa PGlite en vez de Neon, escribe los mails en una bandeja local, paga con una página de prueba y abre el panel con un PIN de desarrollo. Una tienda nueva corre con migrate, seed y dev, y se la puedo mostrar al cliente antes de que nadie cree una cuenta en ningún lado.
El costo. Dos caminos de código por integración. La página de pago de prueba tuvo que quedar bloqueada en producción, y PGlite puede esconder una diferencia con Neon hasta el deploy.