Como elegir la forma de construir

Como elegir un stack tecnologico para un MVP

Elige el stack que te permita cambiar de idea mas rapido, para el que puedas contratar y que alguien aun pueda mantener dentro de dos anos. La novedad no es una funcionalidad. Para la mayoria de los MVP la respuesta correcta es un stack aburrido y popular para el que puedas encontrar diez ingenieros, no el framework que fue tendencia el mes pasado.

Reservar una call de treinta minutos

Respuesta corta

Elige un stack tecnologico por velocidad de iteracion, bolsa de contratacion y mantenibilidad a largo plazo, no por novedad, y para la mayoria de los MVP eso significa un stack aburrido y popular.

Ideal para

  • Fundadores que necesitan entregar e iterar, no ganar un debate de arquitectura
  • Productos donde el riesgo es el encaje con el mercado, no la escala tecnica pura
  • Equipos que contrataran ingenieros para este stack mas adelante
  • MVP que deben seguir siendo baratos de cambiar durante los primeros 12 meses

No es para

  • Equipos que tratan el MVP como un experimento de framework para el curriculum
  • Productos con un requisito de escala extrema genuino y probado desde el dia uno
  • Fundadores que quieren reescribir antes de tener un solo usuario
// 01

Compara las opciones

La mayoria de las decisiones de stack para un MVP se reducen a un stack aburrido y popular frente a uno de vanguardia. Asi se comparan en lo que de verdad decide los resultados.

Que importa Stack aburrido y popular Stack de vanguardia
Bolsa de contratacion

Profunda. Puedes contratar o reemplazar ingenieros rapido.

Escasa. Compites por una bolsa pequena y pagas un sobreprecio.

Velocidad de iteracion al principio

Rapida. Librerias maduras, las respuestas ya existen.

Mas lenta. Topas con limites sin documentar y escribes mas tu mismo.

Mantenibilidad a largo plazo

Alta. El siguiente equipo lo reconoce.

Arriesgada. La herramienta puede abandonarse antes de que escales.

Coste y riesgo de contratacion

Menor. Habilidades comunes, incorporacion predecible.

Mayor. Habilidades de nicho, traspaso mas dificil.

Cuando gana de verdad

Casi cualquier MVP.

Cuando la nueva tecnologia resuelve un cuello de botella real y probado.

// 02

La postura de Wavect

El stack importa mucho menos de lo que creen los fundadores, y la forma equivocada en que importa es casi siempre la misma: una eleccion ingeniosa que hace caro cada cambio futuro. Hemos entregado mas de 75 productos, y los que avanzaron mas rapido corrian sobre herramientas aburridas y bien entendidas que cualquier ingeniero competente podia asumir.

Optimiza para tres cosas en este orden. Que tan rapido puedes cambiar de idea. Que tan facil es contratar para ello. Puede alguien mantenerlo despues de ti. La novedad falla en las tres. Un framework de vanguardia es una apuesta a que seras el equipo que lo escala, antes de haber probado que alguien quiere el producto.

Hay casos reales donde la nueva tecnologia se gana su sitio, sistemas on-chain, flujos de datos nativos de IA, escala en tiempo real genuina. Esos los construimos. Pero adoptas la pieza nueva porque resuelve un problema que de verdad tienes, no porque queda bien en un dossier de inversores. Todo lo que la rodea sigue siendo aburrido a proposito.

// 03

Coste, riesgo y plazos

Coste Discovery desde EUR 3,500Una fase corta de Discovery fija la decision del stack antes de gastar presupuesto de construccion en ello.
Riesgo Riesgo de reescrituraEl error caro es un stack que se te queda pequeno o para el que no puedes contratar, forzando una reescritura a mitad de la traccion.
Plazo De 0 a produccion en 6 semanasUn stack enfocado permite a un equipo pequeno llegar a produccion rapido, como con PromptID y LivLive.
// 04

