Stack tecnológico. Para alguien que no viene del mundo del desarrollo, el término suena técnico y abstracto. Pero la decisión que representa es muy concreta: con qué herramientas se va a construir tu app, y esa elección tiene consecuencias que se van a sentir durante años.
No te cuento esto para asustarte. Te lo cuento para que sepas qué preguntas hacer.
¿Nativo o multiplataforma?
La primera gran decisión es si la app se va a construir de forma nativa —una versión en Swift para iOS, otra en Kotlin para Android— o con una tecnología multiplataforma que genera ambas versiones desde un solo código base.
Nativo da el mejor rendimiento y el acceso más completo a las funciones del dispositivo. También es más caro, porque es básicamente dos apps en vez de una.
Multiplataforma —con frameworks como Flutter, React Native o Ionic— permite construir una sola vez y publicar en ambas plataformas. Eso reduce costos y simplifica el mantenimiento. La brecha de rendimiento respecto al nativo se ha cerrado mucho, y para la mayoría de las apps de negocio es perfectamente suficiente.
¿Qué tecnología multiplataforma, entonces?
Depende de varios factores. Flutter tiene muy buen rendimiento y una comunidad muy activa. React Native es maduro, tiene un ecosistema enorme y funciona bien si tu equipo ya conoce JavaScript. Ionic es una opción sólida para equipos con experiencia web que quieren llegar rápido a móvil con Angular o React.
No hay una respuesta correcta universal. Hay una respuesta correcta para tu equipo, tu presupuesto y las necesidades específicas de tu app.
El backend también importa
La parte visible de la app —lo que el usuario toca y ve— necesita un lugar donde guardar datos, autenticar usuarios y ejecutar lógica de negocio. Eso es el backend.
Aquí también hay decisiones: servidor propio, servicios en la nube como Firebase o AWS, bases de datos relacionales o no relacionales. Cada elección afecta el costo, la escalabilidad y la velocidad de desarrollo.
Firebase, por ejemplo, es muy bueno para arrancar rápido con poco costo operativo, y escala bien en muchos casos. Pero tiene limitaciones cuando la lógica de negocio se complica. Saber eso de antemano te evita tener que migrar después.
La pregunta que más importa: ¿quién lo va a mantener?
Puedes elegir el stack más moderno y sofisticado del mercado. Si en seis meses el desarrollador que lo construyó ya no está disponible y nadie más lo conoce, tienes un problema.
El stack correcto no es solo el técnicamente superior. Es el que puede ser mantenido por las personas que van a estar disponibles para tu proyecto en el tiempo. Eso incluye considerar cuánta comunidad tiene la tecnología, qué tan fácil es encontrar desarrolladores que la conozcan, y qué tan activa está su evolución.
Un stack «aburrido» pero ampliamente conocido suele ser mejor decisión que uno «emocionante» y de nicho.
Cómo hacer la pregunta correcta
Cuando hables con un equipo de desarrollo, no preguntes solo «¿qué tecnología usan?». Pregunta por qué. Si la respuesta es clara, bien argumentada y conectada con las necesidades de tu proyecto específico, estás en buenas manos. Si la respuesta es «es lo que siempre usamos», sigue buscando.