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 de verdad 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.

Ejemplo de por qué el rol combinado gana al principio: una startup de dos founders envía sin parar las features que pidió el inversor que más grita, porque el cofundador técnico construye lo que salga de la conversación de producto y nadie es dueño de la secuenciación. Un CTPO colapsa ese loop. La misma persona que decide que el rediseño del checkout pesa más que el dashboard también decide cómo se arquitecta y si entra en este sprint. No hay handoff, ni capa de traducción, ni pulso de los martes entre dos egos C-level, que es la mayor fuente de pista quemada antes del PMF.

En un engagement con Wavect el CTPO suele ser fraccional, entregado a través de nuestro modelo de fractional co-founder. 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 la empresa tiene los ingresos y la estructura para justificar ambos. En Austria ese engagement es normalmente un freier Dienstvertrag, ya que el entregable es criterio continuo, no una obra fija.

El trade-off honesto y el error de founder más común: una sola persona se vuelve punto único de fallo, y los founders se enamoran de la comodidad y mantienen al CTPO mucho más allá del momento en que el rol debió partirse. La mitigación es 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. El rol debe partirse cuando gestionar ingeniería se vuelve un trabajo full-time (normalmente 8+ ingenieros) y producto no puede esperar a un lote semanal. Antes, partirlo solo crea impuesto de coordinación. Relacionado: Fractional CTO Austria.

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 ni un tech lead senior con un título más vistoso. Es el operador que decide qué incendios se apagan y cuáles se reconocen y se posponen, y que carga con el riesgo técnico que llega a la agenda del consejo.

En Wavect distinguimos tres perfiles. Un founding CTO está en el cap table y en las trincheras escribiendo código. Un scale-up CTO tiene 20+ ingenieros reportando y gestiona sobre todo ingeniería a través de una capa de engineering managers. Un fractional CTO se contrata para cubrir el hueco cuando ninguno de esos dos perfiles está aún justificado por ingresos.

Ejemplo del error más común y más caro: una startup seed levanta una ronda, le aconsejan «contratar un CTO de verdad» y recluta un nombre impresionante de una empresa de 200 ingenieros. Esa persona lleva cinco años gestionando organigramas y presupuestos, no escribiendo código, y aterriza en un equipo de cuatro que necesita a alguien que arquitecte el sistema y lo envíe él mismo. Seis meses y un cuarto de la pista después, el equipo tiene proceso y slides pero el producto apenas se ha movido. El CV era real; era el perfil equivocado para la etapa. Ajusta el perfil a la etapa, no al logo.

El trade-off honesto que los founders esquivan: un CTO con forma de founding que sabe construir choca tarde o temprano con un techo en la parte de gestión, y un scale-up CTO que sabe gestionar está desperdiciado (y aburrido) con cuatro ingenieros. El rol cambia de verdad según crece la empresa, por eso la pregunta rara vez es «¿necesitamos un CTO?» sino «¿qué CTO necesita esta etapa?». Cuando la respuesta es «la autoridad de decisión pero todavía no el coste full-time», la versión fraccional lo cubre. Ver Fractional CTO Austria para el engagement pilar de Wavect.

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. Combínalo con el cometido de CTO en una sola persona y obtienes un CTPO; mantenlo a tiempo parcial y obtienes un fractional CPO.

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

Ejemplo del fallo de «idioma que falta»: un CPO fichado directamente de una organización liderada por ventas habla con fluidez P&L y clientes pero no sabe leer lo que ingeniería le dice sobre el coste. Compromete el roadmap a un trimestre de «quick wins» que en silencio son seis meses de trabajo de plataforma, las fechas se deslizan y la confianza se erosiona por ambos lados. El fallo espejo es el ingeniero reconvertido en CPO que sabe acotar cualquier cosa pero no sabe decir qué feature mueve de verdad los ingresos. El trabajo es la traducción entre los tres, y la debilidad en cualquiera aparece como la cosa equivocada construida con seguridad.

El trade-off honesto y el error común: los founders echan mano de un CPO dedicado demasiado pronto. Antes del PMF el rol es excesivo, porque la propia intuición del founder con el cliente es el activo de producto más valioso de la empresa y no se puede delegar. El trabajo lo absorbe el founder o un CTPO hasta que el equipo de ingeniería es lo bastante grande como para que decidir qué construir a continuación sea un full-time. Antes de ese punto, contratar un CPO sobre todo añade una capa entre el founder y el cliente, que es lo contrario de lo que necesita un producto en etapa temprana. Relacionado: Fractional CTO Austria.

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. En términos de rol suele ser un CTPO fraccional, producto y tecnología en un solo cuello. 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.

Ejemplo de cuándo esta es la forma correcta: un founder no técnico tiene ingresos pero sigue contratando agencias que construyen lo equivocado porque nadie dentro puede cuestionar el brief. Un fractional co-founder se sienta entre él y quienes construyen, es dueño del roadmap, toma las decisiones de arquitectura y le dice al founder cuándo la feature a la que está emocionalmente atado es la apuesta equivocada. Esa postura, dueño en vez de contratista, es toda la diferencia respecto a un fractional CTO, que cubre autoridad técnica pero no carga con el peso de producto y propiedad.

El matiz legal austríaco: esto se contrata como un freier Dienstvertrag, no un Werkvertrag, porque debemos criterio y disponibilidad continuos en vez de una sola obra fija, y a diferencia de un cofundador real no hay equity ni entrada en el cap table por defecto. El trade-off honesto, y donde los founders se equivocan: esto no es un cuerpo que tramite tickets (para eso contrata un freelancer) y no sustituye la propia convicción del founder. Si necesitas a alguien que se siente contigo a las 11 de la noche del domingo con una decisión dura de arquitectura bajo un SoW claro, este es el contrato que quieres. ¿Ya has pasado el PMF y buscas un CTO en su lugar? Ver Fractional CTO Austria.

El mercado de CTO fraccional existe porque contratar uno full-time demasiado pronto es caro y demasiado tarde es fatal. Un CTO 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.

Ejemplo: una empresa seed tiene dos ingenieros mid fuertes, un founder que sabe leer código pero no arquitectar un sistema, y un inversor preguntando por qué el roadmap se sigue deslizando. No necesita un CTO full-time a 180k más equity. Necesita a alguien dos días por semana que fije la arquitectura, desbloquee a los dos ingenieros y convierta el roadmap en milestones que el consejo pueda seguir. Ese es el mandato de manual de un fractional CTO, y suele durar de seis a doce meses hasta que un hire full-time se justifica.

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.

El matiz legal en Austria: un fractional CTO se contrata normalmente como Dienstvertrag o freier Dienstvertrag, no Werkvertrag, porque debe criterio y disponibilidad continuos, no una sola obra fija. Eso importa para la responsabilidad y para cómo se contabiliza el engagement. No dejes que un vendor disfrace un retainer de fractional CTO como un contrato de alcance fijo; las obligaciones son distintas.

El error de founder común: confundir un fractional CTO con un fractional co-founder. El CTO cubre autoridad técnica. La postura de cofundador añade estrategia de producto y conducta de propiedad. Si quieres a alguien que cuestione tu roadmap y no solo tu stack, quieres lo segundo. El trade-off honesto de cualquier modelo fraccional es la continuidad: un ejecutivo a tiempo parcial nunca tendrá la profundidad de contexto de un full-time, así que el engagement solo funciona si el alcance está acotado y el handoff se planifica desde el día uno.

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. Ver Fractional CTO Austria.

Un Interim CTO es un ejecutivo full-time y temporal que dirige ingeniería durante una transición, normalmente de 3 a 12 meses. El trigger es un vacío: el CTO anterior dimitió en mitad de una ronda, fue despedido, o la empresa lo superó antes de que existiera un plan de sucesión. El interim entra a plena capacidad, estabiliza la organización y entrega a la contratación permanente que a menudo ayuda a reclutar.

La diferencia con un Fractional CTO es la forma del compromiso, no la seniority. Fractional significa 1 a 3 días por semana, de forma continua, para una empresa que necesita autoridad de nivel CTO sin presencia full-time. Interim significa cinco días por semana con fecha de fin planificada, para una empresa que tiene un agujero de tamaño full-time ahora mismo. Elige según el tamaño del agujero, no según qué título suena más senior.

Ejemplo: una scale-up pierde a su CTO ocho semanas antes de una technical due diligence. Cuarenta ingenieros, tres equipos, sin segundo de a bordo. Un operador fractional a dos días por semana no puede absorber eso. La organización necesita a alguien en cada reunión de liderazgo, cada escalación, cada llamada de la diligence, y eso es un mandato interim. El caso espejo, una startup seed con cuatro ingenieros y un roadmap que se desliza, tiene un problema de dos días por semana. Pagar un interim full-time ahí quema runway en presencia que nadie necesita.

El matiz legal austriaco refleja el modelo fraccional: un Interim CTO se contrata normalmente como Dienstvertrag o freier Dienstvertrag, porque el entregable es criterio y disponibilidad continuos, no una obra fija. El trade-off honesto del interim es el acantilado: todo lo que el interim aprendió sale por la puerta en el handover, así que el mandato debe incluir documentar decisiones y reclutar al sucesor. Un interim que es vago sobre su propio plan de salida está planeando quedarse, y eso es un producto distinto y más caro.

Los engagements de Wavect son fraccionales por diseño, 1 a 2 días por semana con dos founders en cada engagement. Si tienes un vacío real que necesita cinco días por semana, contrata interim, y te lo diremos exactamente así en la primera llamada. Dónde se solapan las dos formas se cubre en Fractional CTO Austria.

Menos habitual que el modelo de fractional CTO, 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 el coste de 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 es un generador de fricción.

Ejemplo: una empresa alcanzó tracción temprana, el founder está enterrado en ventas y el equipo de ingeniería envía lo que pidió el cliente que más gritó la semana pasada. Un fractional CPO entra a instalar un framework de priorización, llevar una cadencia de discovery seria y dar a ingeniería un roadmap secuenciado en vez de una cola de peticiones sueltas. Tres días por semana bastan porque el trabajo es criterio y estructura, no volumen de ejecución.

El error común que cometen los founders es contratar un fractional CPO para evitar tomar ellos mismos las decisiones de producto, antes del PMF. Eso nunca funciona. Pre-PMF, la intuición del founder con el cliente es el activo más valioso de la empresa y no se puede externalizar. Un fractional CPO escala una función de producto que ya tiene un punto de vista; no lo inventa. En Austria el engagement suele ser un freier Dienstvertrag, como la mayoría de roles ejecutivos fraccionales, porque el entregable es criterio continuo y no una obra fija.

El trade-off honesto: un CPO a tiempo parcial siempre irá por detrás de un full-time en contexto, y el contexto de producto se acumula. Si tus decisiones de roadmap hay que tomarlas a diario sobre conversaciones en las que el CPO no estuvo, el modelo se rompe. Funciona cuando las decisiones se pueden agrupar semanalmente y el equipo puede ejecutar entre sesiones.

Relacionado: Fractional CTO Austria.

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. Esa última distinción es la que lo separa de un engineering manager, y equivocarse sale caro.

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: los estándares de code review, cómo el equipo practica agile, si la definición de «hecho» es real o teatro. Confundir los dos roles es el error más común que vemos en startups en serie A.

Ejemplo de ese error: una empresa promociona a su mejor ingeniero a «tech lead» y luego le va apilando en silencio 1:1s, entrevistas de contratación y planificación de plantilla. Seis meses después la base de código ha derivado porque nadie senior la revisa, y el nuevo lead está quemado haciendo dos trabajos mal. El arreglo es nombrar el split explícitamente: la autoridad técnica se queda en el tech lead, la autoridad sobre las personas pasa a un EM, aunque sea fraccional.

El trade-off honesto: un tech lead fuerte con un CTO externo como caja de resonancia a menudo rinde más que un CTO junior full-time sobre el papel, y cuesta mucho menos. El techo es la autoridad de decisión fuera del equipo. Un tech lead no es dueño de la arquitectura entre productos ni del riesgo técnico a nivel de consejo, y fingir que sí solo retrasa el momento en que necesitas de verdad un CTO.

¿Cuánto debería programar de verdad un tech lead? La mayor parte del tiempo, y aquí es donde los founders rompen el rol en silencio. El instinto, una vez que alguien es «el lead», es arrastrarlo a reuniones, planificación y coordinación hasta que programa el diez por ciento de la semana. Un tech lead que deja de enviar pierde el respeto técnico del equipo y se aleja de la base de código de la que se supone que tiene el conocimiento más profundo. La regla práctica es al menos la mitad de su tiempo con las manos en el código, el resto en review, diseño y desbloqueo. El día en que la carga de coordinación supere eso de verdad, no tienes un tech lead sobrecargado, tienes un asiento de engineering manager sin cubrir.

Relacionado: Fractional CTO Austria.

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. Las decisiones técnicas se quedan con el tech lead; el EM se asegura de que las personas que toman esas decisiones crecen, están apoyadas y no están a punto de irse.

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.

Ejemplo: un equipo crece de cinco a diez ingenieros en un año. Nadie añadió management, así que el CTO fundador lleva ahora diez 1:1s, tres hiring loops y dos problemas de desempeño mientras sigue intentando ser dueño de la arquitectura. La velocidad se desploma, dos personas se van y todos culpan al «proceso». La causa real es un EM que falta. La señal llega meses antes de la fuga: la persona más senior pasa más tiempo en reuniones sobre personas que en la base de código o en el SDLC.

El error común es promover a un ingeniero senior fuerte al rol sin formación y suponer que las habilidades con personas vendrán detrás de las técnicas. Normalmente no vienen; los dos conjuntos de habilidades son casi independientes. Promociona por interés demostrado en el trabajo con personas, luego enseña el contexto técnico, no al revés.

El trade-off honesto: un gran EM hace el output del equipo menos legible para el founder, porque su mejor trabajo (retención, desbloqueo, conversaciones difíciles) no aparece en un diagrama de Gantt. Los founders que miden solo features enviadas tienden a infravalorar e infracontratar el rol hasta que el tambaleo se vuelve fuga.

Relacionado: Fractional CTO Austria.

Un Product Manager es dueño del qué y del porqué, no del cómo. Decide qué problema resuelve el equipo a continuación, por qué importa y qué significa «terminado» para el cliente. No escribe el código, no dirige el sprint como jefe y no diseña la arquitectura. Su trabajo es asegurarse de que el equipo construya lo correcto antes de que nadie discuta cómo construirlo bien.

El rol es sobre todo criterio y comunicación bajo presiones contradictorias. Ventas quiere la funcionalidad que cierra el trato. Soporte quiere el error corregido. El fundador quiere la apuesta audaz. Un buen PM sostiene todo eso, dice no a la mayoría en voz alta y entrega la única cosa que mueve el negocio. Es responsable del resultado, lo que significa que es dueño de la hoja de ruta y de las decisiones de priorización, no solo del mantenimiento del backlog.

