El glosario de Wavect

Un CTPO carga con las responsabilidades de un CTO y un CPO en un solo cuello. Es dueño de qué se construye, cómo se construye y si eso resuelve el problema del cliente. La figura existe porque las startups pre-PMF no pueden permitirse dos hires senior ni la política de un CTO y un CPO discutiendo prioridades cada martes.

En un engagement con Wavect el CTPO suele ser fraccional. Un operador entra en el cap table o en el contrato, lleva descubrimiento de producto y arquitectura técnica en la misma semana, y traspasa a un split permanente (CTO + CPO) cuando los ingresos y la estructura justifican ambos roles.

El riesgo: una sola persona se vuelve punto único de fallo. La mitigación: un CTPO que sabe cuándo dejar de serlo y reclutar a su sustituto. Quien no esté dispuesto a despedirse a sí mismo es el CTPO equivocado.

Un CTO es dueño de tres cosas: sobre qué construyes, qué tan fiable entregas y si la arquitectura elegida hace dos años sigue sirviendo al negocio hoy. No es solo el ingeniero más senior. Es el operador que decide qué incendios se apagan y cuáles se reconocen y se posponen.

En Wavect distinguimos tres perfiles. Un founding CTO está en el cap table y escribiendo código. Un scale-up CTO tiene 20+ ingenieros reportando y gestiona sobre todo ingeniería. Un fractional CTO se contrata cuando ninguno de esos dos perfiles está aún justificado por ingresos.

Error más común: contratar un scale-up CTO cuando la empresa necesita un founding. El CV impresiona, la pista se evapora en seis meses. Ajusta el perfil a la etapa.

Un CPO es dueño del producto. No del diseño, no de la ingeniería, no del marketing, sino de la pregunta de qué poner delante de los clientes y en qué orden. El rol existe porque cada decisión de envío es a la vez una decisión de no enviar otra cosa, y a escala esa elección necesita propietario.

Un buen CPO habla tres idiomas con fluidez: clientes (qué duele), ingenieros (qué es posible), equipo ejecutivo (qué mueve el P&L). Si falta uno, aparece deuda de producto: features enviadas que nadie compró, o features de ingreso que nadie envió.

Antes de PMF, un CPO dedicado suele ser excesivo. El rol lo absorbe el founder o el CTPO hasta que el equipo de ingeniería es lo bastante grande como para que alguien dedique todo su tiempo a qué construir a continuación.

Fractional Co-Founder es el servicio estrella de Wavect y es exactamente lo que suena. Nos integramos al nivel de un cofundador: estrategia de producto, arquitectura técnica, planificación de sprint, llamadas con clientes, preparación del consejo. No aparecemos con una hoja de horas. Aparecemos con el resultado.

Precio: 400 EUR por semana, cancelable cada semana, sin preaviso, sin penalización de salida. Si no te sorprendemos, te devolvemos la última semana. Lo hacemos porque el mal fit sale caro a las dos partes. Un piloto de dos semanas que termina limpio es mejor resultado que un contrato de seis meses arrastrándose.

No somos para todos. Si necesitas un cuerpo que tramite tickets, contrata un freelancer. Si necesitas a alguien que cuestione tu roadmap, que se siente contigo a las 11 de la noche del domingo con una decisión dura de arquitectura, y que te diga cuándo tu feature favorita es la equivocada, este es el contrato que quieres.

El mercado de CTO fraccional existe porque contratar uno full-time demasiado pronto es caro y demasiado tarde es fatal. El fraccional cubre el hueco: toma decisiones de arquitectura, lleva la contratación de ingenieros senior, asiste a reuniones del consejo y escribe las secciones técnicas de los decks de inversores.

Lo que normalmente no hace es escribir código de producción. Si tu equipo necesita un IC fuerte, lo que quieres es un ingeniero senior con un CTO como caja de resonancia, no un fraccional haciendo la ingeniería. En Wavect a veces difuminamos la línea cuando el equipo es tan pequeño que también el CTO tiene que enviar; el SoW lo explicita.

Cuidado con vendors que venden „CTO fraccional" como un account manager renombrado. Un fraccional real tiene autoridad de decisión, asiste a las reuniones que asistiría un full-time y aparece en los materiales del consejo.

