Del cuaderno de un amigo a un SaaS multi-tenant
Mi mejor amigo tiene un car detailing, The King Shine. Las reservas, la caja y los materiales vivían en papel y en Excel. Construí ShineApp solo, del modelo de datos a la interfaz, y hoy opera su día a día.
- Rol
- Todo: producto, backend, frontend, infraestructura
- Stack
- Django, DRF, Next.js, React, TypeScript, PostgreSQL
- Infra
- Vercel + Supabase, presupuesto cero
- Usuarios
- 1 negocio en producción: The King Shine
- Estado
- Desarrollo activo pausado
Un negocio real funcionando en papel
Un detailing maneja reservas, vehículos, servicios que consumen materiales, cobros, deudas y una caja que tiene que cerrar todos los días. The King Shine hacía todo eso en papel y en Excel.
Un usuario, construido como producto
Tenía un usuario real y cero presupuesto. Aun así diseñé ShineApp como un producto para muchos negocios: vi mercado en el rubro, y el objetivo es hacerlo comercial.
Todo
Decisiones de producto, modelo de datos, API, interfaz, infraestructura, tests y documentación. Trabajé con agentes de IA (Claude y Codex) dentro de specs y ADRs escritos.
El recorrido de un trabajo en ShineApp
- PedidoLos clientes piden un turno o una cotización desde la turnera pública
- PresupuestoPresupuestos grupales de hasta 25 autos, en PDF
- ReservaAgenda diaria, semanal y mensual con control de capacidad
- Orden de trabajoMateriales consumidos por receta, por servicio
- CobroCobro al entregar; deudas registradas
- Caja cerradaCaja diaria con conciliación
Decisiones con presupuesto cero
Multi-tenant desde el día uno
Por qué - Cada registro pertenece a una cuenta de negocio, y el backend hace cumplir ese límite en una capa compartida. Hay tests dedicados que verifican que ningún negocio pueda leer datos de otro.
Costo
Más trabajo al principio para un producto con un solo cliente. Es lo que hace posible el segundo.
Serverless con presupuesto cero
Por qué - Web y API corren como funciones de Vercel; datos y archivos viven en Supabase. Sin workers, un cron de GitHub Actions llama a un endpoint de mantenimiento cada 15 minutos, y las migraciones nunca corren en un cold start.
Costo
Cold starts y una base más lenta. Diseñé la interfaz alrededor de eso. El objetivo es contratar mejor infraestructura cuando ShineApp salga a venderse.
UX para infraestructura lenta
Por qué - Deduplicación de requests, requests cancelables, skeletons y stale-while-revalidate en el frontend; índices compuestos y prefetch en el backend.
Costo
Más piezas en el cliente, a cambio de una interfaz que se siente rápida sobre infraestructura barata.
Una turnera pública para cada negocio
Por qué - Cada negocio tiene su propia página pública donde los clientes piden un turno o una cotización, con su vehículo y el día y horario que prefieren. Los pedidos llegan como pendientes y el dueño los convierte en una reserva o un presupuesto en un paso, y elige qué servicios muestra la página.
Costo
Es una entrada pública y sin login a un sistema multi-tenant: cada pedido queda atado a su negocio y nada llega a la agenda hasta que el dueño lo acepta.
Roles que esconden el dinero
Por qué - Dueños y empleados comparten la agenda y las órdenes de trabajo; los empleados nunca ven datos financieros.
Costo
Chequeos de permisos en cada endpoint y pantalla financiera.
Qué está en producción
- Agenda con drag-and-drop, control de capacidad por sector y superposiciones
- Presupuestos grupales y PDFs
- Caja con cierre diario y conciliación
- Deudas y gastos fijos
- Materiales con recetas y unidades abiertas
- Precios por tipo de vehículo
- Turnera pública por negocio, con los servicios que el dueño elige mostrar
- Dashboard, búsqueda global, papelera y registro de auditoría
- Automatización de WhatsApp y stock (construidos, The King Shine todavía no los usa)
Dónde está hoy
En producción con The King Shine, que usa todos los módulos excepto stock y WhatsApp. El desarrollo activo está pausado por falta de tiempo. Los próximos pasos del roadmap son facturación, invitaciones de equipo y entornos separados de staging y producción.
Aceptar la ayuda de Juani construyendo ShineApp fue un antes y un después para The King Shine. Controlar la economía, los tiempos y todo el negocio en un solo lugar agilizó increíblemente la forma en la que trabajo. Recomiendo tanto ShineApp para otros colegas del rubro como a Juani como programador, ya que supo entender mi problema y resolverlo de manera profesional y eficiente.
Qué me llevé
- Sentarse al lado de quien usa la herramienta vale más que cualquier spec.
- Un plan gratuito es una restricción de diseño. Hay que planificar para eso desde el principio.
- Aislar tenants es barato el día uno y caro después.
Hablemos
Software engineer enfocado en backend: Python, Django y DRF, con React y Next.js en el frontend. Construyo y mantengo sistemas en producción con reglas de negocio complejas y muchas integraciones, y uso herramientas de IA todos los días sin bajar la vara.
- Disponible ya - contractor o full-time
- Inglés fluido
- Superposición completa con el horario de la costa este de EE.UU. (GMT-3)