Dónde suele salir mal

  • Elegir un framework porque es nuevo, y convertirte luego en su reportador de bugs no remunerado.
  • Elegir una tecnologia para la que nadie local se puede contratar, asi que el fundador sigue siendo la unica persona que puede cambiar algo.
  • Optimizar para una escala que aun no tienes y pagarla con una iteracion lenta hoy.
  • Apilar tres herramientas experimentales de forma que cada problema es un proyecto de investigacion.
  • Tratar el stack del MVP como permanente y sobreingenierizarlo desde el dia uno.
  • Dejar que un contratista elija lo que personalmente quiere aprender a continuacion.
// 05

La lista de verificación

Pasa el stack candidato por esto antes de comprometer una linea de codigo.

  • Puedes contratar al menos cinco ingenieros para este stack en tu mercado o en remoto?
  • Tiene librerias maduras y mantenidas para tus necesidades principales?
  • Puede un ingeniero nuevo ser productivo en el en una semana?
  • Es el bucle de iteracion, de cambio a ejecucion, lo bastante rapido para probar ideas a diario?
  • Si una herramienta clave se abandonara manana, podrias migrar de ella?
  • Resuelve alguna pieza novedosa un problema real que tienes hoy, no uno hipotetico?
  • Puede alguien distinto del autor original mantenerlo dentro de dos anos?
// 06

Cómo se ve esto en nuestro trabajo

Usamos stacks aburridos donde cuenta para entregar rapido y stacks novedosos donde se lo ganan cuando el producto lo exige.

// 07

Cuándo encaja, y cuándo no

// 01

Cuando Wavect es el encaje adecuado

  • Quieres un stack elegido para tu negocio, no para un portafolio.
  • Necesitas llegar a produccion en semanas y seguir iterando despues.
  • Tu producto tiene un requisito frontera genuino, IA u on-chain, que necesita experiencia real.
  • Quieres la opcion de contratar a tu propio equipo para el stack mas adelante.
// 02

Cuando no somos el encaje

  • Quieres que alguien valide una eleccion de framework para el curriculum.
  • Estas convencido de que necesitas una reescritura antes de tener usuarios.
  • Quieres el contratista mas barato posible sin importar la mantenibilidad.
  • Solo necesitas una demo desechable unica sin futuro en produccion.

Si quieres que la decision del stack se tome para tu negocio y no por una tendencia, una fase corta de Discovery lo resuelve rapido.

// 08
// 09

Preguntas frecuentes

No hay un unico mejor stack. El mejor stack para tu MVP es uno popular y bien soportado para el que puedas contratar y que puedas cambiar rapido. Para la mayoria de los productos eso significa un framework web mayoritario con una base de datos gestionada, no un framework novedoso. Reserva las elecciones exoticas para el unico lugar donde tu producto de verdad las necesita.
Menos de lo que temen los fundadores, y no de la forma que esperan. Un stack aburrido rara vez hunde un MVP. Un stack ingenioso que hace lento cada cambio y para el que nadie se puede contratar a menudo si. Asi que elige por velocidad de iteracion y contratacion, y la eleccion deja de importar en silencio.
No, no por defecto. Los frameworks nuevos te cuestan en documentacion escasa, una bolsa de contratacion pequena y el riesgo de que la herramienta se abandone. Adopta nueva tecnologia solo donde resuelve un problema real que tienes hoy. Manten todo lo que la rodea aburrido a proposito.
Cuando la nueva tecnologia elimina un cuello de botella real que has probado, por ejemplo liquidacion on-chain, flujos de datos nativos de IA o escala en tiempo real genuina. Esos los construimos. La pieza nueva se gana su sitio resolviendo un problema, no por parecer moderna.
A veces barato, a veces solo con una reescritura dolorosa. Por eso mismo la bolsa de contratacion y la mantenibilidad importan desde el principio. Un stack aburrido mantiene bajo el coste de cambiar, que es justo el sentido de un MVP.
Última revisión: porKevin Riedl wiki ↗
Reservar una call de treinta minutos