← Volver a todos los artículos
Casos de Éxito

MintID ha renovado por el doble del presupuesto inicial. Este es el trabajo que hay detrás.

Por Equipo de Conectia·12 de agosto de 2026·8 min de lectura

Un caso de estudio escrito por el proveedor vale lo que valga el dato que lo cierra. El nuestro: MintID abrió este engagement con un presupuesto de 200.000 €. A la vista del trabajo entregado, ha firmado un nuevo engagement de 400.000 € másuna renovación del doble de tamaño y del doble de compromiso.

El trabajo que hay debajo de esa cifra: tres ingenieros y un delivery manager, todos en nómina de Conectia, integrados en el build de MintID desde marzo de 2026 y a pleno ritmo en abril. El mismo squad ha construido el núcleo del protocolo y, desde julio, sus tres SDKs verificadores — TypeScript, PHP, Python — todos probados. Cada entregable llegó en su fecha. Cero bugs.

Escribimos desde el lado de quien entrega, y conviene decir lo evidente: vendemos squads integrados, y este engagement es nuestro. Lo que lo mantiene honesto es que los datos que soportan el peso no dependen solo de nosotros — la reseña de cinco estrellas del cliente es pública y está escrita con sus palabras, y la ingeniería está documentada en nuestro recorrido por los SDKs verificadores. Aquel post cuenta el qué. Este cuenta cómo se entregó.

El código más delicado de MintID corre en máquinas que MintID no verá nunca

Casi todo el protocolo vive en territorio que MintID controla: una especificación congelada, el consenso en Go, el núcleo de credenciales anónimas en Rust. En ese perímetro se fueron los primeros meses del squad — construyendo el núcleo de la propia herramienta, a partir de la arquitectura del cliente. Los SDKs verificadores son el primer artefacto que sale del perímetro. Corren dentro de los stacks de los integradores, sobre infraestructura que el protocolo nunca poseerá, exactamente en el punto donde sus garantías se cumplen o se rompen en silencio.

Eso los convierte en una compra difícil, por razones que no tienen nada que ver con el volumen:

  • Nueve condiciones de aceptación corren siempre al completo — vinculación al origen, nonce fresco, comprobación de la política solicitada, estado vigente del emisor — sin ningún camino parcial que las esquive.
  • La vida de una presentación es una constante en el código, no un ajuste que un integrador pueda estirar.
  • No hay ninguna superficie de política. Ningún verifyPartial(), ningún skipOriginCheck. El sistema de tipos no puede expresar un verificador más débil.
  • Un solo núcleo de verificación con tres lenguajes encima. TypeScript, PHP y Python son ergonomía; el pipeline de aceptación de debajo es una sola implementación con un solo comportamiento.

Cero ajustes es una propiedad preciosa en una especificación y despiadada a la hora de construir contra ella. Todos los atajos a los que un ingeniero cansado podría echar mano se han eliminado por diseño, así que el código tiene que salir bien a la primera. Como lo dijo el cliente en su reseña: «nuestro proyecto es un sistema complejo de protocolo blockchain para identidad Know Your Agent en la era agéntica, así que no cualquier desarrollador de software puede asumir este reto.»

Respondimos con cuatro personas en nómina propia, con el match hecho en una semana

La forma del equipo fue tres ingenieros y un delivery manager, con el match hecho directamente contra el brief y no un pipeline de CVs para que el arquitecto de MintID lo cribara. El squad que se presentó es el squad que entregó.

Tres hechos estructurales lo hicieron posible, y son los mismos tres en cada engagement que llevamos:

  1. Los ingenieros están empleados directamente por Conectia — en 2 países, con contratos exigibles y cesión de IP, no una cadena de contractors de marketplace. Cuando el código en cuestión es el más delicado de un protocolo, «quién emplea legalmente a quien lo toca» deja de ser una formalidad de compras.
  2. La validación la lideran CTOs. El filtro es criterio de producción y no palabras clave de un CV — que es exactamente lo que pone a prueba un codebase de cero ajustes.
  3. El match se cierra en 72 horas, sin fee de reclutamiento. En este engagement el equipo entero ya estaba trabajando en menos de una semana, y es la parte con la que el cliente decidió abrir su reseña: «Conectia nos dio un equipo de trabajo altamente técnico con una gestión de proyecto sobresaliente en una semana.»

La relación arrancó en marzo de 2026 con el núcleo del protocolo; la fase de SDKs verificadores — el primer entregable dirigido a integradores, y el que está documentado en público — corre desde julio. Un squad que ha construido el núcleo es también el squad que quieres escribiendo el código que hace cumplir las garantías del núcleo en otro sitio.

El squad corre solo; la arquitectura cruza la frontera cada sprint

El modelo de trabajo es fino a propósito. Con el cliente hay una sola ceremonia fija: un check-in semanal. Todo lo demás es una frontera trazada una vez y respetada.

Qué cruza esa frontera, cada sprint:

  • Entra: la arquitectura de alto nivel, que entrega el arquitecto de MintID, Marc Miró i Rierola, al empezar el sprint.
  • Lo lleva el squad: descomposición, implementación, tests, revisión y entrega en la fecha acordada.
  • Lo lleva nuestro delivery manager: el ritmo, el reporting y ser la única persona a la que el cliente escala.
  • No cruza nunca: la coordinación diaria de cada ingeniero. Ese trabajo es nuestro, y cobrárselo al cliente en horas de reunión vaciaría de sentido la compra de un squad.

