Un solo desarrollador: por qué mi stack no cambia

Porque cada dependencia es una deuda con tu yo futuro, y cuando el único mantenedor eres tú, no hay a quién pasarle la factura. Vanilla JavaScript, Supabase y Netlify, desde 2024. Es postura declarada, no límite técnico.

¿Qué cambia cuando el equipo es una persona?

Desaparece el costo de coordinación —convenciones, inducciones, revisiones cruzadas— y queda concentrado todo el costo de mantenimiento sobre una persona. La pregunta de tecnología deja de ser «¿cuál hace más?» y se convierte en «¿cuál sigue funcionando el día que el único que la entiende está ocupado, enfermo o durmiendo?». En una operación que corre 24/7, esa pregunta no es retórica.

¿Por qué la plataforma es mi framework?

Escribo JavaScript vanilla con ES Modules: el navegador es la única dependencia grande, y la web tiene un contrato que ningún framework ofrece — lo que ya funciona, no se rompe. Sin migraciones mayores en el horizonte, sin aviso de seguridad de un tercero a las tres de la mañana, sin volver a aprender lo que ya sabía cuando cambia la moda. Cada año que pasa, la apuesta por la plataforma se paga sola.

¿Y el backend y el hospedaje?

Supabase y Netlify son servicios administrados: base de datos, autenticación, hospedaje y despliegue sin que yo opere ninguno de esos servidores. Es el equivalente tecnológico del equipo que no tengo, sin contratarlo. La regla de elección es la misma del punto anterior: piezas que se mantienen solas y que una sola persona puede entender de punta a punta.

¿Qué pierdo con esta postura?

Lo declaro porque el límite es parte del dato. Pierdo ciertos filtros de contratación que buscan palabras de moda antes que criterio. Pierdo la comodidad de algunas interfaces de complejidad extrema, donde un framework ahorra trabajo de verdad. Y pierdo la posibilidad de culpar al proveedor cuando algo sale mal. Peso conocido, elegido a propósito.

¿Cuándo sí cambiaría?

Con un criterio, no con una fecha: cuando una restricción real del problema lo exija, no la moda. Si el problema requiere lo que la plataforma no da, o si el equipo crece y el costo de coordinación regresa, se cambia y se escribe por qué. Un stack que no cambia no es terquedad: es una decisión que sigue ganando sus propias pruebas — una en producción real cada día.