Product Manager frente a Product Owner es donde la mayoría de los equipos se confunden. Product Owner es un rol específico de Scrum, distinto del Scrum Master: es dueño y ordena el backlog para que el equipo de desarrollo tenga claro lo siguiente que construir. Product Manager es el rol de negocio más amplio: mercado, estrategia, aporte sobre precios, alineación con los interesados y el porqué detrás de la hoja de ruta. Es el puesto que escala hacia un CPO (o un fractional CPO) una vez que la organización es lo bastante grande. En un equipo pequeño una persona lleva ambos sombreros. En uno más grande el PM marca la dirección y el PO la convierte en trabajo ordenado y listo para construir.

La contratación errónea más común es un PM sin autoridad. Si la hoja de ruta en realidad la fija el interesado que grita más fuerte y el PM solo escribe tickets, has contratado a un coordinador de proyectos y lo has llamado producto. Incorporamos la responsabilidad de producto en equipos fundadores como parte de un compromiso de fractional co-founder cuando el fundador está demasiado metido en la construcción para asumirla.

Un Software Architect es dueño de las decisiones difíciles de deshacer. Cómo se divide el sistema en servicios o módulos, cómo fluyen los datos a través de él, dónde están los límites, a qué tecnologías se compromete el stack y cómo aguanta el conjunto bajo carga, fallo y crecimiento. Las funcionalidades individuales son baratas de cambiar. Estas decisiones estructurales no lo son, por lo que necesitan a alguien pensando a nivel de sistema en lugar de a nivel de funcionalidad.

El valor real está en los requisitos no funcionales: rendimiento, escalabilidad, seguridad, fiabilidad, mantenibilidad. Son las cosas que ningún ticket de funcionalidad asume y que hunden silenciosamente un producto cuando se ignoran. El trabajo del arquitecto es nombrar las contrapartidas en voz alta. Más rápido de construir ahora frente a más barato de cambiar después. Simple y limitado frente a flexible y complejo. No hay arquitectura gratis, solo contrapartidas que elegiste a propósito o contrapartidas que heredaste por accidente.

La mayoría de las startups no necesitan un Software Architect dedicado, y contratar uno pronto suele ser un error. A pequeña escala la arquitectura es pequeña, y el tech lead o el CTO la asume como parte de su trabajo. Un arquitecto a tiempo completo sin código que escribir y sin equipo que liderar tiende a producir diagramas y documentos de estándares que el equipo luego ignora. El rol se gana su sitio una vez que el sistema es lo bastante grande como para que nadie tenga el cuadro completo en la cabeza.

Ejemplo de por qué el arquitecto sin código deriva mal: un arquitecto que dejó la base de código hace dos años diseña un sistema «limpio» dirigido por eventos con seis colas y tres bases de datos, porque en una pizarra eso desacopla todo de forma elegante. El equipo que tiene que construirlo descubre que el entorno de desarrollo local ahora tarda un día en levantarse, cada funcionalidad toca cuatro servicios, y depurar una sola queja de usuario significa correlacionar logs entre todos ellos. El diagrama era elegante; la experiencia vivida es miseria. Un arquitecto todavía cercano al código habría sentido venir ese coste, porque habría sido él quien corriera las seis colas en su portátil.

La opinión honesta: “Solutions Architect” en el organigrama de un proveedor a menudo significa un rol de preventa que diseña sistemas que nunca tendrá que mantener. Un buen arquitecto se mantiene lo bastante cerca del código como para sentir las consecuencias de sus propias decisiones. Si la persona que dibuja las cajas nunca tiene que vivir dentro de ellas, las cajas estarán mal.

Un Scrum Master tiene un solo trabajo real: hacer al equipo más eficaz quitándole cosas del camino. Eso significa eliminar bloqueos, proteger al equipo de interrupciones a mitad del sprint, facilitar los standups y las retros de Scrum para que sean útiles en lugar de teatro, y entrenar al equipo en cómo trabajar de verdad, no solo recitar las ceremonias. Es un servidor del equipo, no un jefe sobre él. No asigna trabajo, no es dueño del backlog (eso es el product manager o product owner) y no hace evaluaciones de desempeño (eso es el engineering manager).

El rol se malentiende en dos direcciones. Algunos lo tratan como un programador de reuniones glorificado que lee el guion del standup. Otros lo convierten silenciosamente en un jefe de proyecto que empuja al equipo a comprometerse con fechas. Ambos pierden el punto. El valor está en detectar qué está frenando al equipo, a menudo algo organizativo e incómodo, y tener la posición para arreglarlo. Un Scrum Master que solo dirige reuniones es sobrecarga.

La opinión honesta: los equipos pequeños rara vez necesitan un Scrum Master a tiempo completo. Un equipo de cuatro o cinco ingenieros puede dirigir sus propias ceremonias, y el trabajo de facilitación son unas pocas horas a la semana que un tech lead o un ingeniero senior puede absorber. Un Scrum Master dedicado a tiempo completo se gana el puesto cuando coordinas varios equipos, cuando la organización alrededor del equipo es la principal fuente de bloqueos, o cuando un equipo genuinamente aún no puede autoorganizarse. Por debajo de eso, el título es un coste en busca de una justificación.

Hemos visto muchos equipos más contentos y más rápidos tras eliminar al Scrum Master a tiempo completo y repartir el trabajo en el equipo. También hemos visto equipos ahogarse porque nadie asumía los bloqueos. El rol es real, la versión a tiempo completo a menudo no.

CTO as a Service es una etiqueta de empaquetado, no un trabajo distinto. Bajo la etiqueta, un vendor vende criterio de nivel CTO (decisiones de arquitectura, loops de contratación, gestión de vendors, reporting listo para el consejo) como servicio recurrente con un compromiso de tiempo definido. Quita el branding y lo que queda es un Fractional CTO en retainer: la misma autoridad, las mismas reuniones, una suscripción en lugar de un sueldo.

La etiqueta importa por lo que puede esconder. «As a service» implica que la persona es intercambiable, y el trabajo de CTO es el trabajo menos intercambiable que compra una empresa. El contexto se acumula: la decisión de arquitectura del mes uno solo tiene sentido para la persona que vio aterrizar los trade-offs en el mes cuatro. Los vendors que rotan consultores detrás de una marca de servicio resetean ese contexto en cada rotación, y el cliente paga el re-onboarding cada vez.

Ejemplo del modo de fallo: una startup firma un paquete de CTO as a Service con una agencia. El primer mes aparece un arquitecto senior. Para el mes tres, la llamada semanal la lleva un account manager que reenvía las preguntas a un pool. La startup sigue pagando tarifas de ejecutivo, pero nadie en la sala puede decir no a un feature sin consultar arriba. Eso es gestión de cuenta con pegatina de CTO, y es la queja más común que nos trae founders desde esta categoría.

Qué comprobar antes de firmar: quién aparece exactamente (personas con nombre, no un pool), si tienen autoridad de decisión o escalan a alguien que nunca conoces, y cómo termina el engagement (un plan de handover, no un pitch de renovación). En Austria esto es normalmente un retainer estilo Dienstvertrag y no un Werkvertrag, porque el entregable es criterio continuo, y una cláusula limpia de cancelación semanal o mensual es la versión honesta de «as a service».

La versión de Wavect es el engagement Fractional CTO Austria: CTO-on-Call desde 2.500 EUR al mes o un operador embebido a 1 a 2 días por semana, dos founders con nombre en cada engagement, cancelable cada semana.

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, y el cliente puede retener el pago hasta que la obra se acepte. Un contrato de Time & Material bajo el mismo marco es un Dienstvertrag, que solo obliga a esfuerzo. Los engagements a precio fijo de Wavect son contratos Werkvertrag.

Ejemplo de por qué los criterios de aceptación cargan con todo el contrato: un SoW que dice «construir la feature de reporting, debe funcionar bien» es inaplicable, porque «funcionar bien» es una opinión. Un SoW que dice «el endpoint /reports devuelve las cifras mensuales para el rango R en menos de 200ms bajo carga L, coincidiendo con los valores del spec S» es comprobable, y «hecho» deja de ser una negociación. El error de founder más común es firmar un SoW redactado de forma vaga para ahorrar tiempo al inicio, y luego pasar seis meses discutiendo si una feature a medio funcionar cuenta como entregada. Un proveedor que se resiste a escribir criterios de aceptación precisos está protegiendo su derecho a tener esa discusión más tarde.

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. Ojo a las capas: un MSA (Master Services Agreement) cubre el marco legal (IP, responsabilidad, jurisdicción) una vez, y muchos SoWs viven bajo él a lo largo del tiempo. El trade-off honesto es que un SoW apretado cuesta trabajo real de escribir y se siente lento al principio, que es exactamente el trabajo que una fase de discovery pagada existe para hacer. Relacionado: Fractional CTO Austria explica el modelo Werkvertrag en la práctica.

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. En derecho austríaco y alemán esto se corresponde con un Dienstvertrag: el proveedor debe esfuerzo y diligencia, no una obra terminada. Esa distinción legal es todo el juego, y es la razón por la que un Statement of Work (un Werkvertrag) es un instrumento fundamentalmente distinto, no solo otro estilo de facturación.

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 a los engagements T&M, lo que en esencia es reinventar un engagement a precio fijo sin los dientes legales.

Ejemplo de cómo se tuerce el T&M: un founder firma un contrato «T&M para mantener la flexibilidad» para una feature que todos ya habían acordado. Tres meses y 40k después está al 70%, la agencia propone otras seis semanas, y el founder no tiene ninguna palanca contractual que tirar porque nunca nombró un entregable. De haberse acotado el mismo trabajo como Werkvertrag, el problema del 70% habría sido del proveedor resolverlo a su coste.

Wavect usa T&M para engagements exploratorios donde el alcance no se puede definir de antemano. No lo usamos por defecto. El trade-off honesto es real: T&M es genuinamente el modelo correcto para investigación abierta o mantenimiento impredecible, donde forzar un alcance fijo solo nos haría inflar la estimación o discutir sobre «hecho». La regla práctica: usa T&M cuando nadie pueda aún describir el entregable, y cambia a un retainer o un SoW en cuanto puedan. 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 (derecho AT/DE) o su equivalente local más cercano. Un Werkvertrag obliga legalmente al proveedor a entregar la obra, no solo a aportar esfuerzo, y el cliente puede retener el pago hasta que la obra se acepte. «Precio fijo» como promesa verbal con un contrato Time & Material debajo no es precio fijo; es una línea de marketing. El SoW de base es donde la garantía vive o muere de verdad.

Ejemplo: un vendor cotiza «unos 25k, fijo» pero el SoW dice «pago mensual contra horas» y no lista criterios de aceptación. Eso es T&M con sombrero de precio fijo. La versión honesta nombra el entregable («flujo de checkout en producción, pasando los tests de aceptación A, B, C, para la fecha X»), declara el precio y pone el riesgo de sobrecoste en el proveedor. Si no lo quieren poner por escrito, el precio no es fijo.

Wavect trabaja a precio fijo para engagements con alcance bien definido donde el descubrimiento ya ha ocurrido. Para trabajo pre-descubrimiento hacemos primero una fase de discovery de 2 a 3 semanas, que en sí es a precio fijo. Su coste se descuenta de la factura del build si continúas con nosotros.

El trade-off honesto, y el error de founder más común: forzar precio fijo sobre un alcance genuinamente incierto. Cuando las incógnitas son grandes, un proveedor a precio fijo o infla la estimación un 30 a 100% para absorber el riesgo, o cotiza bajo y luego recorta calidad para no salirse del presupuesto. Ninguna de las dos te sirve. Haz discovery primero, fija el precio sobre lo que de verdad sabes, y mantén las partes genuinamente desconocidas en otro modelo. Nuestra garantía a precio fijo significa SoW firmado (Werkvertrag), obligado legalmente a entregar. No significa reembolso si se incumple el plazo.

Relacionado: Fractional CTO Austria publica precios fijos por nivel.

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 Statement of Work 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í. En Austria un retainer suele estructurarse como Dienstvertrag o freier Dienstvertrag, ya que lo que compras es disponibilidad y criterio reservados en vez de una obra fija.

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 para confirmar que la capacidad se está usando. Si la utilización está por debajo del 60 %, el retainer es la forma equivocada y conviene un SoW por engagement.

Ejemplo: una startup pone a un asesor senior en un retainer de 10 días al mes «por si acaso». Dos meses se usa entero; luego sale el lanzamiento y el trabajo cae a dos días al mes, pero la factura no. Ahora paga por ocho días ociosos. El arreglo no es cancelar la relación, es ajustarla a su tamaño: bajar a un retainer más pequeño más la opción de acotar un build a precio fijo cuando aparezca un entregable real. Los retainers sanos viven entre el 70 y el 85 % de utilización; por debajo compras un seguro, por encima del 95 % estás operando al proveedor como plantilla sin holgura para el trabajo que importa.

El trade-off honesto es previsibilidad frente a eficiencia. Un retainer te compra un coste mensual conocido y un cerebro senior reservado, a cambio de pagar por capacidad en los meses tranquilos. Relacionado: Fractional CTO Austria funciona como retainer semanal, cancelable cada semana, lo que elimina la mayor parte del lock-in que hace arriesgados a los retainers tradicionales.

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, el proveedor puede cotizar un precio fijo real y escribir un SoW defendible.

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 llevártelos a otro proveedor. Ese último punto es la prueba de un discovery honesto: el output debería servirte aunque te vayas.

Ejemplo de por qué importa: un founder reúne tres presupuestos «gratis» para la misma app y obtiene 30k, 70k y 110k. El abanico no es codicia del vendor, es que ninguno acotó de verdad el trabajo, así que cada uno infló para un conjunto distinto de incógnitas imaginadas. Un discovery pagado colapsa ese abanico reemplazando conjeturas por una arquitectura y un plan de milestones, que es también de lo que parte un SDLC honesto. Los mismos artefactos te dejan distinguir entre un MVP que envías en ocho semanas y una plataforma a la que te estás comprometiendo en silencio durante un año.

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. El trade-off honesto es que discovery se siente como gastar dinero antes de tener nada que enseñar. Sí tienes algo: los cuatro artefactos son un activo portátil, y la alternativa (comprometer seis cifras a un build que nadie acotó) es la opción cara, no la barata.

Relacionado: Fractional CTO Austria lista Discovery como uno de cuatro niveles de precio.

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. Un sprint sin demo es solo una fecha límite; un sprint sin retro es una cinta de correr.

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.

Ejemplo del fallo silencioso: un equipo corre «sprints» de dos semanas durante seis meses, acude a cada reunión de planificación y no envía nada en lo que un stakeholder pueda hacer clic. El consejo se sigue deslizando porque el trabajo se dimensiona por esperanza, no por lo que cabe, y no hay revisión que obligue al equipo a enfrentarse a un incremento funcional. El arreglo es brutal y simple: al final de cada sprint, alguien fuera del equipo tiene que poder usar lo construido. Si no puede, el ritmo es teatro, y encoger a sprints de una semana suele exponer por qué en una quincena.

