KISS o muere: Por qué los ingenieros senior fracasan en las Startups

Mi primera startup fue un fracaso, y varias startups vecinas también fracasaron. Teníamos: $100K en créditos de GCP, un ingeniero fundador que había construido sistemas en empresas, y estrategia de comercialización. Y fracasamos, no porque lo construimos mal, sino porque lo construimos bien. Ese fue el problema.

Mientras pasábamos tiempo luchando con lo que parecía un stack tecnológico "no óptimo", perdimos lo más importante: tiempo, impulso y estratégicamente una oportunidad.

Esta historia no trata sobre personas sin sentido común. Yo tenía sentido común, y sabíamos que debíamos mantener las cosas simples. Pero cuando tu modelo mental no se ajusta a la situación, todo tu sentido común desaparece. Tomas decisiones "correctas" que te matan.

Tampoco es una historia sobre mala ingeniería. Es sobre cómo la buena ingeniería mata startups. Cómo la misma experiencia que te hace senior se convierte en tu mayor responsabilidad. Cómo "hacerlo bien" o incluso "hacerlo simple" a menudo es hacerlo mal.

Este artículo presenta modelos mentales para ayudarte a tomar las decisiones correctas y evitar las equivocadas que yo tomé.

:::tip Para quién es esto: ingenieros senior que comienzan o se unen a startups en etapa inicial. Si has pasado más de 5 años en empresas o Big Tech, esta es tu advertencia.

:::

\

Modelo Mental #1 - La infraestructura "gratuita" es la más cara

$100K en créditos de GCP parece un regalo, pero es una trampa. Te empuja hacia la sobre-ingeniería porque "ya está pagado". Obtienes instancias de computación, balanceadores de carga, registros de contenedores y herramientas empresariales que requieren configuración empresarial. ¿Qué necesitas conseguir? Un botón de "push para implementar".

Claro, puedes construir flujos de trabajo de "implementación desde GitHub a VM" en GCP/AWS/Azure. Algunos productos se acercan. Pero requiere pasos adicionales: configurar Cloud Build, establecer roles IAM, escribir scripts de implementación, gestionar secretos y configurar verificaciones de salud. Quemas tiempo construyendo infraestructura de implementación antes de implementar productos reales.

Mientras tanto, plataformas como Railway o Fly.io te dan lo que las startups realmente necesitan: una VM persistente con implementación rápida desde GitHub. Tan fácil como puede ser: haces push de tu código y se implementa. Solo una VM lista para usar con variables de entorno, SSL, balanceadores de carga, registros, etc. No es "gratis", pero está lista.

Los créditos gratuitos te empujan hacia la sobre-ingeniería porque "ya está pagado". Te convences de que estás ahorrando dinero mientras gastas tu recurso más valioso: el tiempo.

\

Modelo Mental #2 - "Mínimo" <> "Simple"

El principio tradicional KISS nos dice que mantengamos nuestro software simple. Pero en startups, ese es el objetivo equivocado. No deberías mantener tu SOFTWARE simple; deberías mantener tus SOLUCIONES simples.

La verdadera simplicidad debería medirse por el esfuerzo total, no por la complejidad del código:

Esfuerzo Total = Construcción Inicial + Mantenimiento + Depuración + Adición de Funciones + Actualizaciones de Seguridad + Cambios de Escalabilidad

Cuando construyes desde cero, eres dueño de todos estos para siempre. Cuando usas un servicio, la mayoría de estos se vuelven cero. El servicio de terceros "inflado" es en realidad la solución simple porque minimiza el esfuerzo total.

Mi ejemplo de OAuth

Nuestro ingeniero fundador decidió construir OAuth desde cero en lugar de usar una "biblioteca desconocida". Una semana después, envió un PR: implementación limpia de OAuth con tokens JWT, rotación de tokens de actualización, gestión de sesiones y control de acceso basado en roles. Sin dependencias, sin bloqueo de proveedor, solo código que controlábamos.

No rechacé el PR. Y esto fue un error. Desechar una semana de trabajo habría aplastado la moral. Pero crea complejidad de código y lo pone en los rieles equivocados. Además, no discutir el enfoque de antemano fue nuestro verdadero error. Dejamos que el orgullo de ingeniería tomara una decisión estratégica.

Luego, un cliente necesitaba OAuth de Microsoft y OAuth de Google. La implementación personalizada significó días de refactorización, rotación de tokens de actualización, casos extremos, RBA y otras cosas. Cada adición "simple" requería una comprensión profunda de nuestra autenticación personalizada. Cada actualización de seguridad era nuestra responsabilidad implementarla. Cada nuevo requisito era nuestro para codificar.

Principios

Error clásico de ingeniero senior: optimizar para el control en lugar de los resultados. En startups, la realidad requiere invertir completamente cómo piensan los ingenieros senior:

