Cómo elegir la tecnología de tu software (sin ser técnico)
El desarrollador pregunta "¿React o Vue? ¿nativo o Flutter?" y sientes que te hacen decidir a ciegas algo que no entiendes. Respira: como dueño del negocio no te toca elegir el framework — te toca elegir los criterios y hacer las preguntas correctas. Esta guía te da exactamente eso, incluida la trampa más cara: el framework propietario.
6 de septiembre de 20256 min de lecturaEn este artículo
En algún punto del proyecto llega la pregunta que temías: "¿lo hacemos en React o en Vue? ¿app nativa o Flutter? ¿qué base de datos prefieres?" — y sientes que te hacen decidir a ciegas algo que no entiendes, con la sospecha de que la respuesta equivocada te costará caro dentro de dos años.
Respira: como dueño del negocio no te toca elegir el framework — te toca elegir los criterios. Las decisiones técnicas finas son del equipo técnico; las tuyas son de otro nivel: que la tecnología tenga gente que la mantenga, que no te deje rehén de nadie, y que el costo de vivir con ella sea razonable. Esta guía te da esos criterios, las preguntas exactas para tu proveedor y las banderas rojas que sí puedes detectar sin saber programar.
La verdad incómoda: "la mejor tecnología" no existe
Para el software que un negocio típico necesita — webs, tiendas, apps de gestión, sistemas de reservas — cualquier tecnología mainstream moderna puede construirlo bien. Los proyectos no fracasan porque eligieron el framework B en vez del A: fracasan por requisitos difusos, proveedores que desaparecen y mantenimiento impagable. La consecuencia práctica es liberadora: deja de buscar la tecnología perfecta y empieza a filtrar por los criterios que sí separan proyectos vivos de proyectos huérfanos.
Los cuatro criterios que sí importan al negocio
- Talento disponible: ¿cuántos desarrolladores en tu mercado dominan esta tecnología? Una tecnología popular significa poder cambiar de proveedor, contratar y cotizar en competencia — una exótica significa depender de quien la trajo.
- Madurez y comunidad: años en producción, documentación abundante, actualizaciones regulares — lo establecido y aburrido envejece mejor que lo brillante y nuevo.
- Costo total a 5 años: no el presupuesto del desarrollo — el de vivir con él: hosting, licencias, actualizaciones, y sobre todo las horas de quien lo mantenga.
- Adecuación al problema: la tecnología de moda para apps masivas puede ser un tanque para matar tu mosca — el sistema interno de 20 usuarios y la app de consumo masivo no merecen el mismo arsenal.
Las preguntas para tu proveedor (y cómo leer las respuestas)
| Pregunta | Respuesta que tranquiliza | Bandera roja |
|---|---|---|
| ¿Por qué esta tecnología para MI caso? | Razones ligadas a tu proyecto: tamaño, presupuesto, mantenimiento | "Es la que usamos siempre" o jerga sin traducción |
| ¿Quién más podría mantener esto? | "Cualquier desarrollador de X — hay miles" | "Nosotros, es nuestra especialidad" (eso es un candado, no una ventaja) |
| Si ustedes desaparecen mañana, ¿qué hago? | Código en tu repositorio, accesos tuyos, documentación entregada | Incomodidad, evasivas o "eso no va a pasar" |
| ¿Esto es tecnología estándar o algo propio de ustedes? | Estándar del mercado, de código abierto o ampliamente adoptada | "Nuestro framework/CMS propio" — ver el recuadro siguiente |
La trampa más cara: el framework propietario
Las decisiones que sí te tocan a ti
Hay un piso de decisiones que son de negocio, no de sintaxis, y esas sí debes tomarlas tú con información: ¿web app o app instalable? — frecuencia de uso y necesidad de tienda deciden, como desarrolla la guía de app nativa, híbrida o web app; ¿no-code o código? — etapa del negocio y propiedad deciden, según la guía de no-code vs código a medida; ¿dónde vive y de quién es? — exige que el código esté en un repositorio de tu propiedad, los accesos (dominio, hosting, base de datos) a tu nombre, y los datos exportables. Ninguna de las tres exige saber programar; las tres definen quién manda en tu software.
Las señales de que eligieron bien
Una buena elección tecnológica se reconoce por síntomas visibles desde fuera: es aburrida (tecnología establecida que no sale en titulares — el software de negocio premia lo probado), te la pudieron explicar (quien entiende de verdad puede traducir a cristiano; la jerga impenetrable suele tapar inseguridad), hay repuestos (más gente y más proveedores que podrían tomarla mañana), y el presupuesto incluye el después — mantenimiento y evolución con números, no con promesas. El marco completo del proyecto — proveedor, entregables, contrato — está en la guía de crear tu app.
Preguntas frecuentes
¿Debería aprender a programar para tomar estas decisiones?
No — igual que no estudias mecánica para comprar un auto: aprendes qué preguntar y qué respuestas desconfiar. Lo que sí paga enormemente es entender los conceptos de negocio del software (qué es un repositorio, qué es hosting, qué significa API, la diferencia entre alquilar y poseer) — con diez conceptos bien entendidos pasas de rehén a interlocutor, y esta guía más la del pilar te dan la mayoría.
¿Importa que la tecnología esté "de moda"?
Menos de lo que crees, y a veces al revés: la moda técnica cambia cada dos años, y lo que hoy brilla puede quedar a medio mantener mañana. Lo que la moda sí indica es disponibilidad de talento a futuro — por eso el punto dulce es la tecnología mainstream consolidada: lo bastante popular para que sobren desarrolladores, lo bastante madura para que nadie la abandone pronto. Desconfía por igual del "es lo último" y del "esto se usa desde hace 20 años y no lo cambiamos".
¿Se puede cambiar de tecnología más adelante si nos equivocamos?
Se puede, pero es una reconstrucción, no una mudanza: migrar de tecnología significa reescribir buena parte del sistema. Por eso las decisiones de esta guía pesan más ANTES de construir. La buena noticia: si elegiste mainstream y el código es tuyo, el cambio es un proyecto caro pero posible con cualquier proveedor; si caíste en el framework propietario, es empezar de cero — otra razón para la prueba del "¿y si nos peleamos?".
Dos proveedores me proponen stacks distintos, ¿cómo comparo?
No compares los stacks — compara las respuestas a las cuatro preguntas de la tabla: por qué ese stack para tu caso, quién más puede mantenerlo, qué pasa si desaparecen, y si es estándar. Suma los números completos (desarrollo + 5 años de mantenimiento y hosting) y el detalle de qué entregan (¿código en tu repositorio? ¿accesos a tu nombre?). Entre dos tecnologías mainstream, la diferencia real casi nunca está en el stack: está en el proveedor — elige al que respondió mejor, no al del framework con mejor marketing.