El trade-off honesto y el error de founder más común: tratar los sprints como una forma de cumplir una fecha externa fija. El ritmo se construye en torno a fijar la caja de tiempo y flexibilizar el alcance, que es lo contrario de una fecha de lanzamiento dura con alcance fijo. Para trabajo genuinamente guiado por fecha y de alcance fijo quieres un plan a precio fijo con milestones explícitos de SDLC, no un sprint board. Los sprints encajan con la entrega agile continua y el trabajo iterativo hacia un MVP; encajan mal con investigación y diseño, donde una exploración con caja de tiempo y un resumen escrito supera a una demo forzada. También dependen de que el CI/CD esté sano, porque un sprint que no puede enviar al final no es un sprint.

El staff augmentation suma ingenieros externos a tu equipo existente. Participan en tus standups, trabajan tu backlog y siguen tus procesos. Tú conservas la gestión, las decisiones de arquitectura y la responsabilidad. El proveedor aporta personas y factura por tiempo. Ese es todo el modelo.

Encaja cuando tienes un equipo que funciona y un plan que funciona, y simplemente necesitas más manos en el teclado durante un tramo de trabajo conocido. Casi siempre se factura por time-and-material, así que el riesgo de entrega recae en ti. No encaja cuando aún no sabes qué construir, cuando nadie interno puede dirigir a los nuevos ingenieros, o cuando necesitas que alguien sea dueño de un resultado en lugar de ejecutar un ticket. Para responsabilidad sobre el resultado quieres un equipo dedicado o un rol senior fraccional, no augmentation.

La trampa de la seniority es lo que nadie pone en el folleto. La mayoría de los proveedores de augmentation anuncian perfiles senior y te asignan junior que necesitan la misma tutela que tus propios junior, solo que ahora pagas tarifas de agencia por el privilegio. Tú cargas con la sobrecarga de gestión y el proveedor no carga con ningún riesgo de entrega. Lee los CV nominales, entrevista a la persona real y pon una cláusula de sustitución en el contrato.

Hay un matiz legal austríaco que conviene señalar: el staff augmentation puede derivar en Arbeitskräfteüberlassung (cesión de mano de obra), que es un arreglo regulado con sus propias obligaciones sobre quién dirige al trabajador y cómo se le trata. Si un ingeniero «aumentado» queda plenamente integrado bajo tu dirección durante un periodo prolongado, la relación puede parecer legalmente más una cesión de personal que un contrato de servicios, con consecuencias para ambas partes. Rara vez es un problema en engagements cortos y bien acotados, pero conviene acertar con la forma del contrato en lugar de descubrir la clasificación durante una auditoría.

Wavect no funciona como una agencia de alquiler de personal. Somos operadores exclusivamente senior, así que cuando estamos dentro de tu equipo es la persona de la página de desarrollo de software quien hace el trabajo, no un nombre en una lista que se sustituye en silencio en la tercera semana.

La due diligence técnica es lo que un inversor o comprador serio encarga antes de que el dinero cambie de manos. Responde una pregunta directa: ¿la tecnología sostiene realmente la valoración o la historia es mejor que el código? Una revisión adecuada cubre la calidad y mantenibilidad del código, la arquitectura y si escala más allá del próximo orden de magnitud, la postura de seguridad, el estado de la suite de pruebas y el pipeline de entrega, la profundidad real del equipo y el riesgo de persona clave que reside en la cabeza de un solo fundador.

Para el lado comprador, la tech DD es fijar el precio del riesgo. No buscas código perfecto; toda empresa en esta etapa tiene deuda y un SDLC tosco. Buscas la brecha entre lo que afirma la presentación y lo que muestra el repositorio, y las minas que se convierten en emergencias tras el cierre: un único ingeniero que sabe cómo funciona todo, una licencia que envenena un producto comercial, un agujero de cumplimiento, una arquitectura que no sobrevive al crecimiento por el que pagas.

Para el lado vendedor, hacer tu propia tech DD antes de que la sala la haga por ti es una de las formas más baratas de proteger una valoración. Las sorpresas durante la diligence te cuestan poder de negociación; los hallazgos que ya entiendes y para los que tienes un plan, no. Los fundadores que hacen una revisión preventiva entran al data room con respuestas en lugar de explicaciones.

Ejemplo del único hallazgo que mueve un trato: el revisor de un comprador descubre que todo el núcleo de pagos y conciliación lo escribió un solo ingeniero que se fue hace ocho meses, está sin documentar y no tiene pruebas. Eso no es una nota al pie sobre calidad de código; es riesgo de persona clave que el adquirente fijará como un descuento o una retención, porque el día que algo se rompa en ese módulo, nadie actualmente en la empresa podrá arreglarlo con confianza. Un fundador que hubiera hecho su propia revisión lo habría visto venir y o bien documentado el módulo, pagado a un segundo ingeniero para aprenderlo, o al menos entrado a la sala con un plan de remediación creíble. El mismo hallazgo, sacado a la luz por el comprador en lugar de por ti, cuesta dinero real en el term sheet.

Wavect hace la due diligence técnica como operador senior, no como auditor de listas de verificación, la misma postura que llevamos a una fase de discovery pagada. La hemos hecho en ambos lados de la mesa, incluyendo plataformas intensivas en datos y reguladas, y escribimos hallazgos sobre los que un consejo no técnico puede actuar. Encaja de forma natural con nuestro trabajo de fractional co-founder y los mandatos de fractional CTO, donde la misma persona que evalúa el riesgo puede ayudar a corregirlo.

Una prueba de concepto existe para eliminar un riesgo técnico específico. ¿Puede este modelo alcanzar la latencia que necesitamos? ¿Funcionará realmente esta integración contra el sistema heredado? ¿Podemos demostrar la criptografía antes de diseñar un producto a su alrededor? Un PoC responde «¿es esto posible?» y nada más. Se construye rápido, se juzga por si funciona y luego se desecha.

La distinción que más cuesta a las empresas es PoC frente a MVP frente a prototipo. Un PoC responde «¿es esto técnicamente posible?» y va dirigido a tu propio equipo. Un prototipo responde «¿se siente bien?» y va dirigido al diseño y la usabilidad, a menudo sin backend real alguno. Un MVP responde «¿alguien lo usará y pagará por ello?» y es un producto real, lanzado a usuarios reales, solo acotado a la versión más pequeña que valga su tiempo. Tienen audiencias distintas, listones de calidad distintos y definiciones de terminado distintas, y la diferencia se proyecta directamente sobre dónde estás respecto al PMF.

El error común y caro es lanzar un PoC como si fuera producción. El código que demostró que algo era posible se escribió para demostrar que algo era posible: sin manejo de errores, sin pruebas, sin revisión de seguridad, atajos por todas partes. Cuando la demo impresiona a alguien y se decide «simplemente lanzarlo», heredas todo eso como tu cimiento. El movimiento honesto es tratar el PoC como la respuesta a una pregunta y luego construir lo real correctamente.

Una forma de que esa disciplina aguante bajo presión: escribe la única pregunta que el PoC existe para responder antes de empezar, y los criterios de un sí o un no. «¿Puede este modelo clasificar tickets de soporte con un 90 % de exactitud sobre nuestros últimos 500 tickets?» es una pregunta con un veredicto claro. Sin esa pregunta escrita, un PoC muta calladamente en un medio-producto, el equipo lo sigue puliendo porque «casi funciona», y te has deslizado a construir V1 sobre cimientos desechables sin que nadie lo decidiera. La pregunta escrita es también lo que te protege del tirón del coste hundido de lanzar el código desechable: una vez respondida la pregunta, el PoC ha hecho su trabajo y se ha ganado su borrado, por bonita que se viera la demo.

Wavect hace un PoC cuando existe un riesgo técnico genuino que vale la pena eliminar antes de comprometerse con una construcción. La mayoría de los proyectos no necesitan uno; necesitan una fase de discovery que acote el trabajo. Te diremos cuál de los dos casos tienes.

Un equipo dedicado es un escuadrón externo asignado a tu producto, con su propio líder técnico, dueño de un flujo de trabajo desde la planificación hasta la entrega. A diferencia del staff augmentation, no gestionas ingenieros individuales ticket por ticket. Tú fijas la dirección y las prioridades; el líder del equipo se encarga de la ejecución diaria, la coordinación interna y la entrega. El proveedor es dueño del resultado, no solo del tiempo invertido en alcanzarlo, por lo que normalmente se cobra como una tarifa mensual de capacidad o retainer en lugar de por horas.

Encaja cuando tienes un problema completo que delegar en lugar de un hueco que llenar: una línea de producto, una plataforma, un flujo de trabajo que puede operar con una interfaz clara hacia el resto de tu organización. Encaja cuando no tienes el ancho de banda interno de gestión para dirigir a contratistas individuales, porque el equipo se gestiona a sí mismo. No encaja cuando el trabajo está profundamente entrelazado con las decisiones diarias de tu equipo existente; ese entrelazado es exactamente para lo que sirve el staff augmentation.

El trade-off honesto es la interfaz. Un equipo dedicado reduce tu sobrecarga de gestión por ingeniero pero introduce una frontera de coordinación entre dos grupos que trabajan en un solo producto. Esa frontera te cuesta cada vez que las prioridades cambian rápido o el contexto necesita fluir constantemente a través de ella. Los equipos que hacen que funcione invierten en un único punto de contacto claro, una definición de terminado compartida y suficientes horas solapadas para mantener la frontera delgada.

El modo de fallo a vigilar es el equipo dedicado que lo es solo de nombre, calladamente repartido entre otros tres clientes. Pagas por capacidad reservada y un resultado con dueño; si los mismos ingenieros alternan entre tu producto y otros dos, no obtienes ni la propiedad ni el foco, solo augmentation con un margen. Pregunta quién está específicamente en el equipo, si están a tiempo completo en tu flujo de trabajo, y qué pasa con la continuidad si uno de ellos sale. Un equipo dedicado real tiene una membresía estable y un líder nombrado que carga con el contexto; uno falso tiene un reparto rotatorio y un jefe de proyecto reenviando tus mensajes.

Wavect mantiene los equipos pequeños y senior, de modo que el equipo dueño de tu flujo de trabajo son operadores que pueden tomar decisiones, no una capa de junior con un jefe de proyecto delante. Mira la página de desarrollo de software para ver cómo estructuramos la entrega.

El nearshoring significa externalizar el desarrollo a un proveedor en un país cercano, normalmente dentro de un par de zonas horarias. Para las empresas DACH eso suele significar Europa del Este en lugar del sur o sudeste asiático. Onshore es un proveedor en tu propio país a tus propias tarifas. Offshore es el extremo lejano: tarifas diarias más bajas, mayor brecha de zona horaria, cadena de comunicación más larga. Nearshore se sitúa en el medio y se vende como el punto óptimo: más barato que onshore, más fácil de trabajar que offshore.

El número anunciado es la tarifa diaria, y en la tarifa diaria nearshore gana. El número que nadie pone en la propuesta es el impuesto de coordinación: las horas perdidas por una superposición de zona horaria más corta de lo que parece, el retrabajo causado por especificaciones que viajan mal a través de una brecha de idioma y cultura, el tiempo senior de tu propio lado dedicado a revisar, corregir y volver a explicar. Un ingeniero más barato que necesita el doble de dirección y produce trabajo que tienes que rehacer no es más barato. El cálculo de la tarifa barata se rompe en el momento en que el trabajo necesita colaboración estrecha en lugar de tareas bien especificadas y autocontenidas.

El nearshore puede ser la decisión correcta. Para trabajo bien delimitado y claramente especificado, con requisitos estables y una interfaz delgada hacia tu equipo, el ahorro de tarifa es real y el impuesto de coordinación es pequeño, y el engagement suele tomar la forma de staff augmentation o un equipo dedicado. Se rompe para el trabajo ambiguo, de cambio rápido o profundamente colaborativo, que es precisamente el trabajo que la mayoría de las empresas en etapa temprana y guiadas por producto están haciendo en realidad. Sé honesto sobre cuál tienes antes de optimizar por la tarifa diaria.

Wavect es una consultora DACH: misma zona horaria, mismo idioma para las conversaciones que importan, personas senior que necesitan dirección una vez en lugar de tres. Cuando nos compares contra la tarifa nearshore, compara el coste total incluyendo el impuesto de coordinación, no la línea de la factura. Mira desarrollo de software para ver cómo trabajamos.

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 descentralizados, NFTs, DAOs, account abstraction, sistemas basados en 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.

Ejemplo de la decisión: un founder quiere una app de puntos de fidelidad y un pitch deck le dijo de ponerla «on-chain». Aplica tres pruebas. ¿Tienen los puntos que sobrevivir a la quiebra de la empresa? ¿Necesitan varias partes que no confían entre sí compartir el ledger sin un operador central? ¿Necesitan composability sin permiso con otros sistemas on-chain? Para un esquema de fidelidad de una sola empresa la respuesta es no, no y no, así que la herramienta correcta es una base de datos, y ponerlo en una blockchain solo añade costes de gas, tickets de soporte por gestión de claves y un dolor de cabeza regulatorio. Cambia una respuesta a sí (digamos, puntos canjeables entre comercios competidores) y el cálculo cambia.

El matiz austríaco y de la UE que los founders subestiman: un token que parece un instrumento de pago o un valor arrastra a MiCA, normas de folleto y tratamiento fiscal al alcance. «Descentralizado» no te exime, y el coste legal de equivocarte con la clasificación del token empequeñece el coste de ingeniería del contrato. Acótalo antes de escribir el smart contract, no después.

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. El trade-off es que la permanencia corta por ambos lados: la misma inmutabilidad que hace fiable a web3 significa que un bug enviado es un bug para siempre y que hay valor en juego desde el minuto uno. 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 para enviar un smart contract que los verifique.

Ejemplo donde ZK se gana el pan: un exchange regulado tiene que demostrar a un auditor que cada usuario pasó el KYC, sin entregarle una base de datos de nombres y números de pasaporte. Una prueba de conocimiento cero permite al exchange atestiguar «este conjunto de cuentas está plenamente verificado por KYC» mientras las identidades de base quedan privadas. En la UE, donde el RGPD convierte esa base de pasaportes en un pasivo que preferirías no tener, la privacidad no es un extra agradable, es el objetivo. El contraejemplo es igual de instructivo: si una consulta a una base de datos de confianza satisfaría al verificador, ZK es teatro caro.

El trade-off honesto de ingeniería, y el error de founder más común: suponer que la parte difícil es la criptografía. La matemática es sólida. El riesgo vive en el circuito. Un circuito sutilmente mal hecho produce una prueba que verifica perfectamente mientras demuestra la afirmación equivocada, y ese bug es invisible hasta que alguien lo explota. Por eso el trabajo ZK vive cerca de account abstraction y otras primitivas on-chain donde las auditorías son innegociables, no atornillado como feature de marketing. 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 y la mayoría de proyectos web3 que lo mencionan 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.