Menos habitual que el modelo de CTO fraccional, pero cada vez más real. Un CPO fraccional entra 1 a 3 días por semana para llevar descubrimiento de producto, secuenciar el roadmap y poseer la cadencia de entrevistas con clientes. No es dueño de ingeniería. No es dueño del diseño salvo que se lo pidas.

El encaje es estrecho: la empresa necesita seniority de producto pero todavía no puede justificar un CPO full-time, Y el founder está dispuesto a delegar la decisión de producto. Si el founder también es la persona de producto y no quiere compartir esa autoridad, un fraccional de CPO genera fricción.

Un tech lead es ante todo un IC y, en segundo lugar, un coordinador. Escribe código. Revisa código. Toma la decisión cuando dos ingenieros discrepan en la implementación. No es manager: no maneja promociones, performance reviews ni contratación fuera de su equipo.

En Wavect desplegamos a menudo un tech lead junto a un CTO fraccional. El CTO posee la arquitectura y la coordinación entre equipos. El tech lead posee la calidad del output del día a día. Confundir los dos roles es el error más común que vemos en startups en serie A.

Los engineering managers gestionan personas, no arquitectura. Están entre los ingenieros y el resto de la empresa: traducen estrategia a prioridades del equipo, manejan el hiring loop y tienen las conversaciones que ningún ingeniero quiere tener.

Un buen EM tiene credibilidad técnica (los ingenieros le respetan) sin competir con los IC senior del equipo. Uno malo está demasiado lejos para liderar o demasiado dentro para gestionar. El rol es de los más difíciles de contratar; la mayoría de las startups tempranas sobrecontratan en lo técnico e infracontratan en management, por eso los equipos de ocho empiezan a tambalearse.