Es la doctrina forward-deployed aplicada al build de un protocolo: el cliente se queda la arquitectura y el trato con los stakeholders; el squad se lleva el arco de entrega de punta a punta. La descripción que hace el propio cliente de lo que eso le compró es la formulación más limpia del modelo que hemos leído desde el lado del comprador: «Conectia me ha permitido centrarme en la redacción del White Paper, en las decisiones arquitectónicas de alto nivel y en la gestión de stakeholders mientras ellos se encargan de TODO en ingeniería, y sé que no tengo que preocuparme.»

El historial de entrega: tres SDKs probados, todas las fechas cumplidas y cero bugs

Los tres SDKs — TypeScript, PHP y Python — están probados. Cada entregable aterrizó en la fecha a la que se había comprometido. No se ha reportado ni un bug contra lo que hemos entregado.

«Los entregables llegarán a tiempo y con una excelencia que supera las expectativas. Sin bugs, sin despliegues retrasados, sin sorpresas. Solo planificación y ejecución sólidas.» — Marc Miró i Rierola, arquitecto, MintID

La renovación es la única reseña que le cuesta dinero al cliente

Cualquier proveedor te enseña un testimonio. Un testimonio le cuesta unos minutos a quien lo escribe. Una renovación es una reseña con precio — y esta tiene un precio de 400.000 € más, encima de un engagement que abrió en 200.000 €. Sumados, el cliente lleva comprometidos 600.000 € con las mismas cuatro personas.

Es el dato que querríamos que un CTO escéptico comprobara primero, porque es el único de este post que el cliente ha pagado por hacer cierto.

Qué demuestra un caso de estudio, y quién no debería comprar un squad integrado

Un engagement es un solo dato. No dice nada del contrafactual — no podemos deciros qué habrían costado ni qué aspecto tendrían el núcleo o los SDKs de MintID con otro equipo, y ningún caso de estudio puede. Lo que sí establece es más estrecho y aun así vale algo: un squad integrado de cuatro personas, metido en un build criptográfico exigente, cumplió sus fechas sin generar defectos, y el comprador dobló la apuesta con su presupuesto.

Tampoco generaliza a cualquier comprador. Un squad integrado es la compra equivocada cuando:

  • El trabajo es un backlog bien especificado y lo que necesitas son manos. Compra staff augmentation y quédate la coordinación en casa, donde sale más barata.
  • Nadie en tu lado puede hacerse dueño de la arquitectura. El modelo funciona sobre una entrega sprint a sprint; sin nadie que la haga, necesitas otra forma de squad — un Managed Squad o un Discovery Squad, que desglosamos en nuestra guía de roles y tipos de squad.
  • Quieres dirigir a cada ingeniero a diario. Entonces la autonomía que pagas es fricción y no palanca, y conviene decirlo antes de firmar, no en el tercer mes.

Qué comprobaríamos antes de firmar cualquier squad integrado

Exigidnos la misma lista que le exigís a todo el mundo:

  1. Preguntad quién emplea legalmente a los ingenieros, y en qué jurisdicción vive la cesión de IP. Pedid la respuesta por escrito antes de la conversación técnica, no después.
  2. Preguntad qué cruza la frontera cada sprint. Si un proveedor no os sabe decir exactamente qué espera de vosotros y qué se lleva a cambio, no hay modelo — hay cuerpos.
  3. Preguntad cómo es el final. Documentación, handover, borrado de credenciales. Un partner que no ha pensado nunca en la última semana no ha pensado el engagement entero.
  4. Comprad pequeño primero. Un Pilot Sprint de 14 días con una garantía de sustitución de 30 días es una forma más barata de probar todo lo anterior que un compromiso de seis cifras firmado sobre un deck.

Preguntas frecuentes

¿Cuánto cuesta un squad de ingeniería integrado?

Se cotiza por engagement, no por hora trabajada — un compromiso cerrado y atado a un alcance que cubre a los ingenieros, al delivery manager y la gestión que de otro modo caería en tu lado. El engagement de MintID te da dos referencias reales: abrió en 200.000 € y se amplió con 400.000 € más para la fase siguiente. Tu cifra depende del tamaño del squad y de la duración del engagement; la forma del compromiso no cambia.

¿Con qué rapidez puede arrancar un squad integrado?

Cerramos el match en 72 horas desde un brief definido, porque los ingenieros ya están empleados y no se buscan bajo demanda. En MintID, el equipo completo — tres ingenieros y un delivery manager — ya estaba trabajando en menos de una semana, que es como lo cuenta el cliente en su propia reseña.

¿Quién gestiona a los ingenieros en el día a día?

Nosotros. El delivery manager lleva el ritmo, el reporting y la escalación, y es la única persona al otro lado de la línea para el cliente. En este engagement la implicación del cliente es un check-in semanal más la entrega de arquitectura al empezar cada sprint.

¿Un squad integrado es lo mismo que externalizar un proyecto?

No. El cliente conserva la propiedad de la arquitectura y las decisiones de producto; el squad se lleva el arco de entrega, de la descomposición al código entregado y probado. El arquitecto de MintID marca la dirección cada sprint — lo que no hace es gastarse la semana coordinando ingenieros.


Los SDKs verificadores fueron el entregable donde el protocolo de MintID tenía que sobrevivir al contacto con infraestructura que no controla. La pregunta paralela, del lado de la entrega, era si un squad de cuatro podía cargar con ese código teniendo al arquitecto del cliente a una semana de distancia — y la respuesta que dio, con su firma, fue doblar el presupuesto.

Si tienes trabajo que encaje con esa descripción — difícil, especificado a nivel de arquitectura y que no se entrega añadiendo un par de manos más — empieza por un Pilot Sprint.

¿Listo para construir tu equipo de ingeniería?

Habla con un partner técnico y despliega ingenieros validados por CTOs en 72 horas.