La primera pregunta no es qué framework usar. Es si el proceso tiene una entrada estable, una vía de ejecución permitida, valor medible y un responsable cuando falla. Si faltan esas condiciones, el software solo ejecuta la incertidumbre más deprisa.
Motivos para rechazar o pausar un proyecto
- Depende de accesos no permitidos: saltarse autenticación, controles de acceso, límites o protecciones no es un requisito sólido.
- No existe una base válida para tratar los datos: recopilar información personal o confidencial sin finalidad, retención y acceso definidos crea un riesgo inaceptable.
- Los números no cuadran: mantenimiento, revisión humana, infraestructura e incidentes cuestan más que el ahorro.
- El objetivo cambia constantemente: una interfaz no documentada y sin alternativa convierte el producto en una urgencia permanente.
- Nadie gestiona las excepciones: los errores silenciosos producen registros malos, acciones duplicadas y daño al cliente.
La viabilidad técnica es solo un filtro
Divido el análisis en permiso, datos, estabilidad y retorno. El permiso incluye contratos, condiciones de la plataforma y normativa aplicable. Los datos incluyen procedencia, minimización, retención y borrado. La estabilidad cubre APIs soportadas, frecuencia de cambios y recuperación. El retorno compara el coste completo del ciclo de vida con el beneficio operativo.
Que un dato sea público no elimina las obligaciones. Hay que limitar la recogida a campos necesarios, respetar reglas y límites aplicables, identificar fuente y fecha, y conservar trazabilidad para correcciones o solicitudes de borrado. Amplío este criterio en scraping para ventas con datos públicos.
Rediseñar antes de decir que no
Una mala especificación inicial puede convertirse en un buen sistema. Se puede sustituir la imitación del navegador por una API oficial, pasar de automatización total a revisión asistida, procesar exportaciones del cliente en vez de pantallas privadas, ejecutar lotes programados en vez de sondeo continuo o exigir aprobación para acciones irreversibles.
La mejor arquitectura suele ser híbrida: reglas deterministas para casos previsibles, revisión humana para la ambigüedad y un registro de entrada, versión y resultado para cada decisión.
Controles mínimos de producción
Una automatización responsable necesita claves de idempotencia, reintentos limitados, rate limits, timeouts, botón de parada y auditoría por trabajo. Las credenciales deben estar en un gestor de secretos, los logs deben ocultar valores sensibles y los permisos deben seguir el mínimo privilegio. El panel debe medir éxito, rechazo, latencia y calidad, no solo si el proceso sigue vivo.
Si intervienen varios workers, hay que definir propiedad de la cola y recuperación. Los principios de diseño de colas para bots móviles sirven para casi cualquier automatización distribuida.
Errores comunes
- vender resultados garantizados en una plataforma externa
- tratar todo campo visible como apto para conservarse
- estimar solo el desarrollo inicial
- ocultar selectores inestables detrás de reintentos infinitos
- automatizar acciones irreversibles sin aprobación
- compartir credenciales entre clientes o workers
- registrar datos personales y tokens por comodidad
- lanzar gran volumen antes de medir un piloto representativo
Checklist para decidir
- documentar resultado de negocio y coste manual actual
- confirmar permisos, condiciones y obligaciones sobre datos
- preferir APIs soportadas y exportaciones del cliente
- listar dependencias externas y cambios probables
- calcular desarrollo, infraestructura, revisión y mantenimiento
- definir umbrales de calidad y responsable de excepciones
- añadir límites, timeouts, reintentos acotados y parada
- guardar fuente, fecha y trazabilidad de decisiones
- probar con poco volumen y acciones reversibles
- establecer una condición explícita para cancelar
Cuándo tiene sentido contratar a una persona técnica
Conviene incorporar un perfil senior cuando interactúan varias plataformas, datos sensibles, colas o acciones irreversibles; cuando un proveedor promete riesgo cero; o cuando nadie puede estimar mantenimiento. Un discovery técnico breve puede descubrir una dependencia fatal antes de firmar un gran contrato. Así planteo un proyecto técnico antes de programar.
Conclusión
Decir que no también es ingeniería. Rechazo automatizaciones basadas en accesos prohibidos, datos sin control, economía frágil o fallos invisibles. Si el núcleo útil puede ser conforme, trazable y estable, lo rediseño y pruebo su versión mínima. Consulta mis servicios técnicos o contacta conmigo.