La historia suena demasiado familiar: meses de vértigo, lanzamientos a toda velocidad, primeros clientes satisfechos… hasta que el producto se vuelve frágil, cada despliegue es una ruleta rusa y las nuevas funciones rompen las antiguas. El emprendedor y consultor Meir Avimelec Davidov en Reddit —que asegura haber auditado 47 bases de código de startups cuando “todo arde, pero no por falta de dinero sino por falta de escalabilidad”— lo resume en una cronología escalofriante:
- Meses 1–6: todo fluye. Se lanza rápido, crecen los clientes, la moral sube.
- Meses 7–12: aparecen bugs “raros”; el lema pasa a ser “ya lo arreglaremos”.
- Meses 13–18: no se puede añadir una función sin romper tres; cada deploy es una tensión.
- Meses 19–24: contratas tres ingenieros más, pero solo mantienen el incendio. Nada nuevo llega a producción.
- Meses 25+: reescribir desde cero o ver morir tu startup a cámara lenta.
Su diagnóstico, polémico y aplaudido a partes iguales en foros de emprendedores, llega con números que duelen:
- 89 % de las codebases auditadas no tenían índices en base de datos. La app estaba lenta porque buscaba entre 100.000 registros en cada petición.
- 76 % pagaban hasta 8× más servidores de los necesarios. Utilización media: 13 %. Se paga por 100 y se usan 13.
- 68 % arrastraban vulnerabilidades de autenticación “para dar un ataque de pánico a cualquier equipo de seguridad”.
- 91 % carecían de tests automatizados. Cada entregable era tiro al aire.
La aritmética es demoledora. Con un salario medio de 120.000 US$ por ingeniero, si el equipo dedica —como estimó Stripe— un 42 % de su tiempo a lidiar con mal código, un equipo de 4 personas en 3 años quema > 600.000 US$ solo en sostener la basura. Súmese 200.000–400.000 US$ por reescritura y 6–12 meses de ingresos perdidos durante la migración: daño total por compañía, 2–3 millones de US$.
A sus ojos, la receta preventiva es terrenal: dos semanas de arquitectura, tests desde el día uno, tecnología “aburrida” (React/Node/PostgreSQL, por ejemplo), y alguien con experiencia revisando la arquitectura la primera semana, no en el mes 12.
La discusión está servida: ¿es esto la norma en startups que fracasan o también en las que triunfan? ¿Hasta qué punto es sesgo de supervivencia? ¿Dónde queda el mantra del product-market fit?
Lo que sí aparece una y otra vez en startups que se frenan (y cómo se arregla en 48 h)
Más allá del debate, hay patrones técnicos objetivos que generan cuellos de botella y facturas innecesarias. Los más repetidos —y cómo atacarlos esta semana—:
1) Consultas que “leen el mundo” (sin índices)
- Síntomas: endpoints que tardan 4 s donde deberían tardar 40 ms; CPU y E/S disparadas en picos; timeouts en producción.
- Diagnóstico exprés: activar pg_stat_statements, slow query log, lanzar EXPLAIN ANALYZE a las 10 consultas más lentas; buscar N+1 en servicios.
- Corrección: índices compuestos y covering en claves de filtrado y orden; materialized views para agregados caros; caching (Redis) con TTL y invalidador; colas de trabajo para procesos pesados.
2) “Escalo” dándole al botón (sobredimensionar por pánico)
- Síntomas: facturas cloud que suben 10–50 k US$/mes sin base de usuarios equivalente; 13 % de utilización media.
- Diagnóstico exprés: auditoría de instancias, autoscaling policies, volúmenes y storage classes; activar cost alerts y budgets.
- Corrección: rightsizing (reservadas/ahorros), autoscaling basado en métricas reales (CPU, latencia, queue depth), apagar entornos o nodos fuera de horario, compresión y lifecycle en objects storage. Un caso real: de 47.000 US$/mes a 8.200 US$/mes en 3 días revisando servidores, storage y SQL.
3) Autenticación “con cinta adhesiva”
- Síntomas: tokens sin caducidad ni rotación; secretos en repos; “admin” con permisos “Dios”; cookies sin Secure/HttpOnly.
- Diagnóstico exprés: revisión de secrets, auditoría de roles y permisos, OWASP ASVS básico.
- Corrección: MFA, secret manager, rotación de claves, least privilege, expiración de tokens, refresh tokens con rotation detection, CSRF y cabeceras seguras.
4) Sin tests: cada entrega rompe algo (y nadie sabe qué)
- Síntomas: deploys nocturnos, rollbacks frecuentes, picos de Sentry/Rollbar.
- Diagnóstico exprés: ¿existe una pipeline que, con un botón, diga “nada roto”?
- Corrección: testing pyramid: unit (rápidos), contract/API, E2E (selectivos y estables). Cobertura razonable, no 100 %. Añadir smoke por feature y regresión para fallos repetidos. Feature flags, CI/CD con canarias y blue/green.
“Move fast (pero sin suicidarte)”: cómo equilibrar PMF y deuda técnica
No todos compran el discurso de que dos semanas de arquitectura “salvan 18 meses de infierno”. Varios fundadores y CTOs replican que la prioridad es el PMF y que sobre-ingenierizar te mata antes de saber si hay mercado. Tienen razón en parte. El equilibrio práctico:
- Monolito modular, no microservicios prematuros. Empieza simple, pero segmenta por módulos con interfaces claras para extraer a servicios cuando toque.
- Guardarraíles ligeros desde el día 1:
- Activar slow query log y pg_stat_statements.
- Índices obvios en tablas grandes y claves foráneas.
- Dos smoke tests por feature.
- Presupuesto de latencia y coste por endpoint (y vigilarlo).
- Cuota semanal de deuda (5–10 %): picos de valor sin dejar que el barro te hunda.
- Observabilidad mínima: traces (OpenTelemetry/New Relic), errores (Sentry), p95/p99 de latencia, saturación de colas.
- Reescritura como último recurso: mejor estrangular (Strangler Fig) módulos calientes con tests de contrato que tirar todo a la basura en mes 18.
Regla útil: “Construye para 10× sin cambiar conceptos; optimiza para 100× cuando los datos lo pidan.” Es decir: no shardees el día 1, pero no acoples de forma que sea imposible shardear el día 400.
Lista de comprobación en 30/60/90 días (equipo ≤ 6 personas)
Día 30
- Cost alerts y presupuestos en cloud; inventario de instancias.
- pg_stat_statements y slow query log activos; EXPLAIN de top 10 consultas.
- 2 smoke tests por feature; CI + linting.
- Roles/Permisos auditados; secrets fuera del repo.
Día 60
- Caching (Redis) y colas para trabajos pesados.
- Contract tests en APIs críticas; E2E en flujos de compra/login.
- Dashboards de p95/p99, errores, queue depth, utilización.
- Rightsizing de instancias; lifecycle en object storage; apagar entornos.
Día 90
- Canarias/Blue-green; feature flags.
- Playbooks de rollback y incident response.
- Security baseline (ASVS nivel 1–2).
- Arquitectura revisada por alguien que ya escaló (un día de design review paga años de dolor).
Tecnologías “aburridas” que funcionan (y por qué)
- Frontend: React/Vue estables, routing conocido, state sin excentricidades.
- Backend: Node/Express, Python/FastAPI/Django, Ruby on Rails, Go.
- Base de datos: PostgreSQL por defecto (transaccional, JSONB si hace falta), MySQL si hay legacy. Mongo con criterio (eventos/lecturas flexibles, no contadores bancarios).
- Infra: Docker+orquestador cuando toque; una VM bien configurada con systemd + supervisor vale para miles de usuarios.
- Mensajería: Redis, SQS, RabbitMQ; no inventes.
- Autenticación: OIDC/OAuth 2.1, secret manager, rotación.
PHP no es pecado: es un caballo de batalla con ecosistema maduro. Lo “aburrido” es bueno: hay talento disponible, documentación, casos resueltos… y menos sustos a las 2:00.
Cuándo reescribir (y cuándo no)
Sí tiene sentido:
- Dependencias no mantenidas o framework sin camino de migración.
- Cambios de modelo de datos que no caben con migrations razonables.
- Latencia/costes imposibles de domar tras 3 ciclos de refactor.
No tiene sentido:
- “No me gusta cómo se ve el código.”
- “Vamos a microservicios porque sí.”
- “Vendrá un silver bullet con X framework.”
Regla de oro: primero estrangula módulos con contratos y tests; si sigue siendo inviable, planifica la reescritura por fases con paridad funcional y canarias.
El elefante en la sala: PMF y sesgo de supervivencia
Varios fundadores y veteranos señalaron que muchas startups con el mismo desorden técnico sobreviven porque llega el dinero y pueden arreglarlo antes del colapso. Es cierto: PMF manda. Sin tracción, ninguna arquitectura te salva.
Pero hay matices:
- Si tu factura de cloud supera tu ARPU por cliente, un PMF incipiente puede morir por unit economics malos, no por falta de mercado.
- La velocidad de iteración cae con la deuda técnica: si no puedes iterar, te costará encontrar/defender el PMF.
- La disciplina mínima (índices, smokes, cost alerts) no retrasa el PMF; evita meses perdidos en incendios.
No es PMF vs. ingeniería. Es PMF con guardarraíles.
Preguntas frecuentes (FAQ)
¿Cómo evitar “optimizar prematuramente” y, aun así, no cavar mi tumba técnica?
Piensa en guardarraíles, no en catedrales: monolito modular, índices básicos, smokes, colas para lo pesado, dashboards p95/p99 y alerts de coste. Dedica 5–10 % del tiempo a deuda cada semana y no hagas “microservicios por fe”.
¿Qué índices DB son imprescindibles al principio?
- Claves foráneas y campos frecuentes de filtro/orden.
- Compuestos cuando filtras por dos o más columnas siempre juntas.
- Covering para lecturas “solo índice”. Verifica con EXPLAIN ANALYZE y revisa mensualmente con pg_stat_statements.
¿Cuánto invertir en tests automatizados en las primeras 12 semanas?
Apunta a smokes y contract/API tests de flujos críticos (login, pago, alta). E2E selectivo y estable (no pruebes el mundo). Metas realistas: cobertura del 30–50 % en unidades donde aporta, y 0 % en spikes que pueden morir al día siguiente.
¿Cómo sé si necesito reescribir o puedo refactorizar?
Si tras 3 iteraciones de estrangulamiento con tests de contrato y cambios localizados el p95 y el coste por request no mejoran, o si dependes de frameworks sin soporte, plantea reescritura por fases con paridad funcional, feature flags y canarias. Nunca “big bang”.
En una frase: “Muévete rápido, sí. Pero pon barandillas.” Unas dos semanas de arquitectura ligera y prácticas mínimas evitan que en el mes 18 te descubras pagando 40.000 US$/mes para sostener spaghetti que debió costar 4.000. El PMF manda, pero sin disciplina básica lo acabarás persiguiendo con los pies en el barro.
Conocimos de este hilo de Reddit gracias a:
