Criterio Técnico: El Arte de Elegir la Solución Correcta

El peso de una decisión tecnológica

Arrancamos un proyecto nuevo y las opciones aparecen enseguida: ¿usamos una base de datos relacional o una NoSQL? ¿Escribimos una expresión regular o integramos una API externa? ¿Mandamos todo a una VPS tradicional o usamos funciones edge?

Es fácil incorporar lo último que salió o repetir la herramienta que nos funcionó en el proyecto anterior. Si una tecnología es avanzada, podemos asumir que también será la mejor opción.

Pero no funciona así.

Las tecnologías no son buenas o malas por sí solas. Cada una resuelve determinados problemas, tiene un costo de adopción y exige cierto mantenimiento. Tener criterio técnico no consiste en sumar herramientas, sino en entender cuándo aportan valor y cuándo solamente agregan complejidad.

Evaluar antes de elegir

Cuando tenemos que tomar una decisión arquitectónica, ya sea al arrancar un proyecto o cuando el crecimiento empieza a presionar la infraestructura, conviene poner las alternativas en la balanza.

¿Qué problema resuelve cada una? ¿Cuánto cuesta implementarla? ¿Qué tendremos que mantener? ¿Cuáles son sus límites?

Veamos cómo aparece este criterio en algunas decisiones habituales del desarrollo web.

1. ¿Regex propia o API externa?

Supongamos que necesitamos validar direcciones o procesar datos geográficos. Una expresión regular puede parecer la opción más simple: no requiere llamadas de red, no depende de un tercero y responde de inmediato.

Pero una regex compleja puede volverse difícil de leer, frágil frente a nuevos formatos y peligrosa si está mal construida. Incluso puede abrir la puerta a problemas de rendimiento como los bloqueos por ReDoS.

Si el formato es acotado y conocemos bien sus reglas, una regex puede ser suficiente. Si necesitamos consultar datos postales, fiscales o geográficos que cambian fuera de nuestro código, una API especializada puede ser una opción más estable que seguir ampliando una regla difícil de mantener.

2. ¿Solución propia o servicio externo?

Construir desde cero un sistema de autenticación, pagos o envío de correos nos da control sobre la implementación. También significa hacernos cargo de cada actualización, parche de seguridad y cambio futuro.

Si la funcionalidad forma parte central del producto, desarrollar una solución propia puede tener sentido. Si se trata de una función común y existen servicios confiables que ya la resuelven, delegarla puede evitar que dediquemos tiempo a mantener una parte que no diferencia al proyecto.

La decisión no depende solamente de si podemos construirla. También importa si conviene sostenerla.

3. ¿VPS tradicional o Workers en el Edge?

Una VPS permite controlar el sistema operativo, la memoria, los discos y los procesos que se ejecutan en el servidor. Esa libertad puede ser necesaria cuando necesitamos conexiones persistentes, procesos largos o una tecnología específica.

A cambio, tenemos que configurar respaldos, aplicar actualizaciones, revisar la seguridad y ocuparnos de la disponibilidad. Si aparece un pico de tráfico, la escalabilidad también queda bajo nuestra responsabilidad.

Para funciones cortas y distribuidas, Workers puede simplificar la operación y acercar la ejecución a los usuarios. Pero también tiene límites de tiempo, compatibilidad y acceso a bases de datos.

No elegimos una opción porque sea más moderna o porque dé más control. La elegimos según el tipo de proceso que tenemos que ejecutar y el mantenimiento que estamos dispuestos a asumir.

4. ¿Tailwind CSS o CSS propio?

La forma en que organizamos los estilos también requiere una decisión.

Escribir todo el CSS desde cero nos da control, pero puede llevar más tiempo y exigir una nomenclatura consistente desde el comienzo. Tailwind permite construir una interfaz con rapidez y mantener criterios visuales comunes, aunque necesita una buena organización para no llenar el HTML de clases difíciles de seguir.

Podemos usar una base de utilidades para avanzar con el esqueleto visual y reservar el CSS propio para animaciones, componentes o detalles que realmente lo necesiten.

No se trata de elegir un ganador. Se trata de usar cada herramienta donde aporta más.

Cuando el proyecto empieza a crecer

Una decisión que funcionó bien para lanzar un proyecto puede convertirse en un límite cuando aumentan el tráfico, los datos o la cantidad de funcionalidades.

Ahí aparece una parte importante del criterio técnico: reconocer que una solución puede haber sido correcta en su momento y necesitar una revisión más adelante.

Si cada cambio exige un parche, aparecen excepciones constantemente o el mantenimiento empieza a costar más que el beneficio, conviene frenar antes de seguir agregando código.

Podemos revisar la documentación, comparar alternativas y comprobar si la solución actual todavía alcanza. Tal vez baste con ajustar una parte. Tal vez sea mejor delegar una función, cambiar de servicio o reorganizar la arquitectura.

Lo importante es no sostener una decisión solamente porque ya está escrita.

Elegir bien no significa encontrar una solución perfecta ni acertar para siempre. Significa entender qué ganamos, qué resignamos y cuánto cuesta mantenerlo.

Empezamos con lo necesario, observamos cómo responde el proyecto y revisamos el rumbo cuando cambian las necesidades. Ahí es donde el criterio técnico deja de ser una preferencia y se convierte en una herramienta para construir mejor.