Contratar una agencia de desarrollo web ya no es solo “hacer una web bonita”: en 2026 suele implicar integrar sistemas, cumplir requisitos de seguridad, optimizar rendimiento y sostener un ciclo continuo de mejoras. En un mercado donde el sitio web es producto, canal de ventas y plataforma de datos, elegir mal puede traducirse en retrasos, sobrecostes y deuda técnica que frena el negocio durante años.
Esta guía te ayuda a tomar una decisión informada: qué pedir, cómo comparar propuestas, qué preguntas hacer y qué señales de alarma detectar. El objetivo es que puedas alinear expectativas, evaluar capacidad real (no solo marketing) y firmar un acuerdo que proteja tu inversión y tu operación.
Key Takeaways
- Define el problema de negocio y el alcance antes de pedir presupuestos; sin eso, comparar agencias es casi imposible.
- Evalúa por evidencia: casos relevantes, proceso, equipo asignado y criterios de calidad (rendimiento, seguridad, SEO técnico).
- Exige un contrato con entregables verificables, gestión de cambios, propiedad intelectual y un plan de soporte post-lanzamiento.
- Evita errores típicos: comprar solo por precio, confundir “diseño” con “producto” y medir puntos sueltos en lugar del recorrido del cliente.
- Usa una matriz de selección y una prueba corta (discovery o sprint 0) para reducir el riesgo antes del build completo.
¿Qué necesitas realmente antes de contratar una agencia de desarrollo web?
Antes de pedir propuestas, define con precisión el resultado de negocio, los usuarios, el alcance funcional y las restricciones técnicas. En 40–60 minutos puedes pasar de “queremos una web nueva” a un brief accionable con objetivos, métricas y prioridades. Esto reduce incertidumbre, mejora la calidad de las ofertas y evita re-trabajos costosos.
H3: De objetivos de negocio a requisitos medibles
Empieza por el “para qué”: generación de leads, autoservicio, eCommerce, soporte, reclutamiento o marca. Traduce ese propósito en métricas operativas (por ejemplo, formularios válidos, tasa de conversión, tiempo de carga, reducción de tickets) sin inventar cifras objetivo si aún no tienes baseline. Define también el público: decisores B2B, candidatos, clientes recurrentes o partners.
H3: Alcance funcional mínimo (MVP) y backlog
La forma más segura de acotar es separar MVP de “nice to have”. Lista páginas, componentes y flujos críticos: navegación, buscador, formularios, checkout, área privada, multidioma, analítica y consentimiento. Convierte ideas en historias de usuario y prioriza por impacto/urgencia; así la agencia puede estimar con menos riesgo.
H3: Restricciones técnicas y de cumplimiento
Aclara desde el inicio restricciones de hosting, nube, SSO, accesibilidad, RGPD/cookies, requisitos de seguridad y herramientas corporativas. Si hay integraciones (CRM, ERP, PIM, pasarelas de pago), documenta sistemas, responsables y límites. Cuando el contexto es complejo, apóyate en recursos de Desarrollo web para alinear términos y expectativas con tu equipo interno.
¿Cómo elegir el tipo de agencia (boutique, full-service, especializada) según tu caso?
El mejor tipo de agencia depende del problema: una boutique puede ser excelente en velocidad y foco; una full-service aporta amplitud y coordinación; una especializada domina un stack o vertical. La clave es ajustar complejidad, riesgo y dependencia futura. Decide también si necesitas un socio de largo plazo o un equipo para un proyecto acotado.
H3: Boutique vs. full-service vs. especialistas
Una boutique suele ofrecer cercanía y seniority, pero puede tener capacidad limitada ante picos. Una full-service integra estrategia, diseño, desarrollo y marketing, aunque a veces diluye especialización. Un especialista (por ejemplo, en WordPress enterprise o headless) reduce riesgo técnico, pero puede requerir coordinación con otros proveedores.
H3: Proyectos “site” vs. “producto digital”
Si tu web es básicamente informativa, el énfasis es CMS, SEO técnico, rendimiento y gobernanza de contenidos. Si es un producto (portales, self-service, eCommerce avanzado), prioriza arquitectura, QA automatizado, observabilidad y un roadmap de releases. En ambos casos, exige claridad sobre mantenimiento y soporte.
H3: Señales de que necesitas una agencia con integración de sistemas
Si hay sincronización de catálogo, precios, stock, usuarios o consentimiento, estás en terreno de integración. En ese caso, revisa experiencia conectando plataformas y define responsabilidades de datos. Como lectura complementaria, consulta Eficiencia en la integración de sistemas: OpenCart y PrestaShop para entender riesgos típicos y patrones de conexión.
¿Qué debe incluir un brief y un RFP para recibir propuestas comparables?
Un brief sólido y un RFP breve pero específico son la diferencia entre propuestas “bonitas” y propuestas útiles. Deben describir contexto, objetivos, alcance, restricciones, criterios de éxito y cómo se tomará la decisión. Así fuerzas a que todas las agencias estimen sobre la misma base y reduces ambigüedad.
H3: Plantilla mínima de brief (lo que no puede faltar)
- Contexto del negocio y problema a resolver (dolor actual, impacto, stakeholders).
- Usuarios y recorridos críticos (top 3–5 journeys) con fricciones conocidas.
- Alcance: sitemap, funcionalidades, integraciones, idiomas, roles y permisos.
- Requisitos no funcionales: rendimiento, seguridad, accesibilidad, SEO técnico, analítica.
- Contenido: inventario, migración, gobernanza, flujos de aprobación.
- Limitaciones: stack preferido, hosting, plazos, dependencias internas.
H3: Criterios de evaluación y formato de respuesta
Pide que respondan en un formato estándar: enfoque, plan por fases, equipo propuesto, supuestos, entregables, riesgos y precio. Incluye una sección de “preguntas obligatorias” para comparar manzanas con manzanas. Define de antemano ponderaciones (por ejemplo, 40% capacidad, 30% enfoque, 20% coste, 10% cultura), aunque ajustes después.
H3: Cómo pedir evidencia sin convertir el RFP en burocracia
Solicita 2–3 casos relevantes con contexto, decisiones técnicas y resultados cualitativos, más una demo de un entregable (por ejemplo, un design system o un repositorio de ejemplo). Pide referencias de clientes, pero enfócate en preguntas concretas: gestión de cambios, calidad, cumplimiento de plazos y soporte post-lanzamiento.
¿Cómo evaluar el portafolio y la experiencia real (más allá del “look & feel”)?
Un portafolio bonito no garantiza buen delivery. Evalúa relevancia (casos similares), profundidad (decisiones y trade-offs) y sostenibilidad (mantenimiento, evolución). La agencia debe demostrar que entiende tu industria, tus restricciones y que puede operar con disciplina de ingeniería. Busca señales de proceso, no solo capturas de pantalla.
H3: Checklist de verificación técnica en demos
- Arquitectura: ¿explican por qué eligieron el stack y cómo escalará?
- Calidad: ¿hablan de pruebas (unitarias, integración, e2e) y QA?
- Operación: ¿mencionan despliegue, rollback, monitoreo y logs (observabilidad)?
- Seguridad: ¿prácticas de gestión de secretos, dependencias, revisiones y hardening?
- Rendimiento: ¿tienen enfoque en Core Web Vitals, caching y optimización de assets?
H3: Preguntas para separar “equipo A” de “equipo B”
Pide conocer al equipo que realmente trabajará en tu cuenta, no solo al equipo comercial. Pregunta quién toma decisiones de arquitectura, quién lidera UX, quién hace QA y quién gestiona el proyecto. Exige claridad sobre seniority, disponibilidad y rotación: la ejecución depende de personas, no de la marca.
H3: Ejemplo ilustrativo (hipotético): portafolio engañoso
Ejemplo hipotético: una empresa B2B elige agencia por un sitio visualmente espectacular. En el build, descubren que el equipo asignado no había hecho integraciones con CRM y que el rendimiento móvil cae por animaciones pesadas. Resultado: recortes de alcance y retraso del lanzamiento; el “look” era real, pero el delivery no estaba probado.
¿Qué proceso de trabajo debería tener una buena agencia (Discovery, UX, desarrollo, QA, lanzamiento)?
Una buena agencia opera con un proceso explícito y repetible: discovery para reducir incertidumbre, diseño centrado en usuario, desarrollo iterativo, QA sistemático y un lanzamiento controlado con medición. Debe haber artefactos claros por fase y criterios de aceptación. Si el proceso es vago, el riesgo lo asumes tú en forma de cambios y sobrecostes.
H3: Discovery o Sprint 0 (la fase que más ahorra dinero)
El discovery alinea objetivos, define alcance, valida riesgos e identifica dependencias. Entregables típicos: mapa de journeys, arquitectura de información, prototipos, backlog priorizado y estimación revisada. En servicios basados en proyectos, la precisión al estimar precios y alcances es un diferenciador de las compañías más exitosas, según McKinsey, porque evita ejecutar proyectos subvalorados y no rentables (fuente).
H3: Diseño UX/UI y sistema de diseño
No compres pantallas; compra decisiones. Un buen equipo de UX define estructura, jerarquía y flujos; UI traduce en componentes reutilizables y accesibles. Pide un sistema de diseño (tokens, componentes, estados, pautas) para mantener consistencia y acelerar futuras iteraciones. Si tu proyecto es intensivo en marca, revisa también recursos de Diseño para alinear criterios.
H3: QA, accesibilidad y definición de “hecho”
Define una “Definition of Done” que incluya pruebas, revisión de seguridad, performance y accesibilidad. Exige entornos separados (dev/staging/prod), pruebas en navegadores y dispositivos relevantes, y un plan de regresión. Para proyectos con foco móvil, es útil profundizar en compatibilidad y responsive; como referencia práctica, consulta Compatibilidad móvil en AngularJS y Bootstrap: consejos clave.
¿Cómo comparar presupuestos y modelos de precio sin caer en trampas?
Comparar presupuestos exige entender qué estás comprando: alcance, nivel de calidad, riesgo asumido y capacidad del equipo. No existe “precio correcto” sin supuestos explícitos. La forma segura es pedir desglose por fases, entregables y roles, y revisar qué queda fuera. Un presupuesto barato puede ser caro si no incluye QA, soporte o gestión del cambio.
H3: Modelos comunes (fijo, time & materials, retainer)
- Precio fijo: útil si el alcance está muy definido; riesgo alto si hay incertidumbre (se compensa con buffers o recortes).
- Time & Materials: flexible para iterar; requiere buena gobernanza y priorización para no “derivar”.
- Retainer: ideal para mejora continua; define capacidad mensual, SLAs y backlog vivo.
- Híbrido: discovery fijo + build T&M con techo presupuestario y checkpoints.
H3: Qué revisar en el desglose (y qué suele faltar)
Revisa si incluyen: gestión de proyecto, QA, accesibilidad, SEO técnico, analítica, seguridad, migración de contenidos, licencias, y soporte post-lanzamiento. Pide que declaren supuestos (número de plantillas, idiomas, integraciones, rondas de revisión). Cuando una agencia estima con precisión alcance y precio, reduce el riesgo de proyectos subvalorados y tensiones posteriores, una idea alineada con lo que destaca McKinsey sobre servicios por proyectos (fuente).
H3: Tabla de comparación de propuestas (plantilla práctica)
Usa una tabla para puntuar de forma consistente. Columnas recomendadas: comprensión del problema, enfoque por fases, equipo y seniority, calidad/QA, seguridad, rendimiento, integraciones, gobernanza de contenidos, soporte, y coste total. Añade una columna de “riesgos y mitigaciones” para capturar lo que cada agencia ve (o no ve).
¿Qué preguntas hacer en entrevistas para detectar riesgos y madurez?
Las entrevistas deben validar cómo piensan y cómo trabajan bajo presión: gestión de cambios, manejo de dependencias, transparencia y calidad. Pregunta por ejemplos concretos de problemas y cómo los resolvieron. Una agencia madura habla de límites, riesgos y trade-offs sin ponerse defensiva. Evita conversaciones solo de “features” sin hablar de operación.
H3: Preguntas sobre delivery y gobernanza
- ¿Cómo gestionan cambios de alcance y quién aprueba el impacto en coste/plazo?
- ¿Qué cadencia de entregas proponen y cómo demuestran progreso (demos, releases)?
- ¿Cómo documentan decisiones (ADR, guías, handover) para evitar dependencia?
- ¿Qué herramientas usan para seguimiento (Jira, Linear, GitHub) y quién tiene acceso?
H3: Preguntas sobre calidad, seguridad y cumplimiento
Pregunta cómo gestionan vulnerabilidades en dependencias, revisiones de código, control de accesos y secretos. Pide su enfoque de pruebas automatizadas y manuales, y cómo validan accesibilidad. Solicita un plan de respuesta ante incidentes y de parches. Una respuesta vaga (“lo vemos al final”) suele anticipar problemas.
H3: Preguntas sobre equipo y continuidad
Valida estabilidad del equipo y continuidad: ¿qué pasa si el tech lead se va? ¿Cómo aseguran transferencia de conocimiento? Pregunta por su política de rotación y por el plan de reemplazo. Si tu organización necesita contratar o complementar perfiles, puede ayudarte revisar referencias de mercado y roles en Open IT vacancies para calibrar disponibilidad y expectativas.
Factores clave: UX, SEO, rendimiento, seguridad y analítica (¿qué exigir por contrato?)
Los factores clave deben convertirse en requisitos verificables: UX basada en recorridos, SEO técnico desde el inicio, rendimiento medible, seguridad por diseño y analítica accionable. Si quedan como “buenas intenciones”, se sacrifican al final del proyecto. Lo más efectivo es definir entregables, pruebas y criterios de aceptación para cada dimensión.
H3: UX centrada en recorridos (no solo pantallas)
Exige que la agencia diseñe y mida journeys completos: descubrimiento, consideración, conversión, onboarding y soporte. McKinsey señala que medir recorridos de clientes en lugar de puntos de contacto individuales tiene un poder predictivo mucho más alto sobre la satisfacción general (fuente). Tradúcelo a tu proyecto: define 3–5 journeys y sus eventos clave.
H3: SEO técnico y contenido: lo que suele romperse en migraciones
Pide un plan de migración con inventario, mapeo de URLs, redirecciones 301, canónicas, sitemap, robots y validación en staging. Alinea estructura de contenidos y taxonomías con gobernanza editorial. Si vienes de un CMS legacy, revisa enfoques de migración para evitar pérdidas; por ejemplo, Estrategias para la migración de Joomla a WordPress sin complicaciones aporta un marco útil.
H3: Rendimiento, seguridad y analítica como “no negociables”
- Rendimiento: presupuestos de performance, optimización de imágenes, caching, SSR/SSG cuando aplique, y pruebas antes del go-live.
- Seguridad: hardening, control de permisos, revisión de dependencias, CSP cuando proceda, y plan de parches.
- Analítica: plan de medición (eventos), etiquetado consistente, consent mode/cookies, y dashboards para negocio.
- Accesibilidad: criterios (por ejemplo WCAG) y auditorías internas/externas según criticidad.
Errores comunes al contratar una agencia (y cómo evitarlos)
Los errores más caros suelen ser de enfoque, no de tecnología: elegir por afinidad, por precio o por promesas vagas. También es común subestimar la gestión del cambio y la necesidad de capacidades internas para operar lo construido. Evitarlos requiere criterios explícitos, evidencia y un contrato que haga visibles los riesgos.
H3: Error 1 — Elegir “a tu imagen y semejanza”
Un sesgo típico de contratación es buscar proveedores que reflejen tus propias habilidades y antecedentes, lo que puede limitar diversidad de enfoques e innovación. Harvard Business Review lo describe para nuevos directivos y aplica también a selección de partners: si solo eliges a quien “piensa como nosotros”, pierdes perspectivas valiosas (fuente). Mitigación: usa una matriz de criterios y un panel evaluador diverso.
H3: Error 2 — Comprar por precio y no por riesgo
Un precio bajo puede esconder supuestos: menos QA, menos seniority, sin soporte, o estimaciones optimistas. Lo correcto es comparar coste total de propiedad: build + soporte + evolución. Pide que detallen qué riesgos asumen y cómo los mitigan; si no pueden, probablemente el riesgo se trasladará a tu equipo.
H3: Error 3 — Medir entregables sueltos y no el resultado del journey
Es fácil obsesionarse con “la home” o “el nuevo menú” y perder de vista el recorrido completo. En transformaciones de experiencia, McKinsey resalta que los journeys predicen mejor la satisfacción que puntos de contacto aislados (fuente). Evítalo definiendo journeys, eventos y criterios de éxito desde discovery.
Qué debe incluir el contrato: alcance, cambios, propiedad intelectual, SLAs y garantías
Un buen contrato convierte expectativas en compromisos verificables: entregables, criterios de aceptación, gestión del cambio, propiedad intelectual y soporte. También define cómo se resuelven conflictos y cómo se protege la continuidad del negocio. Si el contrato es ambiguo, la ejecución dependerá de interpretaciones, y eso suele terminar en fricción.
H3: Cláusulas esenciales (lista práctica)
- Alcance y entregables por fase: documentación, diseños, código, infraestructura, pruebas, handover.
- Criterios de aceptación: definición de “hecho”, pruebas mínimas, navegadores/dispositivos, accesibilidad.
- Gestión de cambios: proceso, tiempos de respuesta, cómo se estima impacto y cómo se aprueba.
- Propiedad intelectual: titularidad del código, diseños, contenidos; licencias de terceros y repositorios.
- Confidencialidad y protección de datos: roles, subprocesadores y obligaciones.
- Soporte post-lanzamiento: SLA, tiempos de respuesta, mantenimiento correctivo/evolutivo.
H3: Entregables de transferencia (para no quedar cautivo)
Incluye en contrato un paquete de handover: acceso a repositorios, documentación de arquitectura, runbooks, credenciales gestionadas por tu organización, y guía de despliegue. Asegura que el proyecto pueda operar sin la agencia si es necesario. Esto reduce el vendor lock-in y mejora tu posición de negociación en el tiempo.
H3: Garantías realistas y cómo definir “bug” vs. “cambio”
Define un periodo de garantía para defectos y un proceso de triage. Aclara qué es bug (incumple requisitos acordados) y qué es cambio (nuevo requisito o ajuste fuera de aceptación). Documentar esto evita discusiones y acelera correcciones. Si hay integraciones, especifica ambientes, datos de prueba y responsabilidades de cada parte.
¿Cómo gestionar el proyecto con una agencia para maximizar resultados?
La contratación no termina con la firma: la gobernanza diaria define el éxito. Establece cadencias, roles, toma de decisiones y un backlog vivo. Trabaja por incrementos entregables y valida con usuarios y datos. Una relación sana combina transparencia, disciplina y aprendizaje continuo, no microgestión ni “caja negra”.
H3: RACI y responsabilidades (cliente vs. agencia)
Define quién es responsable, quién aprueba y quién aporta información. El cliente suele ser dueño de prioridades, contenidos, aprobaciones y compliance; la agencia, de ejecución técnica, calidad y propuesta de soluciones. Si no hay dueño interno de producto, el backlog se vuelve reactivo y el proyecto pierde foco.
H3: Cadencia de comunicación y artefactos
- Weekly: demo de avance + revisión de riesgos y dependencias.
- Quincenal: planificación de sprint y revisión de backlog.
- Mensual: revisión ejecutiva (objetivos, presupuesto, decisiones pendientes).
- Artefactos: roadmap, backlog priorizado, actas de decisiones, tablero de issues, reporte de calidad.
H3: Agilidad “de verdad” y equipos en red
Si la agencia se declara ágil, valida que lo sea en estructura y práctica. McKinsey describe que organizaciones ágiles mantienen estabilidad en niveles altos, pero reemplazan gran parte de la jerarquía tradicional con una red flexible y escalable de equipos (fuente). Tradúcelo a tu proyecto: equipos pequeños, decisiones rápidas y feedback frecuente.
Ejemplos prácticos: 5 escenarios típicos y cómo decidir
Los escenarios reales suelen combinar restricciones técnicas, presión de plazos y múltiples stakeholders. Estos ejemplos son ilustrativos (hipotéticos) para ayudarte a reconocer patrones y tomar decisiones. Úsalos como guía para formular preguntas y ajustar tu RFP. El valor está en identificar el “riesgo dominante” de tu caso.
H3: Escenario 1 (hipotético) — Rebranding con migración SEO
Empresa SaaS con rebranding y cambio de IA/estructura de contenidos. Decisión clave: elegir una agencia fuerte en contenido + SEO técnico + migraciones, no solo en visual. Requisito: plan de redirecciones, mapeo, validación en staging y checklist de indexación. Riesgo: pérdida de tráfico por cambios de URL y canónicas mal gestionadas.
H3: Escenario 2 (hipotético) — Portal de clientes con SSO e integraciones
Fabricante industrial que necesita portal con documentación, pedidos y tickets; integra SSO, CRM y ERP. Decisión clave: priorizar arquitectura, seguridad y pruebas de integración. Pide evidencia de integraciones similares y un plan de ambientes/datos. Riesgo: dependencias internas que bloquean; mitígalo con discovery y acuerdos de responsabilidad.
H3: Escenario 3 (hipotético) — eCommerce con múltiples plataformas
Retailer que conecta catálogo y pedidos entre plataformas. Decisión clave: agencia con experiencia en integración y operación, no solo en front-end. Pide un diseño de flujos de datos, manejo de errores y reconciliación. Complementa tu análisis con el artículo de integración ya citado para reconocer puntos de fallo recurrentes.
H3: Escenario 4 (hipotético) — CMS personalizado para procesos internos
Grupo empresarial con gobernanza compleja: múltiples aprobadores, compliance y plantillas por unidad. Decisión clave: evaluar si conviene CMS estándar con extensiones o CMS personalizado. Si el caso requiere personalización fuerte, revisa CMS personalizado: cómo implementarlo para gestión de contenido para alinear expectativas sobre esfuerzo y mantenimiento.
H3: Escenario 5 (hipotético) — Modernización por fases sin parar el negocio
Empresa con web legacy crítica que no puede “apagarse”. Decisión clave: estrategia de migración incremental (por secciones), con feature flags y medición. Pide un plan de releases, rollback y monitoreo. Riesgo: convivir con dos sistemas; mitígalo con arquitectura clara y una hoja de ruta de desmantelamiento del legacy.
Cómo verificar capacidades del equipo: talento, seniority y mercado
Verificar capacidad no es solo revisar CVs: es validar cómo resuelven problemas, cómo documentan, cómo prueban y cómo operan en producción. Además, conviene entender el mercado de talento para detectar propuestas irreales (por ejemplo, “equipo senior” a precio de junior). La transparencia sobre roles y disponibilidad es una señal de madurez.
H3: Señales de seniority (observables)
- Explican trade-offs y riesgos sin prometer “todo se puede” sin coste.
- Proponen instrumentos de control: pruebas, CI/CD, revisiones, métricas.
- Hablan de operación: monitoreo, incidentes, mantenimiento y deuda técnica.
- Documentan y dejan el proyecto transferible (no dependen de héroes).
H3: Cómo calibrar expectativas de roles y costes sin inventar números
Si necesitas una referencia externa para entender perfiles y demanda, usa fuentes de mercado en lugar de suposiciones internas. Por ejemplo, puedes revisar IT salary data by city and role para contextualizar rangos por ciudad/rol y detectar incoherencias en propuestas. No es para “regatear”, sino para validar viabilidad de staffing.
H3: Dónde encontrar y prefiltrar agencias con señales verificables
Para ampliar el embudo sin perder calidad, empieza por directorios con empresas verificadas y referencias. Un punto de partida práctico es el Verified IT company catalog, donde puedes explorar proveedores y luego validar fit con tu RFP. Aun así, la selección final debe basarse en evidencia, no en listados.
Checklist accionable: próximos pasos para contratar con confianza
Si quieres pasar de lectura a acción, sigue este checklist en orden. Está diseñado para reducir incertidumbre primero (discovery), luego comparar propuestas de forma justa, y finalmente cerrar un contrato operativo. Ajusta la profundidad según el tamaño del proyecto, pero no saltes los pasos de definición y verificación.
- Define objetivos de negocio, usuarios y 3–5 journeys; documenta fricciones actuales y dependencias.
- Crea un brief/RFP de 2–5 páginas con alcance MVP, requisitos no funcionales y criterios de evaluación.
- Preselecciona 4–6 agencias y solicita propuestas en formato estándar (mismas preguntas para todas).
- Haz entrevistas con el equipo asignado (tech lead, PM, UX, QA) y revisa un caso similar en profundidad.
- Pide un discovery o sprint 0 como “prueba controlada” antes del build completo cuando haya incertidumbre.
- Compara con matriz: capacidad, enfoque, riesgos, soporte, y coste total (no solo el presupuesto inicial).
- Negocia contrato: entregables, criterios de aceptación, gestión de cambios, propiedad intelectual, SLAs y handover.
- Planifica lanzamiento: migración, QA final, monitoreo, plan de rollback y medición de eventos/journeys.
- Define operación post-lanzamiento: backlog de mejoras, cadencia, mantenimiento, parches y roadmap trimestral.
