Puedes. Eso no está en discusión.
Con Cursor, Lovable o Bolt, alguien con criterio técnico puede tener un prototipo funcional de control de presupuestos de obra en menos de 8 horas. Una interfaz limpia, campos personalizados, quizás una tabla de partidas con semáforos de alerta. Si le dedicas un fin de semana largo, le agregas autenticación, un dashboard y exportación a PDF.
El resultado va a ser mejor que el Excel que usa tu equipo ahorita. Va a verse bien. Y vas a tener la satisfacción legítima de haber construido algo que resuelve un problema real de tu operación.
El problema no es que no puedas construirlo. Es lo que viene en los siguientes 18 meses.
El prototipo versus el producto
Hay una distinción que no es obvia hasta que ya estás adentro: un prototipo demuestra que algo es posible. Un producto demuestra que algo es sostenible.
El prototipo que construyes en un fin de semana cubre el caso de uso ideal: un proyecto, un usuario, datos limpios, sin errores de captura, sin el residente que escribe «varilla 3/8» en un campo que espera un número. Funciona perfectamente en las condiciones de laboratorio de tu laptop.
La operación real de una constructora no funciona en condiciones de laboratorio.
En producción, el sistema va a recibir entradas que no anticipaste. El almacenista va a subir una foto de una factura en lugar de escribir el número. Dos residentes van a registrar el mismo pedido desde dispositivos distintos y vas a tener un duplicado que nadie sabe cómo resolver. Alguien va a borrar una partida por error y vas a necesitar un historial de cambios que no implementaste porque en el prototipo no parecía necesario.
Cada uno de esos casos es un bug. Cada bug es una hora tuya o de alguien en tu equipo. Multiplicado por la frecuencia con que ocurre, por el número de proyectos abiertos, por los doce meses del año.
El costo que no aparece en el prompt
Cuando calculas si vale la pena construir tu propio sistema, el error más común es comparar el costo de la suscripción contra el costo de las horas de construcción inicial. Ese cálculo está incompleto.
El costo real tiene cuatro componentes que raramente se suman juntos:
Construcción inicial: las horas del fin de semana. El costo más visible y el más bajo de los cuatro.
Mantenimiento correctivo: cada vez que algo se rompe en producción. Una actualización del navegador que rompe un componente. Un cambio en la API de algún servicio que integraste. Un error de base de datos que corrompe registros. Con vibe coding, el código que generó la IA es funcional pero raramente está estructurado para ser fácil de mantener. Cada corrección requiere re-entender lo que se construyó.
Mantenimiento evolutivo: cada vez que la operación cambia y el sistema necesita cambiar con ella. Un cliente nuevo que requiere un formato de reporte distinto. Una obra con una estructura de partidas diferente a las anteriores. Un módulo de órdenes de cambio que no existía en el MVP. Cada mejora es un proyecto nuevo, con su propio costo de tiempo.
Costo de oportunidad: esto es lo que realmente duele. Cada hora que dedicas a mantener, mejorar o debuggear tu sistema propio es una hora que no dedicaste a conseguir el siguiente proyecto, a mejorar tus márgenes o a escalar tu operación. Para un CEO de constructora, el costo de oportunidad de una hora es considerablemente más alto que el de un desarrollador junior.
Hay un número que vale la pena hacer explícito: si mantenimiento y mejoras te toman en promedio 4 horas al mes —un estimado conservador para cualquier sistema en uso real— y tu hora vale $100 dólares, eso son $4,800 dólares al año solo en tiempo de mantenimiento. Sin contar lo que dejaste de hacer.
El problema que no se resuelve con código
Hay algo que ningún sistema construido desde cero resuelve automáticamente, independientemente de qué tan bien esté programado: la adopción del equipo de campo.
El residente de obra que tiene 58 años y lleva tres décadas en la industria no va a usar tu sistema porque lo construiste tú. Lo va a usar si la interfaz es tan simple que no requiere explicación, si funciona bien en su celular viejo con señal irregular, y si el proceso de registrar algo es más rápido que mandarte un mensaje de WhatsApp.
Eso no es un problema de código. Es un problema de diseño de producto que se resuelve con años de iteración sobre usuarios reales con comportamientos reales.
Mawi lleva iterando sobre ese problema específico desde su fundación. El flujo de captura desde campo fue rediseñado múltiples veces basado en cómo se comportan realmente los residentes y almacenistas en obras de México, Honduras y Guatemala. Esa información no está disponible en ningún prompt.
Tu prototipo va a tener el flujo que tú imaginaste que tiene sentido. El flujo que realmente funciona con equipos de campo es el resultado de haber visto fallar docenas de versiones anteriores.
Lo que sí tiene sentido construir con vibe coding
Para ser precisos: hay casos donde construir tu propio sistema es la decisión correcta.
Si tienes un proceso muy específico de tu operación que ningún software del mercado contempla —un tipo de contrato particular, una estructura de costos inusual, una integración con un sistema heredado que solo tú usas— entonces construir tiene sentido. El costo de adaptar un software genérico puede superar el costo de construir algo propio.
Si eres una empresa de tecnología que además hace construcción, y tienes un equipo de desarrollo interno que puede mantener el sistema, los números cambian.
Si estás construyendo un prototipo para validar una hipótesis antes de invertir en software real, el vibe coding es exactamente la herramienta correcta. Rápido, barato, desechable.
Lo que no tiene sentido es construir tu propio sistema de control de obras como sustituto permanente de software especializado, cuando ya existen soluciones construidas específicamente para ese problema, probadas en producción real y con un costo de suscripción que se amortiza en la primera obra donde detectas un sobrecosto a tiempo.
La matemática del sobrecosto
Hay un número que ancla esta conversación: el 28% de sobrecosto promedio en proyectos de construcción en Latinoamérica.
En un proyecto de $5 millones de pesos, ese 28% son $1.4 millones de pesos que se perdieron. La mayoría de ese sobrecosto no ocurre por un evento catastrófico. Ocurre por acumulación de pequeñas desviaciones que nadie detectó a tiempo: compras no autorizadas que pasaron, partidas que se agotaron sin alerta, cambios de alcance que no se presupuestaron.
La diferencia entre detectar esa desviación el día que ocurre versus detectarla dos semanas después no es un problema de análisis. Es un problema de captura en tiempo real.
Si tu sistema propio no captura información desde campo de manera consistente —y los sistemas construidos rápidamente rara vez lo hacen, porque ese problema es más difícil de lo que parece— entonces tienes un sistema de reporteo, no un sistema de control.
Un sistema de reporteo te dice dónde estabas. Un sistema de control te dice dónde estás y hacia dónde vas.
El fin de semana que cuesta más de lo que parece
Volvamos al escenario inicial: decides construir tu sistema el próximo fin de semana.
Al final del domingo tienes un prototipo que funciona. Lo muestras al equipo el lunes, hay entusiasmo, lo empiezan a usar el martes.
Dos semanas después, el residente de la obra en Echegaray no ha registrado nada porque en su Android la pantalla de carga tarda 12 segundos con la señal que hay en la obra y se desespera. Tres semanas después, descubres que dos usuarios registraron la misma compra y no sabes cuál es el correcto. Un mes después, un cliente pide un reporte en un formato que tu sistema no genera y pasas cuatro horas del miércoles adaptándolo.
En ese punto llevas invertidas quizás 20 horas entre construcción y correcciones. El sistema tiene datos inconsistentes porque la adopción fue parcial. Y todavía falta resolver el problema original: visibilidad en tiempo real del estado financiero de cada obra.
No porque hayas hecho algo mal. Sino porque ese problema tiene más superficie de la que es visible desde el exterior.
La pregunta que ordena la decisión
Hay una forma de saber si vale la pena construir o suscribirse: ¿cuál es tu ventaja competitiva?
Si tu ventaja competitiva está en construir software mejor que el mercado para gestión de obras, entonces construir tiene sentido. Es tu core.
Si tu ventaja competitiva está en ejecutar proyectos de construcción de manera más rentable, más rápida o con mejor calidad que tu competencia, entonces el sistema de control de obras es infraestructura, no diferenciador. Y la infraestructura que no es tu diferenciador no debería consumir tu tiempo ni tu energía.
Los mejores operadores en cualquier industria no construyen sus propias herramientas de ERP, sus propios sistemas de nómina ni su propio software de facturación. Los usan. Su tiempo va en lo que genuinamente los hace mejores que el resto.
La pregunta no es si puedes construir Mawi. Puedes. La pregunta es si hacerlo es el mejor uso de las horas que tienes disponibles esta semana.
Si quieres ver qué resuelve Mawi en una obra real antes de decidir, agenda una demo. Sin presentación de ventas — solo el producto funcionando.
