Saltar al contenido
elmalmenor.com [OPERATIONAL] 140,000 users · last incident: 0 days
vittasami.com [OPERATIONAL] multi-tenant · 4 países
suit.pe [OPERATIONAL] SUNAT-integrated · 99.9% uptime
intinovalabs.com [ACCEPTING CLIENTS] 20 auditorías disponibles
elmalmenor.com [OPERATIONAL] 140,000 users · last incident: 0 days
vittasami.com [OPERATIONAL] multi-tenant · 4 países
suit.pe [OPERATIONAL] SUNAT-integrated · 99.9% uptime
intinovalabs.com [ACCEPTING CLIENTS] 20 auditorías disponibles

~ 5 min · 2026-04-22 · by Jose Burga

Por qué existimos: 140k usuarios y un código que no aguantaba

Un VAA peruano que explotó, casi colapsó, y nos enseñó dónde está el negocio. La historia corta de cómo Intinova Labs encontró su tesis.

#historia #elmalmenor #vibe-coding
Captura de terminal mostrando el incidente de ElMalMenor el 15 de octubre 2025 — latencia p95 4213ms con 8047 usuarios activos, seguido de la resolución tras la rearquitectura

El día que se rompió

El 15 de octubre de 2025, a las 21:08, ElMalMenor.com empezó a fallar. 8,000 usuarios concurrentes intentando completar un test de afinidad política al mismo tiempo. La latencia p95 superó los 4 segundos. Un deploy que intentaba parchar un bug rompió la autenticación. Los costos de hosting se triplicaron en 7 días.

Yo (Jose) lo construí solo en 30 días, con Claude y Cursor, sin saber programar formalmente. Funcionaba para 100 usuarios. Funcionaba para 1,000. Para 8,000 simultáneos, no.

Lo que NO era

No era un problema de IA. La IA hizo exactamente lo que se le pidió: producir código que funciona. Es lo mismo que pasaría con un junior dev con 6 meses de experiencia construyendo lo mismo: el código funciona, valida la demanda, pero no tiene la estructura para sostener crecimiento real.

No era culpa del producto. El producto fue un éxito — captó tracción, generó cobertura mediática, sirvió a la conversación electoral. Esa parte estaba bien hecha.

Era un problema de transición. El gap entre prototipo y producto que casi nadie está mirando.

Lo que aprendí

Tres cosas que sigo aplicando hoy:

1. Validar y escalar son habilidades distintas

Los founders no-técnicos podemos validar demanda con IA. Esa parte ya no es debate. Lo que muchos no entendemos es que la habilidad para llevar un MVP a producción real es completamente distinta — requiere arquitectura, observabilidad, gestión de costos, manejo de incidentes. Eso no se improvisa.

2. Reescribir es casi siempre la respuesta incorrecta

Cuando el sistema falló, mi primera reacción fue “tirémoslo y empecemos de cero con un equipo de devs senior”. Mi hermano Álvaro me detuvo. La rearquitectura preservando lo que funcionaba tomó 3 semanas. Una reescritura completa hubiera tomado 3 meses como mínimo y hubiera matado el momentum del producto.

Reescribir desde cero no es valentía técnica. Es admitir que no sabes encontrar lo que vale la pena conservar.

3. La oportunidad de mercado está en la transición

Mientras todos los founders en LATAM construyen prototipos con IA y celebran los primeros 1,000 usuarios, muy pocos están equipados para llevar esos prototipos a 100,000 usuarios sin dejar caer el producto en el camino.

Esa observación es la tesis de Intinova Labs. No construir más prototipos. Rescatar los que ya están funcionando y llevarlos al siguiente nivel.

Lo que sigue

ElMalMenor sigue vivo (puedes verlo arriba en el status bar — esos números son reales y se actualizan). Tras las elecciones, evolucionó a una herramienta de seguimiento de promesas de campaña. Cada nueva feature ahora tarda horas, no días.

Y nosotros — Jose, Álvaro, Paloma — formalizamos Intinova Labs poco después. Llevamos meses recibiendo consultas de fundadores que están exactamente donde estábamos nosotros en septiembre 2025. La diferencia es que ahora sabemos cómo ayudarlos.

Si te suena familiar, probablemente sí lo sea. Conversemos.

> Solicitar auditoría — S/ 379


Preguntas frecuentes

¿Cuándo conviene migrar de IA-coding a código profesional?
Cuando tu producto pasa los 1,000 usuarios concurrentes, cuando agregar una feature toma más de 1 semana porque hay que pelear con el código existente, o cuando los costos de infraestructura crecen más rápido que tus usuarios. Esos son los tres signos clínicos.
¿El vibe coding es malo?
No. Es excelente para validar. Es frágil para escalar. Es la herramienta correcta para los primeros 30 días y la herramienta incorrecta para los siguientes 12 meses. La transición tiene que pasar en algún punto.
¿Cuánto cuesta rescatar un MVP vibe-coded?
Depende del tamaño y del estado. Una auditoría diagnóstica (5 días, S/ 379) te da un número exacto. Para referencia, rescates típicos van entre S/ 15,000 (caso simple, 4 semanas) y S/ 80,000 (caso complejo, 12+ semanas).

// related: /casos/elmalmenor · /servicios/rearquitectura-y-escalado

¿Te suena familiar?

Si lo que leíste describe tu producto, una auditoría técnica de S/ 379 te da un diagnóstico real en 5 días.

Solicitar auditoría →