Cómo elegir el stack tecnológico de su primer SaaS: una guía honesta para fundadores

Pregunte a diez ingenieros qué stack tecnológico debería usar para su primer SaaS y obtendrá quince respuestas, tres de ellas pronunciadas con la certeza de una religión. La mayoría de esas respuestas son correctas, para quien las da. Ninguna trata de usted, de su margen de maniobra ni de los clientes que aún no ha firmado. Si es usted fundador y mira esta decisión sintiéndose ligeramente mal, esto es lo que nadie dice en voz alta: el stack importa mucho menos de lo que le han hecho creer, y las pocas formas en que sí importa no son las que la gente discute en internet.

He ayudado a no pocos fundadores primerizos a pasar de una presentación de diapositivas a un producto por el que personas reales pagan. Casi ninguno era técnico. Casi todos llegaron habiendo absorbido ya una cantidad aterradora de folclore sobre stacks: que necesitaban microservicios, que tal framework estaba "muerto", que elegir mal los condenaría. Y casi siempre el stack resultó ser una de las decisiones menos trascendentes que tomaron aquel año. Lo que mataba los proyectos era el alcance, la falta de responsabilidades claras y construir lo equivocado de forma hermosa. Nunca el framework.

Así que esta es la guía que doy a esos fundadores antes de escribir una sola línea de código. No le dirá que use un stack concreto, porque quien lo promete sin conocer su negocio le está vendiendo algo. En cambio, le dará una forma de pensar, de modo que, elija lo que elija, o proponga lo que proponga su equipo, pueda comprobarlo con sensatez como una persona adulta en lugar de asentir con nerviosismo.

Por qué esta decisión parece más difícil de lo que es

La pregunta del stack parece enorme porque es la primera elección de apariencia irreversible que toma, y viene envuelta en un idioma que no habla. Palabras como Postgres, React, Kubernetes, serverless se lanzan como si elegir entre ellas fuera como elegir los cimientos de un edificio: equivóquese y todo se derrumba.

Pero el software no es un edificio. Se parece mucho más a una cocina que puede reformar mientras sigue cocinando. Las empresas de éxito reescriben partes de su stack constantemente; la versión de un producto que encuentra sus primeros cien clientes casi nunca es la que sirve a sus primeros cien mil. El objetivo de su primer stack no es durar para siempre. Es permitirle construir, cambiar y lanzar lo bastante rápido como para averiguar si alguien quiere esto siquiera. Eso es un listón completamente distinto, y mucho más bajo, que "perfecto para la próxima década".

Una vez que acepta eso, la presión se reduce a la mitad. Ya no intenta predecir el futuro. Intenta hacer una apuesta razonable y reversible que le lleve a un producto que funciona y a usuarios que pagan. Y las apuestas razonables son algo que un fundador no técnico puede evaluar perfectamente.

Qué es en realidad un "stack", en términos sencillos

Antes de decidir nada, conviene desmitificar la palabra. Un stack tecnológico no es más que el conjunto de herramientas que se usan para construir y hacer funcionar su software. Puede pensarlo en cuatro capas, y no necesita entender ninguna en profundidad: solo necesita saber que existen.

• El frontend: lo que los usuarios ven y pulsan en su navegador o aplicación. Es la parte por la que todos lo juzgan.
• El backend: la lógica y las reglas que se ejecutan en un servidor: quién puede hacer qué, qué ocurre cuando lo hace, cómo se mueve el dinero.
• La base de datos: donde reside de verdad su información: usuarios, pedidos, suscripciones, todo lo que le devastaría perder.
• La infraestructura: los servidores y servicios que mantienen todo lo anterior en línea, con copias de seguridad y accesible a las 3 de la madrugada.

Cuando alguien dice "usaremos un stack moderno de JavaScript" o "Rails sobre Postgres", está describiendo elecciones en estas cuatro capas. Eso es todo. Todo SaaS, desde un proyecto paralelo de dos personas hasta una empresa cotizada, es alguna versión de estas cuatro cosas apiladas. Los grandilocuentes diagramas de arquitectura son justo esto, dibujados con más cajitas.

Lo que de verdad importa (y lo que no)