Ejemplo: una app de pagos de consumo quiere usuarios no nativos de cripto. Sin AA, el onboarding es «apunta estas doce palabras, piérdelas y tu dinero se va para siempre», lo que mata el funnel. Con AA, el usuario se registra con un passkey, la app patrocina las primeras transacciones para que nunca vea una comisión de gas, y un dispositivo perdido se recupera vía guardians en vez de seed phrase. El mismo patrón deja a la wallet aplicar un límite de gasto diario on-chain, el tipo de garantía que una app centralizada nunca podría hacer de forma creíble.

El error de founder común es tratar AA como un checkbox. Cambia el modelo de seguridad: la recuperación social elimina el footgun de la seed phrase para usuarios normales pero introduce el compromiso de guardians como una nueva clase de ataque, lo cual es estrictamente peor para power users que prefieren guardar la clave ellos mismos. El trade-off honesto es que AA compra UX mainstream a costa de más código de contract que auditar y más gas por acció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 código del contract. La misma disciplina de auditoría que aplica a los circuitos de zero-knowledge aplica aquí.

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) a menudo vía MCP, 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.

Ejemplo del fallo de producción más común: a un agent de soporte se le da un objetivo «resolver ticket» y un conjunto de herramientas. Un ticket mal formado lo manda a un loop donde llama a la misma herramienta de lookup decenas de veces, quema el presupuesto del modelo en una tarde y nunca llega a una resolución. El arreglo no es un prompt más listo, es ingeniería: un límite duro de pasos, un techo de coste y un circuit breaker que detiene el loop y escala a un humano. Cualquier cosa que escribe (manda un mensaje, hace un pago, borra un registro) lleva un gate con humano en el loop; los loops de solo lectura suelen poder correr desatendidos.

El trade-off honesto y el error de founder a evitar: los agents añaden no-determinismo, latencia y un radio de impacto mucho mayor que un pipeline fijo, a cambio de manejar tareas cuyos pasos no se pueden enumerar de antemano. La mayoría de flujos vendidos como «agénticos» son bien conocidos y se sirven mejor con un pipeline determinista y una o dos llamadas al LLM en medio, a menudo respaldados por RAG para fundamentación. La postura de Wavect: primero preguntar si IA es la herramienta adecuada aquí, después si un agent es la forma adecuada de IA para ello. Si puedes escribir los pasos, no dejes que el modelo los improvise.

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.

Ejemplo de la palanca: una empresa envuelve su CRM interno, su almacén de analítica y su repositorio de documentos como tres servidores MCP. Este trimestre el equipo está en Claude; el siguiente prueba otro modelo por coste. Con function-calling atado a un proveedor, ese cambio significa reescribir cada integración. Con MCP, apuntan el nuevo cliente a los mismos tres servidores y siguen. El coste de integración se pagó una vez, no por modelo. Emparejar esos servidores con RAG sobre el repositorio de documentos te da respuestas fundamentadas desde datos internos sin fontanería a medida.

El trade-off honesto y el error de founder: MCP es la jugada correcta solo si esperas cambiar de modelo o quieres portabilidad; si estás permanentemente con un proveedor, el function-calling plano es más simple y suficiente. El riesgo mayor es la seguridad. MCP es un protocolo de transporte, no un modelo de permisos. Un servidor MCP descuidado que expone una herramienta con capacidad de escritura y auth débil es un confused deputy esperando a ocurrir, donde se engaña al modelo para invocar algo que no debería. Construimos servidores MCP con regularidad y los hemos llevado a producción; también escribimos una revisión de seguridad para cada uno porque el estándar aún se mueve y el modo de fallo son tus sistemas internos, no un chatbot diciendo una tontería. Envolvemos una herramienta en MCP solo cuando es genuinamente útil dentro de un loop de modelo y el modelo de seguridad permite que un modelo la invoque, con humano en el loop para cualquier cosa destructiva.

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. Es la capa de fundamentación bajo la mayoría de AI agents útiles.

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.

Ejemplo del fallo clásico: una empresa construye un bot de soporte sobre sus docs de ayuda, la demo impresiona, y luego en producción cita con seguridad la política de reembolso equivocada. El instinto es culpar al modelo y probar uno más grande. Las respuestas siguen mal, porque el problema está aguas arriba: los docs se trocearon a mitad de frase, los embeddings no distinguen «reembolso» de «devolución», y no hay reranker que suba el pasaje correcto arriba. Mete mejor chunking, búsqueda híbrida y un reranker y el mismo modelo de pronto parece listo. La lección generaliza: cuando RAG se equivoca, sospecha de la recuperación antes que de la generación casi siempre.

El trade-off honesto y dónde se rompe RAG: brilla en preguntas tipo lookup contestables desde unos pocos pasajes, y se degrada cuando la respuesta exige sintetizar entre muchos documentos o reconciliar contradicciones en el corpus. En ese punto quieres un corpus curado más pequeño, un pipeline agéntico que razone por pasos, o fine-tuning, no un retriever más grande. La verdad poco sexy es que el 80 % del trabajo es hacer buena la recuperación (chunking, embeddings, reranking, búsqueda híbrida) y el 20 % el modelo. Envolver tus fuentes de datos como servidores MCP hace portátil la capa de recuperación, pero no la hace buena. 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.

Ejemplo de por qué la disciplina de despliegue difiere del software normal: envía un bug en un backend SaaS y lo parcheas y redespliegas en una hora. Envía un bug de reentrancy en un contract que custodia fondos de usuarios y un atacante puede vaciarlo antes de que reacciones, porque no hay rollback y el valor está vivo desde el bloque uno. Por eso la pregunta no es «¿deberíamos auditar?» sino «¿cómo estructuramos los upgrades de forma segura?». La respuesta habitual es un patrón proxy tras un timelock y un multisig: la autoridad de upgrade inmediata es un punto único de fallo, no tener camino de upgrade te deja atrapado con el primer bug, y los upgrades con timelock transparentes para los usuarios son el punto medio al que converge la mayoría de los sistemas en producción.

El trade-off honesto y el error de founder común: los founders tratan el contract como una feature y la auditoría como una línea opcional. Para cualquier contract que custodia valor no trivial, la auditoría es el seguro más barato que comprarás, normalmente 1 a 2 semanas del presupuesto del build contra todo el valor en juego. Wavect escribe smart contracts en Solidity para chains EVM y Rust para Solana, Near e ICP, y el lenguaje es consecuencia de qué chain exige tu caso de uso web3, no una preferencia. Recomendamos auditoría externa antes de mainnet en cualquier cosa que importe, y hemos entregado contracts auditados a producción. Saltarse la auditoría es como los equipos aprenden esto por las malas.

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.

Ejemplo de elegir una chain: un protocolo DeFi que necesita componer con contracts de lending y DEX existentes pertenece a Ethereum mainnet o a una L2 grande, donde vive ese ecosistema, aunque el gas sea mayor. Una app de consumo de alto volumen donde los usuarios no tolerarán comisiones de escala de dólar pertenece a una L2 como Arbitrum, Optimism o Base (mismo modelo de seguridad, una décima a una centésima del coste) o fuera de la EVM hacia Solana. La decisión es el trade-off seguridad-coste, no la chain con el marketing más ruidoso de este trimestre.

El trade-off honesto y el error que pilla a los equipos una y otra vez: compatible con EVM no es lo mismo que equivalente a Ethereum. Diferencias sutiles en precio de gas, precompiles, soporte de opcodes y comportamiento de consenso hacen que un contract que pasa en mainnet se rompa en una sidechain. La portabilidad es un punto de partida, no una garantía; vuelve a probar siempre por chain antes de desplegar. Las features de UX a nivel de cuenta como account abstraction también varían en madurez entre chains, así que confirma el soporte antes de prometerlo.

El trade-off más profundo es lo que cedes por comisiones baratas. Mover fuera de mainnet a una chain EVM más barata casi siempre significa heredar un modelo de confianza distinto: una sidechain como Polygon PoS corre su propio conjunto de validadores en vez de tomar prestada la seguridad de Ethereum, y un rollup añade un secuenciador del que ahora dependes y un retraso de retiro de vuelta a L1. Nada de eso aparece en la comparación de comisiones que un vendor pone en el deck. Decide qué necesita garantizar de verdad tu aplicación antes de optimizar por el coste por transacción. Para builds web3 usamos Solidity por defecto frente a Vyper por el tooling más amplio y la familiaridad de los auditores, salvo que haya una razón fuerte para nadar contra corriente.

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.

Ejemplo del gotcha que muerde a los equipos de EVM: el modelo de programación de Solana está basado en cuentas, no en estado-de-contract. Pasas explícitamente cada cuenta que toca una transacción, gestionas el rent de las cuentas, y piensas en ejecución paralela desde el principio. Un equipo con fluidez en Solidity rutinariamente subestima esta curva, envía código que funciona en el camino feliz, y luego choca con casos límite de propiedad de cuentas y rent que no tienen análogo en Ethereum. Presupuesta tiempo real para el cambio de modelo; no es una traducción de sintaxis.

El trade-off honesto, y el error de founder de «elegir la chain rápida y barata»: los requisitos de hardware de los validadores de Solana son más altos que los de Ethereum, así que el conjunto de validadores es más pequeño, e históricamente ha habido caídas de red (menos últimamente). Para pagos de consumo y apps de alto volumen ese trade-off suele estar bien y el throughput vale la pena. Para un sistema cuya promesa central es la resistencia a la censura, examina el modelo de amenaza con cuidado antes de suponer que Solana pasa el listón.

El coste de ecosistema es la otra mitad de la decisión. El DeFi profundo y componible y el tooling que viven en las chains EVM no existen todos en Solana, y cruzar activos por bridge es una operación no trivial y sensible a la seguridad por sí misma, no una importación gratis. Si tu producto necesita enchufarse a protocolos on-chain existentes, ese tirón hacia EVM es real y debe pesarse frente al rendimiento bruto de Solana. Si tu producto es mayormente autocontenido y limitado por throughput (pagos, apps de consumo, gaming), el rendimiento gana y el ecosistema más pequeño rara vez muerde. Wavect entrega tanto en Solana como en EVM por toda la pila web3. 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.

Ejemplo de dónde va de verdad el presupuesto, y el error que cometen los founders: ponen precio a los sensores y olvidan la cobertura. Una granja o un distrito urbano necesita gateways posicionados de forma que cada sensor llegue al menos a uno, y equivocarse significa zonas muertas, retransmisiones y baterías que se vacían en meses en vez de años. En un despliegue real el estudio de sitio y la colocación de gateways suele ser la mitad más difícil del proyecto, mucho después de haber aprobado el coste por unidad del sensor. Muros, terreno y silos metálicos se comen el alcance, y solo lo descubres midiendo en el sitio.

La otra decisión que los founders precipitan es quién es dueño de la red. Con LoRaWAN normalmente operas tus propios gateways, lo que significa nada de factura celular por dispositivo pero una responsabilidad real: operas los gateways, el network server y la cobertura. Las alternativas celulares (NB-IoT, LTE-M) invierten eso, la operadora es dueña de la cobertura allí donde llega, y pagas un plan de datos por dispositivo a cambio. Para un despliegue denso y fijo que controlas (un campus, una granja, un distrito urbano), ser dueño de la red suele ganar en coste a lo largo de la vida del dispositivo. Para un recuento bajo de dispositivos repartidos de forma impredecible entre regiones, pagar a la operadora es más barato que construir una cobertura que apenas usarás.

El trade-off honesto: LoRaWAN cambia ancho de banda y latencia por alcance y vida de batería, y ese intercambio es innegociable, no ajustable. Es la herramienta adecuada cuando necesitas muchos sensores en un área amplia con autonomía de años y solo envías unos pocos bytes de vez en cuando. Es la herramienta equivocada cuando necesitas mucho ancho de banda, baja latencia o conectividad por dispositivo que sigue al dispositivo; para eso, 5G NB-IoT o LTE-M suele encajar mejor. Decide en qué eje vive de verdad tu producto antes de comprometerte con la radio.

Un LLM es un modelo entrenado con enormes cantidades de texto para hacer una sola cosa: predecir el siguiente token (a grandes rasgos, el siguiente fragmento de palabra) a partir de todo lo anterior. Apila suficiente de esa predicción y obtienes respuestas fluidas, resúmenes, traducciones y código. Ese es todo el truco. No es razonamiento en el sentido humano, es una compleción de patrones muy buena.

Esto importa porque explica tanto la magia como los límites. Un LLM no tiene memoria de tu negocio, ni conocimiento más allá de su fecha de corte de entrenamiento, ni una garantía incorporada de que la respuesta fluida que produce sea verdadera. Afirmará un dato falso con exactamente la misma confianza que uno correcto. Ese modo de fallo tiene nombre, alucinación, y no es un bug que parchear, es lo que hace la predicción del siguiente token cuando no tiene fundamentación. Trátalo como una herramienta, no como un oráculo.

Ejemplo de la arquitectura correcta: una empresa quiere un asistente que responda preguntas sobre sus propios contratos. La construcción ingenua le pregunta al modelo en crudo y obtiene citas confiadas y equivocadas. La construcción que funciona envuelve el modelo: RAG recupera las cláusulas relevantes del contrato en tiempo de consulta para que las respuestas salgan de los documentos de la empresa y no de los datos de entrenamiento del modelo, la salida se valida contra un esquema, y cualquier cosa que dispare una acción legal pasa por un humano. El modelo no se volvió más listo; la ingeniería a su alrededor se puso seria.

El error de founder más común es echar mano de un modelo más grande para arreglar un problema de fundamentación, o echar mano de fine-tuning cuando lo que de verdad hace falta es recuperación. El fine-tuning cambia estilo y formato; no inyecta hechos de forma fiable, y queda obsoleto en cuanto tus datos cambian. El trade-off honesto: un LLM es la herramienta equivocada cuando necesitas resultados deterministas y auditables (cálculos fiscales, lógica regulatoria, cualquier cosa donde «casi siempre correcto» sea un riesgo), y la herramienta correcta para redacción, clasificación, extracción y búsqueda sobre tus propios datos. Usado en un loop agéntico puede actuar, no solo responder, lo que sube aún más las apuestas. Construimos exactamente este tipo de sistema fundamentado y validado bajo Inteligencia Artificial. Usado como fuente de verdad, un LLM es un riesgo lleno de confianza.

La ingeniería de prompts es la práctica de estructurar lo que envías a un LLM: la descripción de la tarea, los ejemplos, las restricciones, el formato de salida y el contexto. El modelo no tiene ni idea de lo que quieres hasta que se lo dices, y cómo se lo dices cambia el resultado drásticamente. Un prompt vago obtiene una respuesta vaga. Un prompt preciso con ejemplos y un esquema de salida definido obtiene algo que de verdad puedes lanzar.

El bombo lo enmarca como una habilidad mística. La realidad es más mundana y más útil: es ingeniería iterativa. Escribes un prompt, lo pruebas contra casos reales, ves dónde falla, ajustas las instrucciones o añades ejemplos, mides de nuevo. El prompt de sistema (las instrucciones permanentes que se sitúan por encima de cada mensaje del usuario) es donde vive la mayor parte del comportamiento duradero, así que ahí va el trabajo real.

