Turnos Parcelas
Software de facturación y turnos en producción para un negocio real.
- Año
- 2025 — actualidad
- Rol
- Único ingeniero — producto, backend, front y infraestructura
- Stack
- Python PostgreSQL Neon Railway Vue
Problema
Un negocio de gestión de parcelas llevaba los turnos y la facturación con hojas de cálculo y WhatsApp. Cada mes se rehacían las facturas a mano, la numeración se desajustaba y nadie podía responder "¿cuánto nos debía este cliente en marzo?" sin una sesión de arqueología.
Enfoque
Modelé el dominio primero — emisores, clientes, conceptos, series de factura — y convertí el número de factura en una secuencia garantizada por la base de datos, no en una convención de la aplicación. El stack es deliberadamente pequeño: PostgreSQL en Neon con una rama por rama de git, de forma que cada feature tiene una copia desechable con forma de producción, y un pipeline de despliegue en Railway que solo promociona lo que pasó contra esa rama.
Resultado
La facturación mensual pasó de una tarde entera de trabajo manual a unos cuantos clics. El sistema lleva en producción sin supervisión desde 2026, incluyendo notificaciones a varios emails por cliente y un diseño de factura en PDF que sobrevive a la impresora.
Por qué importaba la parte aburrida
La ingeniería interesante de un sistema de facturación no es facturar. Es asegurarse de que dos personas pulsando “crear factura” en el mismo segundo no generen el mismo número, de que borrar un cliente no deje huérfanos tres años de contabilidad, y de que el PDF siga cabiendo en una página cuando el cliente tiene catorce conceptos.
Ramas de base de datos como red de seguridad
Cada rama de git tiene su propia rama de Neon. Eso convirtió “me da miedo tocar la numeración de facturas” en “he corrido la migración contra una copia real y los números salieron bien”. Es el cambio que más mejoró mi velocidad.
Sustituye esta sección por las cifras concretas que quieras compartir: facturas emitidas, clientes, tiempo ahorrado. Lo concreto gana a los adjetivos.