Aquí es donde se equivoca la mayoría de los consejos sobre stacks: optimizan cosas que no afectan a sus primeros dos años e ignoran las que sí. Permítame ser franco con ambas listas.

Lo que de verdad importa

Quién puede construirlo y mantenerlo. El factor más importante con diferencia no es la tecnología: son las personas. El mejor stack para usted es aquel en el que su equipo (o el socio que contrate) puede trabajar de verdad, con soltura, hoy. Un stack "perfecto" que solo entiende un raro especialista es peor elección que uno aburrido que cualquier desarrollador competente puede retomar. La capacidad de contratar y la continuidad ganan a la elegancia teórica cada vez.

Con qué rapidez puede cambiar las cosas. Al principio se equivocará constantemente respecto a su producto. La verdadera tarea del stack es abaratar el cambio de opinión. Las herramientas maduras y bien documentadas, con grandes comunidades, le permiten ir rápido porque las respuestas a sus problemas ya existen. Las herramientas de vanguardia le convierten en quien descubre los fallos.

Si puede contratar para ello. Elija algo oscuro y atará su futuro a quien lo construyó. Elija algo común y aburrido y siempre podrá encontrar al siguiente desarrollador, la siguiente agencia, la siguiente persona que lo retome. Aburrido es una virtud cuando su negocio depende de ello.

Lo que importa mucho menos de lo que dicen

El rendimiento puro y la "escala". Usted no tiene un problema de escala. Tiene un problema de nadie-lo-usa-todavía, que es el problema opuesto. Las arquitecturas diseñadas para millones de usuarios le ralentizarán cuando tenga once. Las famosas empresas que imita construyeron primero la versión sencilla y la reconstruyeron después, financiadas por el éxito. Usted también debería.

Qué framework concreto está "ganando" este año. Los frameworks suben y bajan en un ciclo de moda que casi nada tiene que ver con si construirán bien su SaaS de facturación. Cualquiera de las opciones populares y ampliamente usadas hará el trabajo. La moda es ruido; elija de en medio, lo aburrido y popular, y siga adelante.

Por qué la tecnología "aburrida" suele ganar

Hay una sabiduría callada entre los constructores experimentados que los recién llegados encuentran decepcionante: la mejor tecnología para un negocio nuevo suele ser la aburrida, probada y ligeramente pasada de moda. No porque las herramientas nuevas sean malas, sino porque cada elección que hace gasta un presupuesto limitado de novedad: la cantidad de cosas desconocidas, sin soporte y sorprendentes que su pequeño equipo puede manejar a la vez.

Gaste ese presupuesto en lo que hace especial a su negocio: el producto en sí, la intuición que solo usted tiene. No lo gaste en una base de datos de la que nadie ha oído hablar solo por sentirse moderno. Un stack aburrido y maduro significa que los problemas ya se han resuelto, la documentación existe, contratar es fácil y la herramienta no desaparecerá el año que viene cuando su único responsable pierda el interés. Lo aburrido le permite poner toda su ilusión donde rinde: en el cliente.

Aquí es también donde la IA cambia un poco el panorama, y no como sugiere el bombo. Los asistentes de programación con IA son muchísimo mejores con las tecnologías aburridas y populares, porque se entrenaron con una década de respuestas públicas sobre ellas. Elija un stack convencional y su equipo (y sus herramientas) obtienen ayuda más rápida gratis. Elija algo exótico y estará solo justo cuando menos puede permitírselo.

Un método de decisión que sí puede usar

Basta de principios. Aquí tiene una forma concreta de llegar a una decisión, tanto si elige usted mismo como si encarga el trabajo a un freelance o evalúa lo que propone una agencia. Nada de esto le exige escribir código, solo preguntar lo correcto y sopesar las respuestas.

1. 1
   Empiece por el equipo, no por la tecnología

   Pregunte: ¿quién construirá y mantendrá esto durante los próximos dos años? Lo que ya dominen bien es su opción por defecto más sólida. Cambiar de stack para perseguir una moda rara vez supera a la soltura.
2. 2
   Por defecto, lo convencional y probado

   Elija de en medio de cada capa, lo popular y bien documentado. Si no encuentra con rapidez tutoriales, ofertas de empleo y grandes comunidades para una herramienta, tómelo como una advertencia, no como una virtud.
