Team Alord, de Excel a plataforma ERP a medida en producción

¿Cuál era el problema?

Team Alord vende lotes con financiación directa, el cliente firma un plan de pagos mensual y Alord lleva la cartera. Al llegar a nosotros, toda esa operación vivía en múltiples hojas de Excel sin cruzar: un archivo por proyecto, pestañas separadas para clientes, pagos y cobranza, y una copia distinta en el computador de cada persona del equipo que necesitaba consultarla.

Los síntomas eran los esperados: cero visibilidad en tiempo real sobre morosidad, alertas manuales (o inexistentes) cuando un cliente no pagaba, trazabilidad imposible entre abonos y lotes, discrepancias entre lo que el dueño veía y lo que el operador registraba, y riesgo constante de perder dinero por seguimiento tardío. Cuando un comprador llamaba para preguntar cuánto debía, el equipo tenía que abrir el Excel del día, cruzar referencias y mandar una captura por WhatsApp, con suerte, con la cifra correcta.

¿Qué consideramos antes de construir?

Revisamos las opciones SaaS primero porque casi siempre son el default correcto cuando existen: Odoo (ERP modular), Siigo, Alegra, plataformas de administración de propiedades. Ninguna encajaba bien con la operación específica de venta de lotes con financiación directa: los ERPs genéricos manejan cartera, pero no la modelan por lote; las plataformas inmobiliarias asumen arriendo, no venta financiada; y forzar un SaaS genérico implicaba meses de configuración + renta mensual permanente + decisiones que no podíamos cambiar.

La pregunta crítica fue: ¿cuántos módulos específicos va a tener esta operación en los próximos dos años? La respuesta era "varios", lotes + cartera sí, pero también control financiero unificado, maquinaria pesada en alquiler, y gestión de documentos de los clientes. Ese tamaño + ese nivel de especificidad apuntaban a construir a medida. Un sistema propio cuesta más al inicio pero escala sin fricción y el código es tuyo.

¿Cómo diseñamos la solución?

La arquitectura es una aplicación Next.js 14 (App Router) respaldada por PostgreSQL vía Prisma, desplegada como contenedor Docker gestionado por Coolify en un VPS propio. Estructurada en módulos que comparten base de datos y autenticación pero son funcionalmente independientes:

• Loteos (lotes + cartera), CRUD de lotes con estados (disponible, vendido al contado, vendido financiado, reservado), registro de compradores, planes de pagos (mensual/quincenal), seguimiento de abonos lote por lote, detección automática de morosidad.
• Finanzas, ledger unificado de ingresos y gastos. Los pagos registrados en loteos generan automáticamente ingresos aquí; los gastos del negocio (nómina, servicios, mantenimiento) se registran con presupuestos por categoría y recurrencia.
• Maquinaria, inventario de equipos de alquiler con estados, registro de arrendamientos, mantenimiento preventivo y correctivo. Los pagos de arriendo se cruzan automáticamente con el ledger financiero.
• Documentos, manager polimórfico para subir cualquier tipo de archivo y asociarlo a una entidad (lote, comprador, arrendamiento, equipo, pago). Un solo punto de búsqueda para "el PDF que firmó Fulano en marzo".

Todos los módulos comparten tres roles de usuario: administrador (ve y edita todo), operador (registra transacciones diarias pero no configura) y socio/shareholder (solo lectura de indicadores clave). Los menús y las vistas se adaptan al rol automáticamente.

¿Qué stack técnico usamos y por qué?

• Next.js 14 App Router, Server Components para fetch de datos sin ceremonia, Server Actions para todas las mutaciones (formularios atómicos sin API REST intermedia). Reduce enormemente la cantidad de código glue entre frontend y base de datos.
• Prisma ORM + PostgreSQL 16, Prisma porque el tipado end-to-end entre schema, queries y TypeScript elimina una clase entera de bugs. PostgreSQL porque es la base de datos transaccional más confiable y sobrada para este tamaño.
• NextAuth v5, autenticación con tres roles (admin, operador, socio), sesiones JWT, sidebar adaptado al rol. Sin depender de Auth0 ni servicios externos.
• shadcn/ui + Tailwind, componentes accesibles, consistentes y 100% bajo nuestro control (no es una librería, son archivos que copias al repo). TanStack Table para los grids de datos, Recharts para los dashboards.
• Tesseract.js, OCR server-side en español para que los operadores puedan subir fotos de recibos y extraer montos/fechas automáticamente. Evita entrada manual de datos en el día a día.
• PWA installable, el equipo en campo puede instalar la app en su móvil como si fuera nativa. Funciona offline para lectura básica.
• Docker + Coolify + VPS (Hetzner), un contenedor multi-stage, deploy automático desde GitHub, SSL vía Let's Encrypt, control total del hosting. Costo mensual fijo, sin sorpresas.

¿Qué resultados entregamos?

El sistema pasó de prototipo a producción con datos reales en pocas semanas. Resultados concretos:

• Cartera de crédito organizada y accesible en tiempo real, cualquiera con permiso ve el estado de cualquier lote en segundos
• Alertas automáticas de morosidad, el sistema flaguea pagos vencidos sin intervención humana
• Cero persecución manual de pagos, el control de cobranza dejó de depender de recordar a quién llamar hoy
• Visibilidad operativa multi-módulo, el dueño ve ingresos, gastos, cartera y maquinaria en un solo panel, en vivo
• Sistema multi-usuario en producción con tres roles, cada uno con su propia vista de la información
• Datos reales importados desde los Excel existentes sin pérdida de historial

Tan importante como lo que construimos es lo que dejamos de tener: discrepancias entre copias de Excel, versiones contradictorias en diferentes equipos, y la ansiedad constante de "¿este número es el bueno?".

¿Qué aprendimos?

Tres reflexiones de este proyecto que aplicamos a todo ERP a medida desde entonces:

1. Los módulos deben compartir base de datos pero no acoplarse en código. Loteos, finanzas, maquinaria y documentos viven en el mismo Postgres, pero cada uno tiene sus propias server actions, sus propias vistas y su propia lógica de negocio. Esto permite agregar un módulo nuevo sin reescribir los existentes, cuando el cliente pide "¿y ahora podemos gestionar X?", la respuesta es "sí, en dos semanas", no "habría que rediseñar todo".

2. Server Actions son el patrón correcto para ERPs internos. No necesitas una API REST separada si tus usuarios son empleados autenticados usando un navegador moderno. Server Actions eliminan una capa entera de código (endpoints, fetch handlers, serialización) y mantienen las mutaciones cerca de la lógica de negocio.

3. La migración de datos desde Excel es la parte más delicada. Escribir el software es directo; importar los datos reales del cliente sin perder historial ni corromper referencias requiere scripts cuidadosos, validación manual, y una conversación honesta con el cliente sobre qué datos estaban mal desde el principio. Planear esta fase explícitamente desde el día uno evita sorpresas.