Arquitectura de guerrilla: Cómo sobreviví al éxito de mis propios MVPs

En la teoría del desarrollo de software, uno diseña el sistema perfecto antes de escribir una línea de código. En la realidad operativa de una empresa constructora, uno apaga incendios.

Mi historia comenzó con una necesidad financiera urgente: controlar el gasto de agua y electricidad. Había sospechas de roturas invisibles y desviaciones de consumo en obras y oficinas que estaban drenando presupuesto.

La solución no fue un ERP millonario. Fue un script de PHP simple, una base de datos MySQL en una instancia clásica (Cloudways) y un subdominio improvisado: medidor.miempresa.cl.

Tres veces por semana, los encargados ingresaban la lectura. Y funcionó. Detecté fugas, la empresa ahorró dinero y validé la hipótesis: la digitalización en terreno paga.

Pero el éxito tiene un precio y yo estaba a punto de pagarlo.

Fase 1: La proliferación del caos

Al ver que “el sistema de los medidores” funcionaba, la organización pidió más. Control de combustible, recepción de hormigones, áridos, entre otros.

Como Business Engineer pragmático, en ese momento prioricé la velocidad sobre la arquitectura. Cloné el script, levanté otra base de datos MySQL aislada y creé otro subdominio.

En seis meses, había creado un “Frankenstein” operativo con URLs independientes:

• combustible.miempresa.cl
• hormigon.miempresa.cl
• aridos.miempresa.cl

Los 3 dolores de cabeza (pain points)

Aunque resolvía el problema inmediato, estaba creando una deuda técnica y operativa insostenible:

1. La fricción cognitiva (el usuario perdido): Los capataces en obra no son informáticos. Tener que recordar 5 URLs distintas era pedir demasiado. El sistema digital fallaba por usabilidad básica, y volvían al papel.

2. La “cirugía” de datos (el terror del admin): No teníamos panel de administración. Si un operario se equivocaba y ponía “10.000 litros” en vez de “100”, el reporte se rompía. Para arreglarlo, yo tenía que entrar a phpMyAdmin, buscar entre 5 bases de datos distintas y editar la fila SQL a mano. Un clic en falso y borraba el historial de la obra.

3. Datos “muertos” y centralismo: Conecté todo a Looker Studio para generar reportes en PDF que se enviaban a gerencia a fin de mes. ¿El problema? Los reportes llegaban tarde (“post-mortem”) y nadie en la obra los veía. El capataz seguía gastando a ciegas porque no tenía feedback inmediato.

Fase 2: La centralización (el nuevo stack)

Entendí que no podía seguir construyendo “islas”, necesitaba un continente. La solución era una plataforma centralizada.

Migré todo a una sola aplicación web (app.miempresa.cl) desarrollada en un stack moderno (Astro para velocidad en 3G, Neon para datos).

1. De “Nadie sabe” a responsabilidad individual (auth): El mayor riesgo de los formularios PHP públicos no era que un hacker entrara, sino la falta de accountability. Si desaparecía petróleo, nadie sabía quién llenó el formulario. Al implementar un sistema de usuarios real, cada litro reportado tiene un nombre y apellido asociado. La calidad del dato subió drásticamente solo por saber que el sistema “te conoce”.

2. Autonomía operativa (democratización del dato): Al centralizar todo en una App, dejé de depender de que el gerente lea el PDF. Ahora, el propio administrador de obra entra a la App y ve sus gráficas de consumo en tiempo real. La operación pasó de un modelo de “Control y Castigo” (el gerente ve el error a fin de mes) a uno de “Autogestión” (la obra corrige el rumbo hoy mismo).

3. Eficiencia de costes (por qué Neon): Podría haber usado un servidor SQL tradicional gigante, pero las obras de construcción tienen horarios erráticos. Elegí Neon (Serverless Postgres) porque permite escalar a cero. Si de noche o los domingos nadie usa la app, no se paga por recursos ociosos. Se pasó de pagar por servidores fijos a pagar por uso real, alineando la tecnología con el margen del negocio.

Conclusión: Evolucionar duele, pero es necesario

Mirando hacia atrás, no me arrepiento de la fase PHP. Esos formularios “sucios” y rápidos me permitieron validar que la empresa necesitaba estos datos sin gastar una fortuna.

Pero un Business Engineer sabe cuándo una solución “parche” ha cumplido su ciclo. Pasar de la anarquía de scripts a una plataforma centralizada no fue un capricho técnico; fue la única forma de convertir datos dispersos y peligrosos en un sistema operativo seguro y rentable.