3. 3
   Optimice para el cambio, no para la escala

   Prefiera la opción que abarate y agilice editar su producto. Se equivocará repetidamente sobre el producto: la tarea del stack es hacer que equivocarse sea sobrevivible.
4. 4
   Mantenga la arquitectura tan simple como pueda ser

   Una base de datos. Un backend. Un frontend. Nada de microservicios ni de ingeniosos sistemas distribuidos hasta que un problema real y medido le obligue. La simplicidad es el objetivo, no la concesión.
5. 5
   Anote por qué lo eligió

   Un párrafo: quién lo construye, qué eligió y qué tendría que cambiar para replantearlo. Esta nota le evita volver a litigar la decisión cada vez que alguien lee una opinión polémica.

Si no sigue nada más, siga los pasos uno y cuatro. Construya con las personas que tiene, sobre la arquitectura más simple que funcione. Esa combinación evita en silencio los dos modos de fallo que hunden a la mayoría de los primeros productos SaaS: que nadie pueda mantenerlo y un sistema demasiado complicado para su tamaño.

Preguntas para quien le proponga un stack

La mayoría de los fundadores no eligen el stack solos: un desarrollador, una agencia o un amigo CTO proponen uno. No necesita verificar la tecnología usted mismo. Necesita hacer un puñado de preguntas y escuchar cómo las responden. Las respuestas seguras y en lenguaje claro son buena señal. La jerga defensiva no lo es.

• "¿Por qué esto y no la aburrida opción popular?" — una buena respuesta gira en torno a sus necesidades concretas, no a lo que está de moda.
• "Si le atropellara un autobús, ¿con qué facilidad podría retomarlo otra persona?" — la respuesta revela lo raro y arriesgado de la elección.
• "¿Cuál es la versión más simple de esta arquitectura que sigue funcionando?" — observe si tira de la simplicidad o de la complejidad.
• "¿Qué tan fácil será contratar al siguiente desarrollador para esto?" — las habilidades comunes significan un mercado sano; las exóticas, dependencia.
• "¿Qué pasa cuando necesitemos cambiar una función central dentro de tres meses?" — quiere oír que el cambio es barato, no que se teme.

Trampas comunes que parecen buenas ideas

Unos cuantos patrones aparecen tan a menudo que vale la pena nombrarlos, porque cada uno parece responsable en el momento y le sale caro después.

Construir para una escala que no tiene. El impulso de "hacerlo bien" lleva a los fundadores a diseñar para millones de usuarios antes de tener diez. Cada pizca de esa anticipación al futuro es complejidad que paga ahora, en tiempo y dinero, para resolver un problema que quizá nunca llegue. Construya para los próximos cien usuarios. Rediseñe cuando el crecimiento lo haga necesario, y que sea un problema feliz.

Perseguir lo más nuevo. Un framework reluciente lanzado el mes pasado no tiene trayectoria, su documentación es escasa y su comunidad, minúscula. Pasará las noches depurando la herramienta en lugar de construir su producto. Deje que otros sean los adoptantes tempranos; usted tiene un negocio que lanzar.

Subcontratar a quien sea más barato, con lo que prefiera. La oferta más baja suele venir con un stack oscuro que solo conoce ese equipo. El día que se separen, su producto se convierte en una isla que nadie más puede alcanzar. Barato al principio, ruinoso después. Exija tecnología convencional y con mercado de contratación incluso cuando subcontrate; sobre todo cuando subcontrate.

Cuándo es de verdad el momento de replantear su stack

Nada de esto significa "no cambiar nunca". Significa cambiar por razones reales, medidas, no imaginadas. Sabrá que de verdad es el momento de hacer evolucionar su stack cuando aparezcan señales concretas, no cuando una entrada de blog le angustie.

Fíjese en el patrón: las razones reales tienen que ver con un dolor medido en su negocio real. Las falsas tienen que ver con la moda, la comparación y la inquietud. Cuando aparezca una señal real, cambie una pieza cada vez, no todo el stack en una reescritura heroica que paraliza todo durante seis meses. Evolución, no revolución.

Preguntas frecuentes