Aquí está la parte honesta: la ingeniería de prompts es real, pero no es un foso de carrera. Las técnicas se aprenden en una semana, y los modelos siguen mejorando en entender prompts descuidados. Lo que no se convierte en commodity es saber a qué problema apuntar el modelo, conectarlo a un sistema real y evaluar si la salida es lo bastante buena para confiar en ella. Eso es ingeniería, y es lo que hacemos bajo Inteligencia Artificial.

Ejemplo del reparto parte-barata / parte-cara: un equipo consigue que un prompt de demo funcione de maravilla sobre cinco entradas elegidas a mano, declara la funcionalidad terminada y la lanza. En producción el mismo prompt falla con las entradas reales y desordenadas que nadie probó, porque no había una capa de RAG alimentándolo con el contexto correcto ni un arnés de evaluación midiendo con qué frecuencia se equivocaba. El prompt nunca fue la parte difícil. Conocer el presupuesto de la ventana de contexto del modelo, conectar la recuperación y medir la calidad de la salida en casos reales es el trabajo que de verdad lanza una funcionalidad fiable. Cuidado con cualquiera que venda la «ingeniería de prompts» como producto independiente: el prompt es la parte barata, y la parte cara es todo lo que lo rodea.

El fine-tuning toma un LLM preentrenado y lo entrena más con un conjunto curado de tus propios ejemplos, ajustando los pesos del modelo para que se incline hacia el comportamiento que demostraste. Lo usas para incorporar un tono consistente, un formato de salida específico, un vocabulario de dominio o una tarea que el modelo base maneja con torpeza. Cambia cómo responde el modelo, no a qué hechos tiene acceso.

La decisión que de verdad importa es fine-tuning frente a RAG, y la gente la entiende al revés constantemente. RAG inyecta hechos recientes y cambiantes en tiempo de ejecución recuperándolos de tus datos, así que la respuesta solo es tan actual como tu última actualización de documento. El fine-tuning enseña comportamiento duradero pero congela el conocimiento en el momento del entrenamiento, así que es la herramienta equivocada cuando tus hechos cambian, y tampoco frenará de forma fiable que el modelo invente cosas, ya que la alucinación se reduce con fundamentación, no con afinado. La regla general: ajusta para la forma, recupera para los hechos. Muchos sistemas reales usan ambos, un modelo afinado que responde con tu estilo propio, fundamentado por recuperación para los datos en vivo.

La realidad de los costes da menos miedo que antes pero sigue siendo real. Necesitas un conjunto de datos limpio y etiquetado (normalmente de cientos a miles de ejemplos), la propia ejecución del entrenamiento y el coste continuo de reafinar cada vez que el modelo base mejora o tus requisitos cambian. Ese último coste es el que los equipos olvidan. Un fine-tune no es un proyecto único, es un compromiso de mantenimiento.

Ejemplo de fine-tuning ganando de plano: una empresa necesita que cada respuesta del modelo vuelva como JSON estricto que coincida con un esquema interno, con un estilo de casa específico y conciso, a lo largo de millones de llamadas. El prompting puede lograrlo la mayoría de las veces, pero la respuesta mal formada ocasional rompe el sistema posterior, y meter la guía de estilo completa y el esquema en cada prompt quema tokens en cada llamada. Un fine-tune incorpora el formato y el tono en los pesos del modelo, de modo que las instrucciones ya no tienen que repetirse en el contexto, lo que hace las respuestas a la vez más fiables y más baratas por llamada a ese volumen. Ese es el punto óptimo: comportamiento duradero, alto volumen de llamadas y un formato que el prompting no acaba de clavar de forma consistente.

¿Cuándo gana el fine-tuning sin discusión? Cuando el prompting más la recuperación no pueden producir de forma fiable el formato o comportamiento que necesitas, y tienes suficientes ejemplos de alta calidad para enseñarlo. En la duda, agota primero el prompting y RAG, porque son más baratos de cambiar. Tomamos esta decisión de construir frente a afinar bajo Inteligencia Artificial.

Una base de datos vectorial almacena embeddings: representaciones numéricas de texto (o imágenes, o audio) donde el significado similar se asigna a puntos cercanos en el espacio. En lugar de coincidir con palabras clave exactas, incrustas la consulta del usuario de la misma manera y pides a la base de datos los vectores más cercanos. Eso es búsqueda por similitud, y es lo que permite a un sistema encontrar «cómo cancelo mi plan» cuando el documento en realidad dice «procedimiento de terminación de la suscripción».

En una canalización RAG esta es la capa de recuperación. La calidad de tus respuestas depende en gran medida de ella: buenos embeddings y buena búsqueda devuelven los fragmentos correctos para alimentar al LLM, los malos alimentan basura y el modelo resume esa basura con confianza. Por eso la recuperación, no el modelo, suele ser donde los proyectos RAG tienen éxito o fracasan.

Aquí está la parte que los proveedores se saltan: a menudo no necesitas una base de datos vectorial dedicada. Si tu corpus es pequeño (miles, no millones de fragmentos), una extensión vectorial sobre el Postgres que ya ejecutas (pgvector) es más simple, más barata y un sistema menos que operar. Si tu búsqueda es mayormente por palabras clave, la búsqueda de texto completo simple puede superar directamente a la búsqueda vectorial. Recurre a una base de datos vectorial especializada cuando la escala, la latencia o la búsqueda híbrida a gran volumen lo justifiquen de verdad, no porque esté en el diagrama de arquitectura.

Ejemplo de sobreingeniería de esto: un equipo que construye un asistente interno de documentos sobre unos pocos miles de páginas recurre a una base de datos vectorial gestionada, una canalización de embeddings separada y un servicio de reranking antes de tener un solo usuario. Ahora operan cuatro sistemas para responder preguntas que pgvector sobre su Postgres existente habría manejado, y cada uno es una cosa nueva que monitorizar, asegurar y pagar. La versión aburrida se lanza en una semana y escala bien hasta que el corpus es genuinamente grande. Recurre a la base de datos especializada cuando los números lo fuercen (millones de vectores, presupuestos de latencia estrictos, búsqueda híbrida de alto volumen), no porque el diagrama de arquitectura parezca más serio con ella.

Elegimos deliberadamente la opción lo bastante aburrida bajo Inteligencia Artificial, porque cada sistema adicional es una cosa más que mantener viva a las 3 de la madrugada.

Una alucinación es cuando un modelo genera algo que suena correcto y es incorrecto: una cita inventada, una API inventada, un hecho plausible pero falso. No es un fallo que puedas parchear. Un LLM predice texto probable, y una respuesta fluida que suena confiada es estadísticamente probable, sea o no cierta. El modelo no tiene una sensación interna de «no lo sé», así que llena el hueco con algo que encaja en el patrón.

Como es estructural, el encuadre honesto es la reducción del riesgo, no la eliminación. La mayor palanca es la fundamentación: dale al modelo los hechos reales en tiempo de ejecución mediante recuperación (RAG) para que responda a partir de texto fuente real en lugar de su conjetura del momento de entrenamiento. Ten en cuenta que el fine-tuning es la palanca equivocada aquí, ya que moldea el comportamiento en lugar de suministrar hechos. Restringe los formatos de salida para que haya menos margen para improvisar. Pide al modelo que cite fuentes que puedas comprobar. Y, de forma crítica, evalúa, construye un conjunto de pruebas de preguntas reales, mide con qué frecuencia el sistema se equivoca y trata ese número como una métrica de calidad que sigues como cualquier otra.

Aquí es donde la IA se encuentra con el QA, y la mayoría de los equipos se lo saltan. Lanzar una funcionalidad de LLM sin un arnés de evaluación es lanzar código no probado y llamarlo terminado. Necesitas conocer tu tasa de fallos antes de que tus usuarios la encuentren por ti. Lo tratamos como innegociable bajo Software Quality Assurance.

Ejemplo de por qué el arnés de evaluación es innegociable: un equipo lanza un asistente de documentos legales tras probarlo a mano con una docena de preguntas, todas las cuales se veían geniales. En producción cita con confianza una cláusula que no existe en el contrato subido, un usuario actúa sobre ella, y ahora hay un riesgo real. El arnés que lo habría atrapado es poco glamuroso: unos pocos cientos de preguntas reales con respuestas correctas conocidas, ejecutadas en cada cambio, produciendo un solo número, el porcentaje que el sistema acertó mal. Sin él no conoces tu tasa de fallos, lo que significa que tus usuarios la descubren por ti, una mala respuesta cada vez. Con él, puedes decidir si la tasa es aceptable para lo que está en juego antes de lanzar.

El ángulo de la confianza es todo el juego en dominios regulados o de alto riesgo. Una alucinación en un chatbot que recomienda una película es un encogimiento de hombros. La misma alucinación en una salida financiera, legal o médica es un riesgo. Ajusta las barreras de seguridad al coste de equivocarse, y nunca dejes que una respuesta fluida sustituya a una verificada.

La ventana de contexto es la memoria de trabajo del LLM para una sola petición, medida en tokens (un token es aproximadamente tres cuartos de una palabra). Todo tiene que caber dentro de ella: tu prompt de sistema, el historial de la conversación, cualquier documento que pegues y la respuesta que genera el modelo. Si superas la ventana, el modelo literalmente no puede ver el desbordamiento.

“Simplemente pon todo en el prompt” falla por tres razones incluso cuando la ventana es grande. Primero, el coste: la mayoría de los proveedores cobran por token, así que meter un documento enorme en cada llamada multiplica la factura. Segundo, la latencia: más tokens significa una respuesta más lenta. Tercero, y menos obvio, la calidad, los modelos atienden de forma menos fiable a la información enterrada en medio de un contexto muy largo, así que más no siempre es mejor. Un prompt enfocado a menudo supera a uno hinchado.

Esta es exactamente la razón por la que existe RAG. En lugar de volcar todo tu corpus en la ventana, recuperas solo el puñado de fragmentos relevantes para cada pregunta y envías solo esos. Obtienes el beneficio de una gran base de conocimiento sin pagar por procesarlo todo en cada petición. La ventana de contexto es el presupuesto; la recuperación y una buena ingeniería de prompts son cómo lo gastas con sensatez.

Ejemplo del efecto «perdido en el medio» que sorprende a los equipos: una empresa pega un documento de política de 40 páginas en el prompt y hace una pregunta cuya respuesta está en la página 20. El modelo, con el documento entero técnicamente dentro de su ventana, igual se equivoca, porque la atención se degrada para el material enterrado en medio de un contexto largo. El mismo modelo, al que se le entregan solo los dos párrafos relevantes que la recuperación extrajo, responde correctamente. Las ventanas más grandes no arreglaron el problema; un contexto mejor dirigido sí. Esta es la parte contraintuitiva que los founders pasan por alto cuando un nuevo modelo sale con un tamaño de ventana que acapara titulares: más capacidad no es más fiabilidad.

La conclusión práctica: trata la ventana de contexto como un recurso escaso con etiqueta de precio, no como espacio gratis. Las ventanas más grandes bajan la presión pero no la eliminan, y el coste y la latencia siguen escalando con lo que metes. Diseñamos en torno a ese presupuesto de forma deliberada bajo Inteligencia Artificial.

Una blockchain es una base de datos con dos propiedades inusuales. Primero, es solo de adición: puedes añadir registros pero no reescribir los que ya están sin que todos los participantes lo noten. Segundo, ninguna parte la controla en solitario. Una red de nodos ejecuta el mismo software y acuerda el siguiente bloque mediante un mecanismo de consenso (prueba de trabajo, prueba de participación o una variante con permisos). El resultado es un libro contable en el que varias partes pueden confiar sin confiar entre sí.

Hay dos tipos amplios. Una blockchain pública (Ethereum, Bitcoin, Solana) es abierta: cualquiera puede leerla, ejecutar un nodo o realizar transacciones, y es donde viven los sistemas de smart contracts y la pila web3 más amplia. Una blockchain privada o con permisos restringe quién participa, lo que normalmente significa que has reconstruido una versión más lenta y compleja de una base de datos normal con pasos adicionales. Si una empresa controla todos los nodos, no tienes una ventaja de blockchain, tienes un sistema distribuido que ahora debes operar.

Ejemplo de la pregunta que lo zanja: una empresa de logística quiere una blockchain «para que los socios puedan confiar en los datos de envío». Recorre las tres pruebas. ¿Tienen los registros que sobrevivir a la quiebra de la empresa? En realidad no, la empresa es la que opera la red. ¿Necesitan partes que desconfían mutuamente compartir estado sin un operador? Más cerca, pero en la práctica una parte es claramente el centro y todos los demás se conectan a ella. ¿Necesitan composabilidad sin permisos con otros sistemas on-chain? No. Así que lo que de verdad quieren es una base de datos compartida bien gestionada con permisos, un registro de auditoría y entradas firmadas, que es más barata, más rápida y algo que su equipo existente puede operar. El pitch de blockchain estaba resolviendo un problema de confianza que una firma y una réplica de lectura ya resuelven.

La postura honesta: la mayoría de los proyectos que se presentan como necesitados de una blockchain no la necesitan. Una blockchain justifica su complejidad solo cuando necesitas activos que sobrevivan a la quiebra del operador, estado compartido entre partes que no confían entre sí, o composabilidad sin permisos. Todo lo demás es una base de datos. Cuando una cadena pública es la decisión correcta, las comisiones y el throughput suelen empujar la construcción hacia una Layer 2 en lugar de la capa base. Hemos entregado sistemas blockchain reales y hemos disuadido a más clientes de los que construimos. Nuestro trabajo en blockchain empieza por si la necesitas siquiera.

Una Layer 2 es una blockchain que toma prestada su seguridad de una Layer 1 (normalmente Ethereum) en lugar de ejecutar su propio consenso desde cero. La L2 ejecuta transacciones fuera de la cadena base, las agrupa y publica el resultado de vuelta en L1. La mayoría son compatibles con EVM, así que los mismos contratos Solidity y el mismo tooling se trasladan. Los usuarios obtienen las garantías de seguridad de Ethereum a una fracción del coste y con un rendimiento mucho mayor. Las L2 existen porque el espacio de bloque en la capa base es escaso y caro: cuando Ethereum está ocupada, una simple transferencia puede costar más que lo que se transfiere.

El diseño dominante es el rollup, que viene en dos variantes. Los rollups optimistas (Arbitrum, Optimism, Base) asumen que las transacciones son válidas y permiten una ventana de impugnación durante la cual cualquiera puede disputar un lote fraudulento. Los rollups ZK usan una prueba de conocimiento cero para demostrar matemáticamente que cada lote es válido antes de que aterrice en L1, lo que elimina el retraso de impugnación a costa de una infraestructura de pruebas más pesada. El optimista es hoy más simple y barato de construir; ZK es hacia donde se dirige la tecnología.

El detalle que sorprende a los usuarios y quema a los founders que no lo planificaron: los retiros de vuelta a L1. En un rollup optimista, la ventana de impugnación significa que mover fondos de la L2 a Ethereum mainnet puede tardar alrededor de una semana, salvo que pagues a un «bridge rápido» de un tercero para que adelante la liquidez. Un consumidor que depositó en segundos y espera retirar en segundos no va a leer tus docs sobre ventanas de prueba de fraude; va a pensar que tu app está rota o le está robando el dinero. Si construyes sobre una L2 optimista, la experiencia de retiro es un problema de producto que tienes que diseñar desde el día uno, no un detalle de implementación.

