TuTiendaWeb
SaaS multi-tenant para comercios: productos, ventas, clientes y pedidos por WhatsApp.
Comerciantes del interior argentino gestionando pedidos por WhatsApp y papel.
Los pequeños y medianos comercios de proximidad operaban con un flujo completamente manual: tomaban pedidos por WhatsApp a mano, respondían uno por uno y anotaban en papel. Sin catálogo digital, sin datos de ventas, sin disponibilidad fuera de horario. Construí una plataforma SaaS multi-tenant que digitalizó todo ese flujo.
- 2–3 horas diarias respondiendo consultas y anotando pedidos manualmente.
- Sin catálogo digital: el cliente preguntaba qué había y el comerciante respondía uno por uno.
- Sin datos de negocio: no sabían cuánto vendían por semana ni qué producto rotaba más.
3 fricciones costosas, todos los días.
Tiempo operativo
2–3 horas diarias respondiendo mensajes y coordinando pedidos por WhatsApp. Tiempo robado al trabajo real.
Ventas perdidas fuera de horario
Si el cliente consultaba a las 22hs y el comerciante no estaba disponible, el pedido se perdía o se enfriaba.
Sin datos de negocio
Sin métricas de ventas. Calcular los ingresos del mes implicaba revisar chats o cuadernos. Decisiones a ciegas.
Qué no se podía romper.
Proyecto bootstrapped sin equipo. Cada decisión técnica tenía que maximizar el producto entregado por hora de desarrollo.
El comerciante no puede cambiar su canal de comunicación. La solución debía integrarse a WhatsApp, no reemplazarlo.
SaaS en etapa MVP: cero costo fijo de servidor, todo serverless o BaaS hasta demostrar product-market fit.
Cada comercio ve solo sus propios datos. El aislamiento tiene que ser real, no solo en la UI.
Qué se construyó.
SaaS multi-tenant: cada comercio tiene su tienda, panel de gestión, pedidos por WhatsApp, cobros con MercadoPago y reportes en PDF/Excel.
El producto en producción.
Dashboard principal
Gestión de productos
Detalle de producto con variantes
Dashboard de ventas y métricas
Código QR único del comercio
Home de la tienda
Catálogo de productos
Resumen del pedido antes de confirmar
Confirmación del pedido
Mensaje de WhatsApp generado automáticamenteStack moderno, pragmático, mantenible.
- Next.js 14 (App Router)
- React
- TypeScript
- Tailwind
- ShadCN
- Zustand
- Zod
- Firebase Auth
- Firestore
- Firebase Storage
- Mercado Pago API
- Webhooks con firma HMAC
- Vercel
- CI/CD automático desde GitHub
Tres decisiones que se sostienen seis meses después.
Firebase, no PostgreSQL propio en servidor
Para un SaaS MVP sin equipo, Firebase eliminó semanas de trabajo: auth integrada, real-time out-of-the-box, reglas de seguridad por documento, sin servidor a mantener.
Mercado Pago, no Stripe
Mercado argentino: los comercios ya conocen y usan MP, acepta ARS directamente, y la tasa de adopción era cero — ya tienen cuenta.
PDFs generados en el cliente, no en servidor
Para reducir costos de infraestructura, los reportes se generan completamente en el cliente usando html2canvas + jsPDF y @react-pdf/renderer.
Lo que no estaba en el plan.
- Flujo de pedidos por WhatsApp sin perder estructura. El desafío era que los pedidos llegaran al comerciante organizados. La tienda construye el pedido como objeto estructurado y al confirmar genera un mensaje de WhatsApp formateado automáticamente con nombre, productos, cantidades, precio total, forma de pago y dirección.
- Modelo de variantes de productos flexible en Firestore. Los comercios tienen productos con combinaciones arbitrarias (ropa: talle + color, bebidas: tamaño + sabor). Diseñé el schema con variantes como arrays de pares {atributo, valor} — cualquier tipo de comercio puede cargarlo sin modificar el modelo.
- Webhooks de Mercado Pago con verificación de firma. Los eventos de pago se verifican contra la firma HMAC que MP incluye en el header. Webhooks no firmados se descartan antes de tocar la base de datos.
Lo que cambió, medido.
Lo que me llevo para el próximo proyecto.
- El canal importa tanto como el producto. Integrar WhatsApp en lugar de reemplazarlo fue la decisión que hizo viable la adopción. Un canal nuevo habría triplicado el tiempo de onboarding.
- Multi-tenancy desde el día uno, no después. Las reglas de Firestore por UID se definen al inicio. Agregar aislamiento después de tener datos es costoso y riesgoso.
- El PDF más útil no es el más lindo, es el que el comerciante puede entregar al cliente sin editar. Diseñé los reportes con datos reales desde el MVP.
¿Querés un proyecto así para tu producto?
Respondo en menos de 24 hs hábiles. Cuanto más concreto el contexto, más rápido te digo si encaja.