Un Statement of Work es el documento que convierte un acuerdo verbal en contrato. Lista el entregable en términos concretos („feature X en producción cumpliendo criterios de aceptación A, B, C"), el precio, el plazo y las condiciones de aceptación.

En derecho austríaco y alemán el instrumento equivalente es el Werkvertrag, más fuerte que el SoW en inglés: el proveedor está legalmente obligado a entregar la obra, no solo a aportar esfuerzo. Un contrato por tiempo y material bajo el mismo marco es un Dienstvertrag, que solo obliga a esfuerzo. Los engagements a precio fijo de Wavect son Werkverträge.

El SoW es también el documento que evita el scope creep. Lo que no esté en él queda fuera por definición y se gestiona con un change request. No es jurídico, es la única manera de que ambas partes acuerden qué significa „terminado" sin discutir seis meses después.

Time & Material es el modelo por defecto en agencias de staffing y en la mayoría de contratos freelance. Pagas por hora o por día; el proveedor registra horas; la factura llega cada mes. No hay entregable contractual, solo esfuerzo contractual.

El modelo es honesto en el sentido de que nadie pretende que el proveedor sea dueño del resultado. También es el peor alineado de los modelos comunes: el incentivo del proveedor es facturar más horas, no acabar antes. Los clientes inteligentes ponen un tope de presupuesto y un alcance claro, lo que en esencia es reinventar un SoW sin el peso legal.

Wavect usa T&M para engagements exploratorios donde el alcance no se puede definir de antemano. No lo usamos por defecto. Si un vendor te empuja a T&M para un trabajo con entregable claro, te está pasando el riesgo.

Un engagement a precio fijo traslada el riesgo de entrega del cliente al proveedor. El precio queda fijado antes de empezar. El alcance está por escrito. La fecha forma parte del contrato. Si el proveedor se pasa de presupuesto o de tiempo, ese problema es suyo, no tuyo.

Para que esto sea real y no teatro, el contrato tiene que ser un Werkvertrag (AT/DE) o su equivalente local más cercano. „Precio fijo" como promesa verbal con un contrato T&M debajo no es precio fijo; es una línea de marketing.

Wavect trabaja a precio fijo para engagements con alcance bien definido y descubrimiento previo. Para trabajo pre-descubrimiento hacemos primero una fase de discovery de 2 a 3 semanas, también a precio fijo. Su coste se descuenta de la factura del build si continúas con nosotros.

Nuestra garantía a precio fijo significa SoW firmado (Werkvertrag), obligado legalmente a entregar. No significa reembolso si se incumple el plazo.

Un retainer es una suscripción al tiempo del proveedor. Pagas cada mes; a cambio obtienes un número definido de días o una capacidad de equipo definida. El alcance concreto cambia; la disponibilidad no.

Los retainers funcionan bien cuando el trabajo es continuo y las prioridades cambian demasiado rápido para que un SoW las siga. Los equipos de producto los usan para socios de diseño, los de ingeniería para roles senior fraccionales, y casi todo asesoramiento legal funciona así.

El riesgo es inverso al T&M: el proveedor cobra incluso si no hay trabajo. Los clientes inteligentes añaden una cláusula de „uso razonable" y revisan el retainer trimestralmente. Si la utilización está por debajo del 60 %, el retainer es la forma equivocada y conviene un SoW por engagement.

Discovery es el trabajo que hace falta antes de poder cotizar honestamente un build a precio fijo. Produce cuatro artefactos: una arquitectura de software, un plan de milestones, los flujos técnicos críticos y un plan de lanzamiento. A partir de ellos se cotiza un precio fijo real.

Wavect lleva discovery como engagement a precio fijo de 2 a 3 semanas por 3.500 EUR. Si continúas con nosotros para el build, la tarifa de discovery se descuenta de la primera factura. Si no, te llevas los cuatro artefactos y puedes ir a otro proveedor con ellos.

Por qué cobramos discovery: el scoping gratis o es deshonesto (el proveedor recupera el coste en la estimación del build) o es de baja calidad (lo hace deprisa porque no se paga). Cobrar arregla el incentivo.

Sprint es un término específico de Scrum que se ha colado en el habla general para nombrar cualquier unidad de trabajo corta y acotada. La definición original exige tres cosas: duración fija, sesión de planificación al inicio y revisión al final. La mayoría de equipos conservan las dos primeras y abandonan la tercera, por eso muchos llaman „sprints" a su ritmo pero no producen incremento demostrable.

La duración importa. Sprints de una semana fuerzan un alcance estrecho y sacan rápido a la luz los problemas de entrega. Sprints de dos semanas dan espacio para trabajo sustancial pero absorben más deriva. Sprints de tres semanas casi siempre acaban siendo dos mal planificados.

Web3 nombra una familia de tecnologías, no una sola cosa. Lo común es que el estado del usuario (activos, identidad, a veces datos) vive en una blockchain pública en vez de en una base de datos centralizada. El usuario firma transacciones con una clave privada que él mismo guarda. El vendor no puede congelar ni borrar su cuenta.

En la práctica cubre wallets, smart contracts, exchanges descentralizadas, NFTs, DAOs, account abstraction, sistemas ZK, bridges cross-chain y la capa de aplicación encima. Wavect construye en este espacio sobre EVM (Ethereum y compatibles), Solana, Cosmos, Polkadot, Near, Ton e ICP.

La versión honesta: la mayoría de proyectos Web3 no necesitan blockchain. Los que sí (activos que deben sobrevivir a la quiebra del vendor; confianza multi-parte sin operador central; composability sin permiso) tienen valor. El resto son distracciones financiadas por VC. Te decimos en qué categoría caes.

Una prueba de conocimiento cero permite a una parte (el probador) convencer a otra (el verificador) de que conoce cierta información, sin revelarla. Ejemplo canónico: demostrar que eres mayor de 18 sin revelar tu fecha de nacimiento.

En producción, ZK aparece en dos sabores. Los ZK-SNARKs son más pequeños y rápidos de verificar pero requieren un trusted setup. Los ZK-STARKs son más grandes y lentos pero no necesitan trusted setup y son resistentes a la computación cuántica. La mayoría de chains ya ofrecen circuitos pre-hechos para pruebas comunes (identidad, balance, elegibilidad de voto), así que no necesitas un criptógrafo en plantilla.

El caso de negocio es más estrecho que el hype: ZK es genuinamente valioso cuando necesitas demostrar una propiedad on-chain (o a una contraparte) sin filtrar los datos. Para la mayoría de apps de consumo es exagerado.

En una chain EVM estándar, cada cuenta es o una Externally Owned Account (una clave privada) o un smart contract. ERC-4337 introduce una tercera clase: una cuenta-smart-contract con la que el usuario transacciona. Al ser contract, puede contener lógica. Esa lógica puede patrocinar gas, recuperarse de una clave perdida vía guardians, agrupar varias llamadas en una transacción o aplicar reglas de auth a medida como un límite diario de gasto.

Las implicaciones de UX son grandes. Con AA, un usuario final puede registrarse con email y passkey en vez de seed phrase. El gas lo puede pagar la aplicación o pagarse en el token de la app, no en ETH. La wallet puede limitar transacciones sospechosas. El trade-off es mayor complejidad on-chain y mayor coste de gas por transacción.

Wavect ha enviado wallets y Snaps (plugins de MetaMask) con account abstraction a producción. La tecnología es real y cada vez más mainstream. La implementación no es trivial. Si un vendor te cotiza AA como un add-on barato, pregunta qué infraestructura usa y qué auditorías de seguridad ha pasado el contract.

Un AI agent es el loop, no el modelo. El modelo (Claude, GPT, Gemini, un LLM open-weights) es el que decide. El agent es el runtime: le da al modelo un objetivo, le deja invocar herramientas (una base de datos, una API, un intérprete de código, otro agent), observa el resultado y vuelve a alimentar el loop hasta terminar.

La distinción importa porque los sistemas agénticos fallan distinto que las aplicaciones LLM puras. Un chatbot se puede equivocar y el usuario sigue adelante. Un agent que se equivoca manda un email, hace una transacción o borra un archivo. Los agents en producción necesitan gates de autorización, observabilidad y circuit breakers que la mayoría de prototipos se saltan.

La postura de Wavect: primero preguntar si IA es la herramienta adecuada aquí, después si un agent es la forma adecuada de IA. La mayoría de flujos vendidos como „agénticos" se resuelven mejor con un pipeline determinista y una sola llamada al LLM en medio.

Model Context Protocol (MCP) es para los AI agents lo que HTTP es para la web: un estándar abierto y compartido sobre cómo el modelo habla con el resto del mundo. Lo introdujo Anthropic a finales de 2024 y se adoptó ampliamente a lo largo de 2025 y 2026.

Forma técnica: un servidor MCP expone recursos, herramientas y prompts a través de un schema definido. Cualquier cliente compatible (Claude Desktop, Claude Code, la API, un plugin de IDE) puede descubrir e invocar esas herramientas sin pegamento por proveedor. Integras una vez; se beneficia cada cliente MCP.

Para las empresas la implicación práctica es palanca. Herramientas internas, bases de datos y APIs envueltas en un servidor MCP quedan utilizables por el LLM que tu equipo use este trimestre, sin reescribir cuando cambies. El trade-off es que MCP es joven: tooling, modelo de seguridad y patrones de auditoría aún maduran. Construimos servidores MCP a menudo y los llevamos a producción; aun así escribimos una revisión de seguridad para cada uno porque el estándar se mueve.

RAG es la arquitectura que permite a un LLM responder a preguntas sobre datos en los que no fue entrenado. El mecanismo es directo: coge la pregunta del usuario, recupera los chunks más relevantes de tu corpus (vía búsqueda vectorial, por keywords o híbrida), mételos en el prompt y deja que el modelo responda.

Por qué existe RAG: entrenar un modelo con tus datos privados es caro, lento y queda obsoleto en cuanto tus datos cambian. RAG lo evita tratando los datos como contexto en tiempo de ejecución. Trade-off: la calidad de la recuperación se vuelve el cuello de botella. Un modelo con mal contexto produce respuestas erróneas con seguridad.

Verdad poco sexy sobre RAG: el 80 % del trabajo es hacer bien la recuperación (estrategia de chunking, elección de embeddings, reranking, búsqueda híbrida) y el 20 % el modelo en sí. Los vendors que venden RAG como una feature de un clic venden la parte fácil.

Un smart contract es un programa desplegado en una blockchain. Una vez desplegado, su bytecode es inmutable, su estado público y su ejecución se rige por reglas de consenso que nadie puede saltarse. Esa permanencia es feature y riesgo a la vez: un bug en producción es un bug para siempre, salvo que metas mecanismos de upgrade (que en sí son superficie de vulnerabilidad).

La mayoría de sistemas de smart contracts en producción no son un solo contract sino un conjunto: un proxy para upgradeability, un contract de implementación para la lógica y, a menudo, un contract de access-control para gobernanza. El patrón es familiar para quien haya versionado APIs; el coste del error es mayor.

Wavect escribe smart contracts en Solidity (chains EVM) y Rust (Solana, Near, ICP). Para cualquier contract que custodia valor no trivial recomendamos auditoría externa antes del despliegue a mainnet. Hemos entregado contracts auditados a producción; la auditoría suele costar 1 a 2 semanas del presupuesto del build.

La EVM es la capa de ejecución que Ethereum inventó y se convirtió en estándar de facto para chains de smart contracts. Un contract compilado a bytecode EVM corre en Ethereum mainnet, Polygon, Arbitrum, Optimism, Base, BNB Chain, Avalanche C-chain y una larga cola de L2s y sidechains.

Implicación práctica: escribe los contracts en Solidity (o Vyper), pruébalos en testnets de Ethereum y despliega en la chain EVM que encaje con tu objetivo de coste y latencia. La portabilidad es real. Los trade-offs entre chains son velocidad, finalidad, descentralización y framework de L2.

Cuidado: compatible con EVM no es lo mismo que equivalente a Ethereum. Diferencias sutiles en gas, precompiles y consenso pillan a equipos que despliegan sin re-probar en cada chain.

Solana no es compatible con EVM. Los smart contracts (en Solana se llaman „programs") se escriben en Rust, se despliegan como bytecode BPF y los ejecuta el runtime de Solana. La arquitectura optimiza throughput (miles de TPS) y comisiones bajas, al coste de requisitos de hardware más altos para validadores y un perfil de descentralización distinto (algunos dicen más centralizado).

Para aplicaciones de consumo donde el usuario paga comisiones por debajo del céntimo y la confirmación es sub-segundo, Solana es difícil de batir. Para componibilidad DeFi profunda con el ecosistema EVM, el coste de cruzar el bridge no es trivial. La chain adecuada depende de qué trade-off pesa más en tu producto.

Wavect entrega tanto en Solana como en EVM. No tenemos sesgo de chain; tenemos sesgo de caso de uso.

LoRaWAN es la capa de red que hace económico el IoT a gran escala. Los dispositivos funcionan con pilas de botón durante años, transmiten payloads pequeños (unos cientos de bytes) y llegan a gateways a kilómetros. Trade-offs: poco ancho de banda, actualizaciones poco frecuentes y una fase de despliegue no trivial para que la cobertura de gateways quede bien.

Aplicaciones que hemos entregado: redes de sensores urbanos (parking, medioambiente, residuos), monitorización agrícola, telemetría industrial. El patrón es siempre el mismo: sensores baratos y tontos en el edge; gateways que agregan a un network server; el network server reenviando al backend de tu aplicación.

LoRaWAN es la herramienta adecuada cuando necesitas muchos sensores en un área amplia con autonomía de años. Es la herramienta equivocada si necesitas mucho ancho de banda, baja latencia o planes de móvil por dispositivo (5G NB-IoT suele encajar mejor para los dos últimos casos).

Agile es más viejo de lo que la mayoría cree (el manifiesto es de 2001) y peor implementado de lo que la mayoría de equipos admite. La idea original era simple: planificar más allá de lo que puedes predecir es trabajo desperdiciado, así que planifica corto, envía, aprende, replanifica. Todo lo demás (Scrum, Kanban, SAFe, sprints, retros, story points) son detalles de implementación.

La pregunta más útil para un equipo que dice „hacemos agile" es: ¿cuándo fue la última vez que el plan cambió por lo que se envió la semana pasada? Si la respuesta es nunca, el equipo hace cascada en trozos de dos semanas.

Wavect es agile en el sentido original: trabajamos en ciclos cortos, hacemos demos a menudo y tiramos el trabajo que resulta estar equivocado. Somos escépticos con la versión de agile de la industria de certificaciones, donde la cadencia de reuniones se vuelve el objetivo.

Test-Driven Development es una disciplina, no una metodología. El loop es: rojo (escribir un test que falla), verde (escribir el código más simple que pase), refactor (limpiar sin romper el test). Hecho al pie de la letra, produce código con cobertura de tests muy alta y una función de fuerza contra el over-engineering.

Por qué la mayoría de los equipos dicen que hacen TDD pero no lo hacen: escribir el test primero se siente más lento en el momento. El payoff (seguridad para refactorizar, cobertura de regresión, presión de diseño hacia unidades pequeñas) llega meses después. Para entonces el equipo dejó de escribir los tests primero y se convenció de que nunca marcó la diferencia.

Wavect usa TDD donde paga: tests de integración para todo lo relacionado con dinero, tests de contrato para todo lo orientado al cliente, tests unitarios para lógica no trivial. No escribimos tests para getters y setters. La cobertura como objetivo es una métrica que se manipula.

Behavior-Driven Development es TDD con el lenguaje de los tests reescrito para que lo lean no-ingenieros. Herramientas como Cucumber usan un formato Given/When/Then que un product manager puede firmar. La idea es mantener los tests alineados con el comportamiento de negocio que validan, no con la implementación que existe hoy.

En la práctica el valor es máximo en las capas de integración y aceptación, donde la barrera de lenguaje entre ingeniería y producto produce bugs reales. En la capa de unit tests, BDD añade más ceremonia de la que ahorra.

La palabra „viable" en MVP hace todo el trabajo, y casi todo el mundo la entiende mal. Viable no significa „una versión reducida del producto final". Viable significa „suficiente para probar la hipótesis de que vale la pena construirlo". Una landing page con lista de espera puede ser un MVP. Un producto funcional con tres features puede ser peor MVP que la landing page.

Error más común: construir el MVP que imaginabas hace seis meses en vez del MVP que prueba la suposición más incierta de esta semana. Cada semana cambia qué suposición habría que probar. La mayoría de MVPs son obsoletos antes de enviarse.

La fase de discovery de Wavect existe en parte para arreglar esto. Antes de poner alcance al MVP, nombramos la hipótesis que debe probar. Si la hipótesis es „los usuarios quieren la feature X", el MVP no es una feature X pulida, sino la forma más barata de averiguarlo.

Product-Market Fit es famoso por lo difícil de definir y lo fácil de reconocer. La heurística de Marc Andreessen sigue valiendo: lo sabes cuando el producto es empujado por usuarios, prensa y cap table a la vez, y tu problema ya no es encontrar clientes sino seguir el ritmo.

Antes del PMF casi todo lo que haces es una apuesta. El organigrama correcto, el stack correcto, el plan de contratación correcto dependen de qué segmento de clientes tira. Después del PMF las preguntas se vuelven operativas: escalar el equipo, endurecer el stack, controlar el burn.

Por qué importa para las decisiones de ingeniería: un equipo pre-PMF que sobre-construye para escala quema pista. Un equipo post-PMF que infra-construye se lo come su propio éxito. Wavect actúa de forma distinta a cada lado de esa línea. Antes de PMF: la versión más barata que permita aprender. Después de PMF: endurecer, documentar y empezar a dormir bien.

Software Development Lifecycle es el paraguas para nombrar las etapas que recorre el software desde idea hasta retirada. Distintas metodologías (cascada, agile, devops, continuous delivery) definen fronteras de etapa y formas de pasar de una a otra distintas. Las etapas en sí son prácticamente invariantes.

Útil como vocabulario, no como proceso. Los equipos que tratan de imponer un SDLC estricto acaban con sobrecarga de documentación que no sobrevive al segundo sprint. Los que lo ignoran del todo redescubren cada fase por las malas („enviamos sin plan de deploy", „no pensamos cómo retirar esto").

La forma preferida por Wavect: discovery al inicio, diseño y build entrelazados en ciclos cortos, test y deploy automatizados desde el día uno, operar con propiedad clara, retirar con caminos de migración documentados.

Continuous Integration significa que el código del equipo se mergea y construye en cada cambio, no en una integración big-bang al final. Continuous Delivery significa que cada build exitoso está a un clic de producción. Continuous Deployment quita el clic: cada build verde sale solo.

La mayoría de equipos hace CI bien, CD a ratos y Continuous Deployment casi nunca. El cuello de botella rara vez es la herramienta. Es la confianza en la suite de tests y la voluntad del equipo de arreglar un build roto en una hora. Sin eso, los deploys automáticos solo envían bugs más rápido.

Wavect entrega cada proyecto con CI configurado desde el día uno. La configuración de CD depende de si el proyecto tiene la cobertura de tests y la disciplina operativa para que sea seguro. Te diremos cuál tienes.

Continuous Delivery es la prima responsable de Continuous Deployment. Cada cambio recorre el mismo pipeline automático de build, test y preparación de release. El artefacto que sale es enviable. Que se envíe es decisión de un humano.

Por qué la mayoría se queda en CD en vez de pasar a Continuous Deployment completo: el coste de un mal deploy es lo bastante alto como para que un humano en el loop justifique la latencia. Pasa a Continuous Deployment cuando tu monitorización, cobertura de tests e historia de rollback sean lo bastante buenas como para que el humano deje de aportar señal.