Con el uso de la inteligencia artificial parece que todo es posible al momento de crear proyectos de software. Esto ha generado la sensación de que todo es fácil y rápido de implementar.
Sin embargo, la realidad es distinta: existen características que suenan simples, pero que en proyectos reales requieren mucho más trabajo, diseño y mantenimiento del que normalmente se imagina.
Como desarrollador, es importante reconocer este tipo de funcionalidades para no aceptar compromisos que pueden tomarte demasiado tiempo, encarecer el proyecto o incluso volverse imposibles de terminar correctamente.
Vamos a ver algunos ejemplos concretos.
1) Notificaciones masivas (Email / SMS)
En un proyecto real, no es simplemente “mandar un correo”.
Normalmente implica:
- Colas y workers (BullMQ, SQS, RabbitMQ, etc.) para no bloquear requests ni tumbar el backend.
- Reintentos, backoff y DLQ (mensajes que fallan y quedan en “cuarentena”).
- Rate limits del proveedor (Twilio, SendGrid, etc.) y throttling para evitar bloqueos.
- Idempotencia, para evitar envíos duplicados cuando hay reintentos.
- Plantillas, variables y tracking (entregado, abierto, rebotes, opt-out).
- Cumplimiento legal: CAN-SPAM, GDPR y, en SMS, opt-in/opt-out, horarios, país, etc.
- Observabilidad: logs, métricas, paneles de fallos y auditoría de quién disparó cada campaña.
👉 En otras palabras: es un mini-sistema dentro del sistema.
2) “Una app web por cliente” desplegada automáticamente
(Multi-tenant / Multi-environment)
Esto suele sonar como “solo clonamos y desplegamos”, pero en realidad obliga a tomar decisiones de arquitectura importantes.
Opción 1: Multi-tenant en una sola aplicación
Un solo deploy, datos separados por tenant_id.
Ventajas
- Más barato.
- Más simple de operar.
Desventajas
- La seguridad y el aislamiento requieren muchísimo cuidado
(RLS, permisos, riesgo de fugas de datos).
Opción 2: Un entorno por cliente
Infraestructura dedicada por cliente (DB, storage, dominios, etc.).
Ventajas
- Aislamiento fuerte.
- Fácil de vender como “dedicado”.
Desventajas
- Muy caro y complejo:
- Infrastructure as Code (Terraform / Pulumi).
- CI/CD.
- Provisioning automático.
- Gestión de secretos.
- Dominios y certificados SSL.
- Upgrades y migraciones.
- Monitoreo por cliente.
- Rollbacks.
- Costos operativos elevados.
Lo realmente difícil aparece después
- Provisioning automático (crear tenant + recursos + DNS + certificados).
- Migraciones de base de datos sin romper clientes existentes.
- Versionado (¿todos corren la misma versión o cada cliente puede quedarse atrás?).
- Soporte y observabilidad por tenant (logs, métricas, errores por cliente).
- Costos: un cliente pequeño puede salir carísimo si se le da infraestructura dedicada.
Cómo lo explico al cliente (sin pelear)
“Esto no es solo una feature de código.
Es una capacidad de plataforma que requiere backend, infraestructura, monitoreo y políticas de seguridad y reintento.
Se puede hacer, pero necesita diseño y fases.”
3) Búsqueda avanzada y filtros
“Que pueda buscar por todo”
Aquí entra:
- Indexación (base de datos, Elasticsearch, Meilisearch).
- Búsquedas parciales, acentos y relevancia.
- Filtros combinables.
- Performance con millones de registros.
- Paginación real (no offset lento).
👉 Es arquitectura de datos, no solo un input de búsqueda.
4) Integraciones con APIs externas desconocidas
Especialmente APIs de ERPs o sistemas de ventas locales que no siguen estándares o están incompletas.
“Solo conectarse con X API”
La realidad incluye:
- Errores y caídas del proveedor.
- Rate limits.
- Cambios de versión en la API.
- Webhooks y reintentos.
- Datos inconsistentes o incompletos.
👉 Integrar una API es mantener una relación constante con un tercero.
5) Feature flags / rollouts progresivos
“Actívalo solo para algunos usuarios”
Implica:
- Flags dinámicos (no hardcodeados).
- Evaluación por usuario, tenant o entorno.
- Rollouts por porcentaje.
- Kill switches.
- Cache y consistencia.
- UI de administración.
👉 Es control de versiones en producción.
6) Plugins / extensiones
“Que terceros puedan extender la app”
Requiere:
- APIs estables.
- Sandboxing y seguridad.
- Versionado.
- Compatibilidad hacia atrás.
- Documentación y SDKs.
- Manejo de errores externos.
👉 Aquí dejas de tener solo una app y pasas a tener una plataforma.
7) Reglas de negocio configurables
“Que el cliente pueda definir sus reglas”
Detrás hay:
- Un motor de reglas.
- DSL o una interfaz compleja.
- Validación.
- Evaluación eficiente.
- Debugging de reglas.
- Versionado de reglas.
👉 Básicamente estás creando un mini lenguaje dentro del sistema.
8) Aislamiento fuerte por cliente
“Que los datos estén 100% separados”
Incluye:
- Base de datos por tenant o schemas por tenant.
- Gestión de conexiones.
- Migraciones sincronizadas.
- Backups por cliente.
- Restauraciones selectivas.
- Costos y límites claros.
👉 Esto es infraestructura multi-cuenta, no solo backend.
9) Regla general que uso con clientes
“Si algo afecta a datos, seguridad, usuarios, infraestructura o dinero, nunca es simple.”
Este tipo de características marcan la diferencia entre una app pequeña y un sistema profesional en producción.
Saber identificarlas te ayuda a estimar mejor, negociar mejor y evitar proyectos que se vuelven una trampa técnica.