Wavect ha entregado en producción sobre una L2 (Boba Network), incluido su modelo de cómputo híbrido que permite que un smart contract llame a código fuera de la cadena durante la ejecución. Ese patrón es potente para llevar datos del mundo real o cómputo pesado a un contrato, y es genuinamente difícil de operar de forma segura. Si un proveedor presenta un despliegue en L2 como una victoria de escalado gratuita, pregunta cómo funcionan los retiros a L1, cuál es el retraso de finalidad y quién opera el secuenciador. Nuestro trabajo en blockchain cubre la selección y el despliegue de L2.

DeFi reemplaza al intermediario de una transacción financiera por código. En lugar de un bróker que casa operaciones, un exchange descentralizado (DEX) usa un creador de mercado automatizado: un smart contract que mantiene dos activos en un fondo y fija el precio de los intercambios mediante una fórmula. En lugar de un banco que decide quién obtiene un préstamo, un protocolo de préstamos permite a cualquiera pedir prestado contra una garantía que bloquea en un contrato, a menudo una stablecoin, con tipos de interés fijados algorítmicamente por la oferta y la demanda. Nadie te aprueba; el contrato simplemente ejecuta.

La verdadera innovación es la composabilidad. Como cada protocolo es un contrato público en la misma cadena, encajan entre sí como Lego. Una posición en un protocolo puede ser garantía en otro, que puede envolverse y negociarse en un tercero, todo en una sola transacción. Esto es algo que la pila financiera tradicional, con sus APIs amuralladas y sus retrasos de liquidación, no puede hacer. También es la razón por la que los fallos de DeFi se encadenan: cuando una pieza se rompe, todo lo apilado sobre ella se rompe también.

Los riesgos son reales y específicos. Riesgo de smart contract: un fallo vacía el fondo, y no hay devolución de cargo. Riesgo de oráculo: los protocolos dependen de fuentes de precios, y un oráculo manipulado permite a un atacante pedir prestado contra garantías falsas.

El riesgo que los founders más subestiman es el regulatorio, no el técnico. En la UE, un negocio que construye sobre raíles de DeFi u ofrece servicios adyacentes a DeFi puede caer bajo MiCA, las obligaciones antiblanqueo (AML) y los requisitos de licencia de los que «descentralizado» no te exime. Los reguladores miran cada vez más quién controla y se beneficia realmente de un protocolo, no el marketing. Si tu modelo asume que la naturaleza sin permisos de DeFi significa cero carga de cumplimiento, presupuesta una revisión legal antes de lanzar, porque equivocarte con la clasificación es mucho más caro que el trabajo del contrato. Hemos entregado infraestructura de pagos que toca los raíles de DeFi (Scramble), y nuestra posición es que DeFi es potente para el estrecho conjunto de casos de uso que necesitan finanzas componibles y sin permisos, y una carga para todos los que lo usan como un casino de rendimiento. Nuestro trabajo en blockchain empieza por cuál de los dos eres.

Una DAO es una forma de dirigir un colectivo donde las reglas de membresía, votación y gasto viven en smart contracts. La tesorería es una billetera en cadena que solo libera fondos cuando una propuesta supera una votación. El poder de voto suele seguir las tenencias de tokens o la membresía. La promesa es que la coordinación se vuelve transparente y a prueba de manipulaciones: cualquiera puede auditar la tesorería, cada voto queda registrado y ningún firmante puede vaciar los fondos en silencio. Es una de las pocas primitivas web3 cuyo valor no depende del precio de un token.

Las DAO funcionan bien para un trabajo específico: gestionar una tesorería compartida en cadena donde los miembros no confían plenamente entre sí y necesitan reglas verificables sobre quién puede gastar qué. Los clubes de inversión, la gobernanza de parámetros de protocolo y la financiación de subvenciones son encajes reales. Construimos la lógica de gobernanza y tesorería en cadena para FTW DAO, donde la estructura justifica su complejidad porque hay dinero real agrupado entre partes.

El estatus legal es la parte que la mayoría de los pitches de DAO pasan por alto, y en Austria y la UE en general importa. Una DAO no es una forma jurídica reconocida. Salvo que los miembros la envuelvan en una entidad real (una GmbH, una asociación, una fundación), un tribunal puede tratar a los participantes como una sociedad con responsabilidad solidaria, lo que significa que un miembro podría responder personalmente por las obligaciones del colectivo. «El código es la organización» es un principio de ingeniería estupendo y uno legal peligroso. Cualquier DAO que toque dinero real o contrapartes reales necesita una envoltura legal real bajo los smart contracts, decidida antes del lanzamiento, no tras la primera disputa.

Donde las DAO se vuelven teatro: gobernanza sobre decisiones que en realidad no están en cadena, votación ponderada por tokens que concentra el poder en un puñado de ballenas, y «gobernanza comunitaria» que es una etiqueta de marketing sobre un equipo que aún controla las claves de administrador. Si las decisiones difíciles siguen tomándose en un chat privado y la votación es un sello de goma, tienes una empresa normal con un disfraz de DAO. Te diremos cuál estás construyendo. Mira nuestro trabajo en blockchain.

Un NFT es un estándar de token de smart contract (ERC-721 en Ethereum es el común) para activos que no son intercambiables. Un dólar es fungible: cualquier dólar es tan bueno como otro. Una escritura de una casa concreta no lo es. Un NFT es el equivalente en cadena de esa escritura: un registro único atado a una dirección de propietario, transferible y verificable por cualquiera. Lo que el token representa realmente es una decisión de diseño, y gran parte de la cuestión del valor depende de acertar con esa decisión.

La distinción honesta es entre utilidad y especulación. Utilidad real: propiedad tokenizada de un activo del mundo real (RWA), un derecho de acceso que da paso a un servicio o evento, una credencial de membresía, o un objeto dentro de un juego que el jugador controla de verdad. En estos casos el NFT hace un trabajo que una fila de base de datos no puede, porque el propietario puede transferirlo o venderlo sin permiso y sobrevive al emisor. Construimos mecánicas respaldadas por NFT para LivLive, donde el token da paso a experiencias del mundo real en lugar de servir como objeto de colección.

Un detalle que rompe calladamente los proyectos de NFT ingenuos: el token en cadena suele ser solo un puntero, y aquello a lo que apunta a menudo vive en un servidor web normal. Si ese servidor cae o la empresa deja de pagarlo, el NFT «permanente» ahora apunta a la nada, un enlace de imagen rota respaldado por una blockchain. Los proyectos que se toman en serio la reclamación de propiedad almacenan el activo referenciado en almacenamiento direccionado por contenido como IPFS o directamente en cadena, de modo que aquello que el token representa sobrevive tanto como el token. Si un proveedor no sabe decirte dónde vive el activo real y quién lo mantiene con vida, la permanencia es marketing.

El caso de la especulación es la mayor parte del mercado: un token que apunta a un JPEG cuyo único valor es que el próximo comprador pague más. No hay nada técnicamente malo en ello, pero es un mercado de coleccionables con liquidación en blockchain, no una herramienta de productividad. Si un proveedor presenta NFT para tu negocio, la pregunta es siempre la misma: ¿qué le permite hacer el token al titular que una base de datos no puede, y necesita esa propiedad sobrevivir a tu empresa? Nuestro trabajo en blockchain empieza ahí.

Una crypto wallet no guarda monedas; las monedas viven en la blockchain. La billetera guarda la clave privada que las controla, y la usa para firmar transacciones que mueven o gastan activos. Ese es todo el juego: quien tiene la clave tiene los activos. Pierde la clave y los fondos desaparecen sin línea de recuperación; filtrala y un atacante vacía la cuenta al instante. La mayoría de las billeteras respaldan la clave como una frase semilla de doce palabras, que es la forma legible por humanos de ese único punto de fallo.

La primera bifurcación es custodial frente a autocustodia. Una billetera custodial (una cuenta de exchange) guarda la clave por ti, como un banco guarda tu dinero: cómoda, recuperable por soporte y solo tan segura como la empresa y solo tan disponible como su solvencia. Una billetera de autocustodia pone la clave en manos del usuario: nadie puede congelar ni incautar los activos, y nadie puede ayudar cuando el usuario pierde la frase semilla. Este compromiso, entre control y red de seguridad, es el problema de UX que define todo el espacio.

Una línea regulatoria que conviene entender, porque cambia tus obligaciones por completo: una billetera genuinamente de autocustodia, donde solo el usuario puede mover fondos y tú nunca tocas sus claves, en general te mantiene fuera de los regímenes de licencia de transmisor de dinero y de custodia que rigen a los exchanges. En el momento en que tu producto puede mover fondos del usuario, guardar claves o intervenir para recuperarlas, puedes haber cruzado a territorio custodial con todo el peso de licencia, KYC y antiblanqueo (AML) que eso conlleva. Las funciones de recuperación son justo donde esto se vuelve sutil: un esquema de «recuperación social» en el que tu empresa es uno de los guardianes se ve muy distinto ante un regulador que uno en el que solo los contactos elegidos por el usuario tienen partes. Diseña el modelo de recuperación teniendo en mente la clasificación legal, no solo la UX.

La abstracción de cuentas es la solución más creíble. Al convertir la billetera misma en un smart contract, puedes añadir recuperación social (guardianes de confianza restauran el acceso), transacciones sin gas, límites de gasto y registro por correo y passkey en lugar de una frase semilla. Hemos entregado billeteras de autocustodia en producción, incluidas Scramble y MetaMask Snaps, y nuestra opinión es que las billeteras de solo frase semilla son un callejón sin salida para los usuarios web3 masivos. La historia de recuperación debe resolverse antes de que una persona no técnica deba tener un valor significativo. Mira nuestro trabajo en blockchain.

Una stablecoin es un token que intenta mantenerse vinculado a un activo estable, casi siempre el dólar estadounidense. El objetivo es conservar la velocidad de liquidación y el alcance global de una blockchain sin la volatilidad que hace inútiles a Bitcoin o ETH como unidad de cuenta. Puedes tener, enviar y recibir una stablecoin como correo electrónico para el dinero: final en segundos, transfronterizo, sin un banco en medio. Ese es el caso de uso genuino, especialmente para pagos y remesas hacia y desde regiones con infraestructura bancaria débil.

Cómo se mantiene la vinculación define el riesgo. Las stablecoins respaldadas por fiat (USDC, USDT) mantienen dólares reales y bonos del tesoro en una cuenta bancaria y acuñan un token por dólar. La vinculación es solo tan buena como las reservas y la honestidad del emisor, por lo que las atestaciones de reservas importan. Las stablecoins colateralizadas con cripto (DAI) sobrecolateralizan con activos en cadena, intercambiando riesgo de custodia por riesgo de liquidación en una caída del mercado, y son la espina dorsal de la mayoría del préstamo en DeFi. Las stablecoins algorítmicas intentan mantener la vinculación con mecánicas de oferta y sin respaldo real, y el cementerio (Terra/UST, miles de millones evaporados) es la razón por la que los operadores serios las evitan.

El panorama regulatorio de la UE es ahora concreto, no teórico. Bajo MiCA, las stablecoins (tokens de dinero electrónico y tokens referenciados a activos) están explícitamente dentro del alcance, con requisitos de reserva, divulgación y autorización del emisor, y las normas limitan cómo pueden usarse las stablecoins no euro para pagos cotidianos a escala dentro del bloque. Para cualquier negocio que construya flujos de pago sobre raíles de stablecoin en Austria o la UE en general, la pregunta ya no es «¿esto está permitido?» sino «¿qué moneda, emitida por quién, bajo qué autorización?». Esa es una decisión de diseño que tomar antes de escribir la integración, porque adaptar el cumplimiento a un producto de pagos ya lanzado es el camino caro.

Construimos infraestructura de pagos sobre raíles de stablecoin (Scramble) y trabajamos en sistemas adyacentes a las stablecoins (Zybra), así que la posición está fundamentada: las stablecoins son la primitiva web3 más genuinamente útil para mover valor, y la vinculación nunca es gratis. Conoce siempre qué respalda la moneda, quién puede congelarla y qué ocurre en una corrida. Nuestro trabajo en blockchain trata el modelo de vinculación como una decisión de diseño de primer orden.

Microservices significa dividir una aplicación en muchos servicios pequeños, cada uno dueño de una parte del negocio y cada uno desplegable por su cuenta. En lugar de un programa donde todo corre en el mismo proceso, obtienes una flota de servicios que se hablan entre sí por la red. La promesa es real: los equipos pueden entregar de forma independiente, puedes escalar solo las partes que lo necesitan, y un servicio puede fallar sin llevarse abajo todo el sistema.

El coste también es real, y suele subestimarse. En el momento en que tus llamadas a funciones se convierten en llamadas de API por la red, tienes un sistema distribuido, y los sistemas distribuidos son difíciles. Heredas fallos de red, latencia, datos repartidos entre muchas bases de datos sin transacciones fáciles, versionado entre servicios y la carga operativa de ejecutar, monitorizar y depurar muchas piezas móviles en lugar de una, lo que sube el listón de la madurez de tu CI/CD. Un error que antes era una traza de pila ahora es una traza a través de cinco servicios y tres colas.

La postura honesta: la mayoría de las startups deberían empezar con un monolito. Una sola aplicación bien estructurada es más rápida de construir, mucho más fácil de depurar y perfectamente capaz de llevarte hasta ingresos reales. Te divides en microservices cuando tienes una razón concreta, un equipo lo bastante grande como para que una sola base de código sea un cuello de botella, o una carga que genuinamente necesita escalado independiente, no porque los microservices sean la respuesta de moda. Los microservices prematuros son la forma en que los equipos pequeños convierten un problema difícil en diez.

Polity corría sobre siete microservices, y esa fue la decisión correcta para su escala y su estructura de equipo. Ese es el punto: la arquitectura debe seguir al problema y al organigrama, no a una charla de conferencia. Elige los límites donde de verdad reducen el acoplamiento, y acepta que cada límite que dibujas es una llamada de red que ahora tienes que defender.

Una API es la forma definida en que una pieza de software habla con otra. Dice: aquí están las cosas que puedes pedirme que haga, aquí está exactamente cómo lo pides, y aquí está lo que recibes de vuelta. Todo el sentido es que quien llama no necesita saber cómo se hace el trabajo internamente, solo qué enviar y qué esperar. La app del tiempo de tu teléfono no sabe cómo funciona el servicio meteorológico. Solo conoce la API, envía una petición y recibe un pronóstico.