1. DEJA de pensar: "Esto es solo unos días de codificación" \n EMPIEZA a pensar: "Estos son unos días NO codificando mi producto real"
2. DEJA de pensar: "Puedo construir esto simplemente" \n EMPIEZA a pensar: "Puedo resolver esto simplemente no construyendo"
3. DEJA de pensar: "Los servicios de terceros añaden complejidad" \n EMPIEZA a pensar: "Los servicios de terceros absorben complejidad"

\

\

Modelo Mental #3 - Elecciones de comodidad

Elegimos Angular porque nuestro ingeniero fundador lo conocía profundamente. Decisión inteligente, ¿verdad? Usa tus fortalezas, entrega código de calidad. El framework estaba bien, PERO el problema era su ecosistema.

La trampa del ecosistema

Angular es excelente y nuestro ingeniero podía construir cualquier cosa con él.

Pero "cualquier cosa" tomaba tiempo solo para comenzar. Configurar la implementación, autenticación y componentes básicos de UI significaba una configuración interminable antes de escribir una sola característica. Mientras depurábamos temas de Angular Material, los competidores pueden (y lo harán) usar Next.js + Vercel y ya estaban incorporando usuarios.

Solo compara eso con el camino de Next.js + Vercel: implementa una aplicación esqueleto con npx create-next-app el primer día, agrega autenticación Clerk y componentes shadcn/ui, entrega características reales el primer día. Mismo destino, viaje completamente diferente.

¿Por qué sucede esto?

La diferencia no está en la calidad del framework, sino en la optimización del ecosistema. Next.js/React está rodeado de startups respaldadas por capital de riesgo que construyen herramientas para otras startups:

• UI: shadcn/ui - copiar, pegar, enviar
• Auth: Clerk/Supabase - configurar en minutos
• Deploy: Vercel - git push equivale a producción
• Todo lo demás: Si las startups lo necesitan, alguien ha construido un servicio

El ecosistema de Angular sirve a empresas: potente, flexible, infinitamente personalizable. ¿Perfecto(?) para equipos de 50 y un veneno para equipos de 3.

\

Modelo Mental #4 - Construye el núcleo, alquila el contexto

Pero incluso con las herramientas adecuadas, hay una trampa final: la compulsión de construir cosas porque puedes, no porque debes. Esta trampa mata a equipos técnicamente fuertes y más startups de las que podemos imaginar: construir cosas que nadie pidió porque puedes, no porque debes.

Gastamos al menos un mes en total en características que nadie necesitaba. OAuth personalizado cuando Auth0 existía. Una cola de trabajos basada en Postgres cuando Redis + Celery existían. Terraform desde el primer día, cuando la consola funcionaba bien. Cada decisión se sentía productiva, pero cada una era un auto-sabotaje para enfrentar desafíos reales como hablar con clientes o hacer otro desarrollo de clientes.

El patrón es simple: si los clientes no te elegirán por ello, no lo construyas.

Mi regla de los $50

Si un SaaS cuesta menos de $50/mes, no puedes permitirte construirlo. Tu tiempo es demasiado caro.

Construir OAuth personalizado toma 1-2 semanas en total de mantenimiento y agregar diferentes proveedores de OAuth. A las tasas de quema de startups, eso es $5,000-$15,000 en tiempo de ingeniería, o en tiempo de oportunidad perdida. Auth0 es gratuito para hasta 25,000 usuarios activos, luego $35/mes. Podrías pagar Auth0 durante 35 años con lo que cuesta construirlo una vez.

Así que, esto no se trata de dinero sino de prioridades y costo de oportunidad.

Excepción

En mi opinión, construye solo si no puedes aprender sobre los usuarios sin ello.  Un ejemplo simple es cuando necesitas probar si los usuarios pagarán por informes generados por IA. Construye la versión más simple que demuestre la demanda. Y todo lo demás intenta colarse. Sí, omite la infraestructura, omite "hacerlo bien", omite las mejores prácticas que no entregan características, omite las pruebas. De nuevo, sé lo más perezoso posible al escribir código.

Lo que realmente uso

• Auth: Clerk (React-native, mejor DX) o Auth0 (enfocado en B2B, listo para empresas)
• Email: Resend (primero para desarrolladores) o SendGrid (probado en batalla)
• Analytics: PostHog (gratuito hasta escalar)
• Monitoring: Sentry (imbatible para errores)
• Hosting: Cloudflare o Vercel (si estás completamente en Next.js)

Estos no son respaldos sino mis propias elecciones optimizadas para la velocidad. Supongo que tu stack será diferente pero este principio no lo será.

\

\

Conclusión

Los LLMs han convertido la construcción en una mercancía. Cualquier junior con Claude puede crear ese sistema de autenticación personalizado del que estás tan orgulloso. Tu valor ya no está en lo que puedes construir, SINO en saber qué no construir.

El liderazgo es la capacidad de separar señales de ruido. La verdadera antigüedad significa tener la disciplina de ignorar el 90% de lo que sabes y entregar la solución de hoy, no la arquitectura de mañana.