Cómo elegimos la tecnología de un proyecto (y por qué no siempre es la misma)

Cuando alguien nos pregunta con qué tecnología trabajamos, la respuesta honesta incomoda un poco: depende del proyecto. No es una evasiva. Es que la pregunta correcta no es "¿cuál es la mejor herramienta?", sino "¿qué tiene que hacer bien este producto en particular?".

Casi todos los equipos de desarrollo tienen una herramienta favorita y la aplican a todo. Es cómodo: se avanza más rápido, no hay que aprender nada nuevo, el equipo ya conoce los problemas típicos. El costo de esa comodidad no lo paga quien desarrolla, lo paga quien contrata: termina con un producto construido alrededor de las preferencias de su proveedor en lugar de sus propias necesidades.

Para que esto no quede en abstracto, acá van tres proyectos nuestros con tres decisiones distintas.

Caso 1: dos audiencias opuestas sobre los mismos datos

Un sistema de comunicación para jardines infantiles. Dos grupos de personas lo usan y quieren cosas contrarias.

El personal del jardín registra la jornada: asistencia, alimentación, siestas, novedades. Trabajan desde un computador, con teclado, muchos campos y uso repetido durante todo el día. Necesitan velocidad de entrada de datos.

Las familias reciben esa misma información en el teléfono, en momentos sueltos del día, con un minuto de atención y una mano libre. Necesitan claridad inmediata.

Diseñar una sola interfaz para ambos habría dejado a los dos grupos a medias. Se resolvió como dos experiencias distintas sobre los mismos datos: el panel web y el administrador en AngularJS, la app móvil en Ionic.

¿Por qué Ionic? Porque comparte lenguaje y herramientas con el resto del sistema y entrega iOS y Android desde una sola base de código. Un equipo acotado mantiene las tres piezas sin duplicar el trabajo ni el conocimiento. La alternativa —dos apps nativas separadas— habría significado dos bases de código, dos ciclos de publicación y, en la práctica, que una de las dos plataformas quedara siempre atrasada.

Caso 2: cuando aparecer en buscadores no importa

Una plataforma de gestión y prevención de salud para pacientes y profesionales. Todo el producto vive detrás de una autenticación.

Eso cambia la decisión por completo. Si nadie va a llegar a esta plataforma desde una búsqueda —llegan porque tienen una cuenta— entonces todo el esfuerzo técnico que normalmente se invierte en que los buscadores puedan leer la página no aporta absolutamente nada.

Liberado ese requisito, el peso se fue entero a la experiencia de uso: fichas, seguimiento, estados que cambian constantemente, formularios largos. Se construyó en React, priorizando la fluidez de la interacción por sobre el renderizado en el servidor.

Es la decisión inversa a la del siguiente caso, y por eso mismo vale la pena verlas juntas.

Caso 3: un proyecto partido en dos mitades contrarias

Un sitio web corporativo con panel de administración. Acá las dos mitades del mismo proyecto tenían necesidades opuestas.

La parte pública vive de aparecer en buscadores. Si Google no la lee bien, el sitio no cumple su función comercial. Se construyó en Next.js con renderizado en servidor: el HTML llega ya armado, sin depender de que se ejecute JavaScript para que exista el contenido.

El panel de administración es privado, no necesita indexarse y sí necesita interactividad. Se construyó en React, igual que el caso anterior y por la misma razón.

Dos herramientas distintas dentro de un mismo proyecto, porque el problema era distinto en cada mitad.

Ese proyecto tuvo además otra decisión que vale la pena mencionar: el CMS se hizo a medida en lugar de usar uno genérico. El cliente buscaba modernizar sus sistemas con algo simple de operar. Un gestor de contenidos genérico trae cientos de opciones que nunca va a usar, más un ecosistema de extensiones que hay que mantener actualizado por seguridad. Un panel a medida hace exactamente lo que tiene que hacer: edita lo que hay que editar, sin aprender una herramienta entera para cambiar un párrafo.

Las preguntas que ordenan la decisión

Si están por empezar un proyecto, estas son las preguntas que en nuestra experiencia definen la decisión técnica. Ninguna es sobre tecnología:

¿La gente va a llegar desde buscadores? Si sí, el renderizado en servidor deja de ser opcional. Si el producto está detrás de una autenticación, ese requisito desaparece y se puede optimizar por otra cosa.

¿Hay app móvil de verdad? "Que se vea bien en el teléfono" y "que esté en las tiendas de aplicaciones" son problemas completamente distintos, con costos completamente distintos. Vale la pena tener claro cuál de los dos se necesita antes de pedir presupuestos.

¿Cuántas audiencias distintas hay? Un producto con dos tipos de usuario que quieren cosas opuestas casi nunca se resuelve bien con una sola interfaz.

¿Quién va a mantener esto en tres años? Es la pregunta que más se omite y la que más caro sale omitir. Una tecnología poco común puede ser técnicamente superior y dejarlos igualmente atrapados si después no encuentran a nadie que la conozca.

¿Qué parte del producto va a cambiar más seguido? Esa es la que hay que construir para ser modificada con facilidad. El resto puede ser más rígido sin que duela.

Lo que no cambia

Hay algo que sí es constante, independiente de la herramienta: el código tiene que poder ser leído y modificado por alguien que no lo escribió.

Un producto que solo puede mantener quien lo construyó no es un activo, es una dependencia. Por eso el repositorio, los accesos y la infraestructura quedan a nombre del cliente desde el primer día, y por eso escribimos pensando en la persona que va a abrir ese archivo dentro de dos años sin conocer nada del contexto.

La tecnología correcta es la que resuelve el problema real y deja al cliente en control de lo que pagó. Todo lo demás es preferencia.