La idea clave es el contrato. Ambos lados se ponen de acuerdo sobre la forma de las peticiones y las respuestas, y mientras ese contrato se mantenga, cada lado puede cambiar sus interioridades libremente. Esa misma disciplina de contrato es lo que mantiene unida una arquitectura de microservices, y es la idea que MCP estandariza para que los modelos de IA puedan llamar a herramientas sin pegamento a medida. Los dos estilos comunes de los que oirás hablar son REST, que modela todo como recursos que lees y escribes mediante peticiones web estándar y es el predeterminado para la mayoría de los backends web y móviles, y GraphQL, que permite a quien llama pedir exactamente los campos que quiere en una sola petición. Ambos son solo formas disciplinadas de definir el mismo contrato.

El diseño de API es una de las decisiones más duraderas que tomas. El código interno lo puedes refactorizar en un fin de semana. De una API pública depende el software de otras personas en su forma exacta, así que cambiarla rompe sus integraciones, lo que significa que a menudo no puedes cambiarla en absoluto sin un doloroso ejercicio de versionado. Una API limpia, bien nombrada y consistente envejece bien. Una descuidada se convierte en un impuesto permanente que pagas en cada cambio futuro. Tratamos el diseño de API como una parte de primera clase del desarrollo de software, no como una ocurrencia tardía atornillada al final.

La opinión honesta: la mayoría de las quejas de «la integración es una pesadilla» se remontan a una API diseñada con prisa para entregar una funcionalidad, y luego forzada a cargar con diez. Invierte el tiempo en el contrato pronto. Es la parte que menos podrás cambiar después.

SaaS es un modelo de entrega y de negocio, no una tecnología. En lugar de venderte una copia del software para que lo instales y ejecutes tú mismo, el proveedor lo aloja, lo opera y te da acceso a través de la web por una tarifa recurrente. Inicias sesión, lo usas, nunca tocas los servidores. Salesforce, Slack y Notion son SaaS. El cliente alquila capacidad en lugar de comprar y mantener software.

El rasgo técnico definitorio es la multiinquilinidad (multi-tenancy): un solo sistema en ejecución sirve a muchos clientes a la vez, con sus datos aislados entre sí. Esa única decisión moldea todo. Diseñas para el aislamiento y la seguridad entre inquilinos, para desplegar actualizaciones a todos a la vez sin romper a nadie, y para escalar a medida que se añaden clientes en lugar de entregar una nueva versión una vez al año. Que ese escalado viva en un monolito o en microservices es una decisión aparte que debería seguir a la carga, no a la moda. También cambia la operación, porque el proveedor ahora carga con la disponibilidad, las copias de seguridad y la seguridad como una responsabilidad continua, no el cliente.

El modelo de negocio es la otra mitad. Los ingresos son una suscripción, normalmente mensual o anual, lo que significa que la relación no termina con la venta, empieza ahí. Las métricas que importan pasan a ser los ingresos recurrentes, la rotación (churn) y el coste de servir a cada cliente. El precio suele ligarse al valor o al uso: por asiento, por nivel o por volumen. Si te equivocas con el modelo de precios, un producto técnicamente excelente igual pierde dinero con cada cliente, así que el precio es una decisión de arquitectura tanto como de ventas.

Construimos productos SaaS de principio a fin, desde la arquitectura multiinquilino hasta la aplicación web en la que los clientes inician sesión, normalmente partiendo de un MVP y endureciéndolo una vez que el producto encuentra el PMF. Polity es un producto SaaS. La parte honesta que los fundadores subestiman: el modelo recurrente significa que te apuntas a una responsabilidad permanente por disponibilidad, seguridad y soporte, lo cual es un coste operativo real, no una construcción de una sola vez.

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 apilados encima.

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.

Ejemplo de la diferencia: dos equipos corren sprints de dos semanas. El Equipo A hace demo, ve que la feature que nadie del roadmap predijo es la que los usuarios de verdad clican, y reordena el siguiente sprint en torno a ella. El Equipo B hace demo, anota el feedback en un doc, y sigue con el plan que escribió en enero porque el plan es el plan. El Equipo A es agile. El Equipo B tiene ceremonias agile y cerebro de cascada. Las ceremonias son idénticas; solo difiere la disposición a actuar sobre la evidencia, y eso es todo el partido.

El trade-off honesto y el error de founder: agile no es licencia para saltarse la planificación, y no es gratis. Cambia previsibilidad a largo plazo por aprendizaje rápido, que es exactamente lo equivocado cuando el alcance, la regulación o un contrato de interfaz genuinamente no pueden cambiar (dispositivos médicos certificados, aviónica, cierto hardware). Incluso ahí los principios originales aplican dentro del equipo; el proceso de cara al público solo se parece más a cascada. Wavect es agile en el sentido original: trabajamos en ciclos cortos, hacemos demos a menudo, nos apoyamos en CI/CD para que enviar sea barato, y estamos dispuestos a tirar 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 y una suite de TDD se escribe para aparentar en vez de para tener confianza.

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. La disciplina solo paga cuando esos tests corren en cada cambio, por eso TDD y CI/CD son hermanos, no preocupaciones separadas.

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.

Ejemplo de dónde TDD se gana su coste frente a dónde es teatro: un módulo de conciliación de pagos tiene casos límite peliagudos (reembolsos parciales, redondeo de divisa, reintentos). Escribir el test que falla primero te obliga a declarar el comportamiento esperado antes de que exista el código, y la suite atrapa la regresión seis meses después cuando alguien «simplifica» el redondeo. Eso es TDD pagándose solo. Ahora contrasta un script de importación de datos desechable que borrarás en dos semanas: escribir tests primero ahí es puro overhead. La regla honesta es hacer TDD del código pesado en lógica y caro de equivocar y no del resto.

El error más común es tratar la cobertura como un objetivo. Persigue el 90 % y el equipo escribe tests para getters y setters para llegar al número mientras se salta los tests de integración donde viven los bugs reales. La cobertura es un diagnóstico útil y un objetivo terrible; es una métrica que se manipula. Wavect usa TDD donde paga: tests de integración para todo lo que tenga forma de dinero, tests de contrato para todo lo orientado al cliente, tests de aceptación estilo BDD donde producto necesita leerlos, tests unitarios para lógica no trivial. Probamos bien las partes difíciles, no todas las partes por igual, y lo tratamos como una práctica dentro de un loop agile sano en vez de una casilla que marcar.

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.

Ejemplo de dónde esto de verdad paga: un producto de seguros tiene una regla por la que una reclamación de menos de 30 días con una póliza válida se aprueba automáticamente. Escrito como escenario Gherkin («Dada una póliza activa durante 30 días, Cuando se presenta una reclamación dentro de la ventana de cobertura, Entonces se aprueba automáticamente»), el product owner y el revisor de compliance pueden leerlo, confirmar que coincide con la regla real y atrapar el off-by-one antes de que se envíe. Esa verificación en lenguaje compartido es todo el valor de BDD, y vive en la capa de aceptación e integración donde la brecha entre lo que producto quiso decir y lo que ingeniería construyó es donde nacen los bugs.

Hay también un coste de mantenimiento que los equipos descubren tarde. Los escenarios Gherkin se apoyan sobre una capa de «step definitions», código pegamento que mapea cada línea en lenguaje plano a acciones de test reales. Ese pegamento es software real que hay que mantener en sincronía a medida que el producto cambia, y una suite BDD grande con step definitions descuidadas se vuelve su propia carga de mantenimiento, lenta de correr y frágil de editar. El beneficio (un stakeholder puede leer y firmar el comportamiento) solo paga ese overhead cuando un stakeholder de verdad los lee. Si el Gherkin lo escriben ingenieros, lo leen ingenieros y nadie más lo ve nunca, estás pagando por una capa de traducción sin audiencia.

El trade-off honesto y el error común: BDD no sustituye a TDD, es una capa encima, y aplicarlo en todas partes es el error. Escribir «Dados dos números, Cuando los sumo, Entonces obtengo la suma» para una función trivial es ceremonia que ningún stakeholder de negocio leerá jamás. Reserva Gherkin para los tests que un no-ingeniero genuinamente necesita firmar, y usa tests unitarios planos por debajo de esa línea. Como todas estas prácticas, BDD es una etapa dentro de un SDLC sensato y una herramienta para un problema real de comunicación, no un proceso a adoptar por sí mismo.

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.

Ejemplo: un founder está convencido de que su hipótesis es «los usuarios pagarán por conciliación automática de facturas». El instinto es pasar tres meses construyendo el motor de conciliación. El MVP más barato que prueba la hipótesis real es manual: una landing page, un precio y un humano haciendo la conciliación a mano entre bastidores (un MVP tipo Mago de Oz). Si nadie paga por la versión manual, el motor habrían sido tres meses desperdiciados. El build solo arranca una vez probada la disposición a pagar, que es justo el tipo de des-arriesgar para el que existe una fase de discovery.

Hay un matiz de financiación austríaco que conviene conocer. aws Preseed y subvenciones similares suelen enmarcarse en torno a alcanzar un milestone de «prototipo» o «MVP», y los founders a veces dejan que la definición de la subvención dicte el build, rellenando el MVP con features que marcan una casilla de financiación en vez de probar una hipótesis. Usa el dinero para aprender más rápido, no para construir un MVP más pesado de lo que el aprendizaje requiere. La subvención premia un milestone; el mercado premia una suposición validada, y no siempre son el mismo artefacto.

El fallo más común es 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 es la más arriesgada, y la mayoría de MVPs son obsoletos antes de enviarse. El trade-off honesto: un MVP deliberadamente infra-construye, así que parecerá poco impresionante junto a la cosa pulida de tu cabeza, y esa incomodidad es el precio de aprender rápido. Si la fase de build supera las 8 a 12 semanas, no estás construyendo un MVP, estás construyendo V1 con un nombre más amable. Wavect corre ciclos agile cortos hacia un MVP y nombra la hipótesis antes de poner alcance al build. Relacionado: Fractional CTO Austria cubre el liderazgo del MVP de principio a fin.

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 de verdad. Después del PMF las preguntas se vuelven operativas: escalar el equipo, endurecer el stack, controlar el burn.

Ejemplo del error pre-PMF más caro: un equipo levanta una ronda seed, contrata cuatro ingenieros y pasa nueve meses construyendo una plataforma de microservicios multi-región respaldada por Kubernetes «para poder escalar». Escala a cuarenta usuarios, se queda sin pista, y la arquitectura que construyeron para millones nunca la prueban cientos. El fallo opuesto es más raro pero real: un equipo encuentra el tirón, sale en prensa, y el único servidor sobrecargado se cae durante la única semana en que todo el mercado miraba. La decisión de ingeniería es enteramente función de en qué lado de la línea de PMF estás, por eso nombrar la línea con honestidad importa más que cualquier decisión de stack.

El trade-off honesto que los founders esquivan: admitir que estás pre-PMF se siente como admitir el fracaso, así que los decks describen un calvario de venta cliente a cliente como «tracción temprana». Si la adquisición sigue siendo una pelea y el churn es lo bastante alto como para que el boca a boca no pueda sostener el crecimiento, estás pre-PMF da igual lo que diga el deck, y la jugada correcta es seguir enviando el MVP más barato que resuelva la siguiente incertidumbre en vez de construir para una escala que no te has ganado. Una fase de discovery te ayuda a nombrar la suposición más arriesgada; un operador fraccional puede evitar errores técnicos caros durante la búsqueda, pero no puede sustituir la obsesión incansable del founder con el cliente que de verdad produce el tirón. Después del PMF normalmente necesitas un CTO, no un cofundador. Ver Fractional CTO Austria.

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

Ú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»).

Ejemplo de la etapa que todos se saltan: una startup construye tres servicios internos en dos años, los envía y sigue adelante. Nadie es dueño de «operar» y nadie planificó «retirar». Dieciocho meses después dos de los tres servicios siguen corriendo, nadie recuerda por qué, el único ingeniero que los entendía se ha ido, y desactivar cualquiera de los dos podría romper algo o no. Ese es el coste no facturado de saltarse la mitad de atrás del ciclo. El arreglo es barato si se hace al principio (nombrar un dueño, escribir un plan de deploy y de desmantelamiento) y caro si se descubre después.

La metodología que elijas decide sobre todo cuán rígidas son las fronteras entre etapas. Un SDLC en cascada las corre estrictamente en secuencia con firmas en cada puerta; un SDLC agile entrelaza diseño, build y test de forma continua y revisita etapas anteriores a medida que aprende. Las etapas son el mismo conjunto en cualquier caso, que es la idea útil: discutir «agile contra cascada» es en realidad discutir cuán permeables deberían ser las fronteras, y la respuesta correcta depende de cuánto pueden cambiar todavía tus requisitos.

El trade-off honesto y el error común: los founders oyen «SDLC» y o lo sobre-formalizan en un proceso con puertas y firmas que mata la velocidad, o lo descartan como teatro de empresa y se saltan las etapas poco glamurosas. La postura correcta es tratarlo como una lista de cosas que deben ocurrir en algún sitio, no una secuencia por la que marchar. La forma preferida por Wavect: una fase de discovery pagada al inicio, diseño y build entrelazados en ciclos cortos, TDD y CI/CD 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, automáticamente. Los tres son una escalera de madurez, no sinónimos.

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.

Ejemplo de la palanca escondida en la velocidad del pipeline: un equipo tiene un pipeline de CI que tarda 25 minutos. Los ingenieros dejan de correrlo en local, agrupan sus cambios y mergean por esperanza para evitar la espera. Los bugs se acumulan entre merges y el dolor de integración que el equipo adoptó CI para evitar vuelve en silencio. Recorta ese pipeline a menos de 10 minutos para el inner loop y los ingenieros lo corren constantemente, atrapan problemas mientras el contexto está fresco, y todo el loop agile se aprieta. La velocidad del pipeline no es un extra agradable; es un multiplicador de fuerza en el día de cada ingeniero.

El trade-off honesto y el error común: los founders piden «CI/CD completo» como si fuera un solo interruptor, cuando CI es sobre todo tooling y CD es sobre todo disciplina. CI lo tienes en una tarde. La Continuous Delivery de verdad exige una suite de tests en la que el equipo confíe tras un hábito de TDD, un camino de rollback medido en minutos, y alguien de guardia para responder cuando un deploy prende fuego a algo. Wavect entrega cada proyecto con CI configurado desde el día uno como parte de un SDLC sensato; la configuración de CD depende de si el proyecto tiene la cobertura 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 (la espina dorsal de CI/CD). 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.

Ejemplo de elegir por servicio, no por empresa: el mismo negocio corre un sitio de marketing y un libro mayor de pagos. El sitio de marketing es un gran encaje para Continuous Deployment completo, donde un mal deploy significa una errata y un rollback es trivial, así que cada build verde puede enviarse desatendido. El libro mayor de pagos se queda en Continuous Delivery con un humano pulsando el botón, porque ahí un mal deploy mueve dinero de forma incorrecta y el humano aporta señal de verdad, no solo latencia. Tratar «¿deberíamos automatizar los deploys?» como una sola decisión para toda la empresa es el error; es un juicio de riesgo por servicio.

Hay una dimensión regulatoria que conviene nombrar. En dominios con requisitos de control de cambios o auditoría (finanzas, salud, cualquier cosa que toque datos personales bajo RGPD), el paso de aprobación humana en Continuous Delivery no es solo gestión de riesgo, es a menudo el control documentado que un auditor espera ver: quién aprobó esta release, contra qué evidencia, cuándo. Los equipos en esos contextos no deberían perseguir Continuous Deployment completo como una medalla de madurez; la puerta manual es una feature de la que depende su historia de compliance. Automatiza todo hasta el botón, luego deja el botón donde lo necesite el rastro de auditoría.

El trade-off honesto: Continuous Delivery te compra la mayor parte de la velocidad de la automatización completa manteniendo un veto humano sobre el paso irreversible, a costa de que ese veto sea un cuello de botella si el humano es lento o falta. El prerrequisito para graduarte más allá es real, no aspiracional: una suite respaldada por TDD tras la que el equipo enviará, un rollback de minutos y no de horas, y una rotación de guardia. Sin esos tres, «Continuous Delivery» es un botón que nadie se atreve a pulsar, y el pipeline es decoración sobre un SDLC por lo demás sano.

Scrum es una implementación de los principios de agile, con tres roles, tres artefactos y un puñado de eventos. El Product Owner decide qué se construye y en qué orden. El Scrum Master elimina los bloqueos y protege el proceso. Los desarrolladores lo construyen. Los artefactos son el product backlog (todo lo que podría construirse, normalmente escrito como historias de usuario), el sprint backlog (a lo que se compromete este sprint) y el incremento (lo que realmente se entrega). Los eventos son la planificación del sprint, el daily standup, la revisión del sprint y la retrospectiva.

Donde Scrum ayuda de verdad: en equipos que luchan con el foco y la visibilidad. El sprint fijo obliga a un compromiso real, la revisión obliga a una demo real y la retro obliga al equipo a mirar su propio proceso en lugar de ignorarlo. Para un equipo que nunca ha entregado a un ritmo, Scrum es un andamiaje útil.

Donde se convierte en teatro: cuando los eventos sobreviven pero la sustancia muere. Un standup que es un informe de estado para el manager. Una revisión sin software funcional que mostrar. Una retro que produce las mismas tres acciones cada quincena y no actúa sobre ninguna. Muchos equipos de «Scrum» ejecutan las ceremonias y no obtienen ningún valor. Si haces las reuniones pero no puedes demostrar un incremento funcional, no tienes Scrum, tienes un hábito de reuniones.

Ejemplo de la trampa de la sobrecarga: un equipo de cinco personas adopta Scrum al pie de la letra y acaba con planificación del sprint, un daily standup, una sesión de refinamiento del backlog, una revisión del sprint y una retro cada dos semanas. En un equipo de ese tamaño, esa carga de ceremonias puede comerse la mayor parte de un día a la semana por persona, y la precisión de planificación que compra se desperdicia porque un equipo de cinco ya sabe qué hace cada uno. El marco se diseñó para coordinar equipos que habían perdido esa visibilidad; imponerlo entero a un equipo que nunca la perdió es puro impuesto. La solución no es abandonar los bucles de retroalimentación (conserva la demo y la retro) sino dejar caer las ceremonias de coordinación que resuelven un problema que no tienes.

La visión honesta de Wavect: Scrum es un buen marco de inicio y una mala religión. Conserva las partes que crean retroalimentación y descarta las que crean sobrecarga. La mayoría de los equipos maduros derivan hacia algo más ligero, a menudo más cercano a Kanban, una vez que la disciplina se interioriza.

Kanban tiene dos ideas centrales: hacer visible el trabajo y limitar el trabajo en curso. Pones cada elemento en un tablero con columnas para cada etapa (por hacer, en curso, revisión, hecho) y limitas cuántos elementos pueden estar a la vez en cada columna activa. Cuando una columna está llena, nadie empieza trabajo nuevo hasta que algo sale. Ese límite es todo el sentido: obliga al equipo a terminar cosas antes de empezar más.

El contraste con Scrum es el ritmo. Scrum agrupa el trabajo en sprints fijos y replanifica en cada límite. Kanban no tiene sprints. El trabajo se extrae de forma continua a medida que se libera capacidad, y puedes cambiar prioridades en cualquier momento sin esperar a que termine un sprint. No hay ceremonia de compromiso, no hay revisión de sprint, no hay caja artificial de dos semanas. Ambos son implementaciones del mismo objetivo agile: retroalimentación estrecha y la capacidad de cambiar de rumbo según la evidencia.

Elige Kanban cuando el trabajo llega de forma impredecible y dirigida por interrupciones (soporte, operaciones, equipos de plataforma), o cuando un equipo es lo bastante maduro como para que el andamiaje del sprint se haya vuelto pura sobrecarga. Elige Scrum cuando un equipo necesita el ritmo y la revisión forzada para construir disciplina de entrega, o cuando las partes interesadas necesitan un ritmo de demo predecible para planificar.

Ejemplo de lo que un límite de WIP le hace de verdad a un equipo: una columna «en curso» limitada a tres, en un equipo de cinco, significa que dos personas a veces no tendrán nada propio que empezar. La reacción instintiva es que esto es desperdicio, ingenieros ociosos. Es lo contrario. Esos dos se ven ahora obligados a ayudar a terminar las tres cosas ya en curso, revisar el trabajo de un compañero o emparejarse en el bloqueo, en lugar de abrir una cuarta tarea y dispersar más al equipo. La incomodidad de una columna llena es el mecanismo funcionando: convierte «todos ocupados, nada enviándose» en «menos cosas en curso, cosas que de verdad se terminan». Los equipos que no toleran ese breve ocio suben calladamente el límite hasta que deja de restringir nada, y luego se preguntan por qué el throughput no mejoró.

La versión honesta: los límites de WIP son donde está el valor, y también son la parte que los equipos ignoran calladamente. Un tablero Kanban sin límite de WIP es solo una lista de tareas con columnas extra. Si el equipo está empezando cinco cosas y no termina ninguna, el límite es la solución, no un tablero más grande.

La deuda técnica es una metáfora, y buena. Cuando tomas un atajo para entregar más rápido (un hack rápido en lugar del diseño limpio, un valor codificado a mano en lugar del sistema de configuración), pides prestado tiempo ahora y lo devuelves más tarde como intereses: cada cambio futuro en esa zona es más lento, más arriesgado y más molesto. Como la deuda financiera, no es automáticamente mala. Es una herramienta.

Tomar deuda deliberadamente suele ser la decisión correcta. Antes del ajuste producto-mercado, la velocidad le gana a la elegancia, porque la mayoría de lo que construyes se va a tirar de todas formas. Construir una arquitectura impecable para un producto que quizá no exista en seis meses es su propia forma de desperdicio, que es toda la lógica de lanzar un MVP. La jugada correcta es con frecuencia tomar el atajo, entregar, aprender y pagar la deuda una vez que sabes que la cosa vale la pena conservar.

El peligro no es la deuda. El peligro es la deuda invisible. La deuda deliberada y documentada (“codificamos esto a mano, aquí está el ticket para arreglarlo antes de escalar”) es un pasivo gestionado, y un pipeline de CI/CD sano más un SDLC sensato son lo que la sacan a la luz antes de que se acumule. La deuda no documentada que nadie decidió tomar, que simplemente se acumuló por las prisas y la rotación, es la basura que estrangula calladamente una base de código. La velocidad cae, nadie sabe decir por qué, y cada estimación se duplica. Para cuando es visible en las métricas, los pagos de intereses llevan un año acumulándose.

La postura de Wavect: la deuda es un compromiso deliberado, no un fallo moral. Con gusto tomamos deuda para llegar a una ventana de tiempo, y anotamos exactamente qué tomamos y qué costará devolverlo. La conversación que nos negamos a saltar es aquella en la que alguien paga intereses y nadie ha nombrado el préstamo. Mira nuestro trabajo de desarrollo full-stack para ver cómo mantenemos explícito este compromiso.

DevOps surgió como reacción a una disfunción concreta: los desarrolladores lanzaban el código por encima de un muro a un equipo de operaciones separado, a operaciones se le culpaba cuando se rompía, y el ciclo de retroalimentación entre escribir software y operarlo estaba roto. DevOps cierra ese ciclo. El equipo que construye el software también lo entrega y lo opera, y el dolor de operar algo fluye directamente de vuelta a las personas que pueden arreglarlo.

En la práctica, esa cultura se habilita mediante automatización: CI/CD para que los cambios fluyan a producción de forma segura y frecuente, disciplina de continuous delivery para que cada build sea enviable, infraestructura como código para que los entornos sean reproducibles en lugar de copos de nieve hechos a mano, y observabilidad (logs, métricas, trazas, alertas) para que el equipo vea qué hace realmente producción. Ninguna de estas herramientas es DevOps por sí sola. Son lo que hace que la cultura sea sostenible.

El título de «ingeniero DevOps» es en gran medida un nombre equivocado, y revelador. DevOps no es un rol que contratas para sentarse entre desarrollo y operaciones, eso solo reconstruye el muro con un nombre nuevo. Lo que la mayoría de las ofertas de «ingeniero DevOps» quieren en realidad es un ingeniero de plataforma o infraestructura que construye la automatización que usan otros desarrolladores. Persona útil, etiqueta equivocada. Si tu organización tiene un equipo DevOps que se encarga de los despliegues para que los desarrolladores no tengan que hacerlo, tienes operaciones con un cambio de marca, no DevOps.

Ejemplo de «tú lo construyes, tú lo operas» funcionando como debe: un ingeniero lanza un cambio el jueves, recibe una alerta a las 2 de la madrugada del viernes cuando provoca una fuga de memoria lenta, y pasa la madrugada arreglando su propio código. Eso es desagradable una vez. También es el sistema de revisión de código más eficaz jamás inventado, porque ese ingeniero nunca volverá a lanzar esa clase de bug, y la próxima vez que diseñe algo pensará en cómo se comporta a las 2 de la madrugada. Cuando un equipo de operaciones separado absorbe ese dolor en su lugar, la persona que podría prevenir la siguiente fuga nunca siente la consecuencia de la última, y los mismos errores se repiten indefinidamente. La alerta no es un castigo; es el bucle de retroalimentación.

La visión de Wavect: DevOps es una forma de trabajar, no un departamento. Construimos la automatización que permite a un equipo pequeño responsabilizarse de su software de principio a fin, y tratamos «tú lo construyes, tú lo operas» como el valor por defecto. Mira nuestro trabajo de desarrollo full-stack para ver cómo se traduce esto en la práctica.

Waterfall ejecuta un proyecto como una secuencia ordenada de fases: reunir todos los requisitos, luego diseñar todo el sistema, luego construirlo, luego probarlo, luego desplegarlo. Cada fase produce un documento aprobado y termina antes de que empiece la siguiente. El atractivo es obvio: conoces el plan, el coste y la fecha por adelantado, y todos están de acuerdo antes de escribir una línea de código.

Aún encaja legítimamente en cierto trabajo. Cuando el alcance es genuinamente fijo y bien entendido, cuando un regulador exige documentación y trazabilidad por adelantado, o cuando construyes hardware donde no puedes iterar barato después de cortar el metal, las fases secuenciales son el modelo honesto. Fingir que un proyecto así es «ágil» solo esconde el plan en lugar de eliminarlo.

El ángulo contractual es donde Waterfall y Agile chocan de forma más concreta. Un Werkvertrag a precio fijo, bajo el derecho austríaco y alemán, necesita un entregable definido al que obligar al proveedor, lo que empuja de forma natural hacia un alcance con forma de cascada, plenamente especificado. El trabajo genuinamente iterativo, donde esperas que los requisitos cambien a medida que aprendes, encaja mejor en un Dienstvertrag o un retainer. Los founders se meten en líos cuando quieren a la vez la certeza legal del precio fijo y la flexibilidad de agile: esas dos tiran en direcciones opuestas. La resolución honesta suele ser hacer un discovery a precio fijo para fijar suficiente alcance sobre el que fijar un precio, y luego ejecutar el build con la permeabilidad de fronteras que la incertidumbre restante de verdad justifique.

Falla gravemente en el descubrimiento de producto. La suposición fatal es que puedes especificar el producto correcto por adelantado, antes de que ningún usuario lo haya tocado. Casi nunca puedes. Para cuando termina la fase de construcción, los requisitos reunidos meses antes son en parte erróneos, y Waterfall no tiene una forma barata de descubrirlo hasta la fase de prueba, cuando cambiar cualquier cosa es caro. Obtienes un producto que coincide con la especificación y se salta la necesidad.

La distinción honesta respecto a Agile: Waterfall concentra todas las decisiones al principio y apuesta a que son correctas. Agile (ya se ejecute como Scrum o como un flujo más ligero) reparte las decisiones a lo largo del trabajo y apuesta a que la retroalimentación temprana atrapará las equivocadas. En cualquier caso, ambos son solo elecciones de secuenciación sobre las mismas etapas de SDLC subyacentes. Para cualquier cosa donde aún no sepas exactamente qué construir, esa apuesta favorece a Agile. Para cualquier cosa donde la respuesta sea genuinamente conocida y fija, la previsibilidad de Waterfall es una virtud, no un defecto.

Una historia de usuario captura una pieza de valor desde la perspectiva de la persona que la quiere, normalmente con el formato «Como [rol], quiero [objetivo], para que [beneficio]». Es la unidad que la mayoría de los equipos agile usan para llenar un backlog de sprint. El formato no es burocracia por sí misma. El «como» te obliga a nombrar quién quiere esto realmente, y el «para que» te obliga a declarar el porqué, que es la parte que los equipos se saltan y entonces construyen lo equivocado. Una historia es un marcador de posición para una conversación, no un contrato.

Las buenas historias suelen cumplir los criterios INVEST: Independent (se puede construir por sí sola), Negotiable (los detalles quedan abiertos hasta que los discutes), Valuable (entrega algo que le importa a un usuario o comprador), Estimable (el equipo puede dimensionarla), Small (cabe dentro de una iteración) y Testable (puedes saber cuándo está hecha). En los dos últimos es donde se desmoronan la mayoría de las historias: demasiado grandes para terminar, o escritas de forma tan vaga que nadie sabe decir qué significa «hecho».

Los criterios de aceptación son cómo una historia se vuelve comprobable, y escribirlos en forma de BDD Given/When/Then es la manera más limpia de hacerlo. Son las condiciones concretas que deben cumplirse para que la historia se acepte, escritas antes de que empiece el trabajo. «Como usuario quiero restablecer mi contraseña» es una intención. Los criterios de aceptación (un enlace de restablecimiento expira tras una hora, un token inválido muestra un error claro, un restablecimiento con éxito inicia la sesión del usuario) son contra lo que el equipo realmente construye y prueba.

El antipatrón común es la historia que es una tarea disfrazada. «Como desarrollador quiero añadir un índice a la tabla de pedidos» lleva puesto el disfraz de historia de usuario, pero no hay usuario ni beneficio, solo una tarea de ingeniería con sombrero. Está bien rastrearla, pero no es una historia de usuario, y disfrazar tareas técnicas de historias borra calladamente la perspectiva del usuario que el formato existe para proteger.