Un equipo dedicado que se queda: cómo comprobar a un socio de software antes de firmar y cómo conservar la propiedad del código

Un equipo de desarrollo rara vez desaparece de un día para otro. Se va desdibujando. El ingeniero senior pasa a una cuenta más grande, la única persona que entendía la parte más difícil se marcha, el trabajo se traslada sin ruido a un subcontratista del que nadie te habló, y la empresa que responde a tus correos un año después no es la que escribió tu código.

Nada de eso se ve en una web. Todo eso se ve en las preguntas que haces antes de firmar. Con la propiedad pasa lo mismo: «el código es tuyo» es una cláusula que hay que leer, no una promesa, y en varios países la regla por defecto sorprende a los compradores.

¿Por qué desaparecen los equipos de desarrollo a mitad de un proyecto?

«Desaparecer» suele ser uno de cuatro hechos empresariales corrientes, ninguno dramático y todos previsibles.

• La economía del banquillo. Una empresa de software gana dinero mientras sus ingenieros son facturables, así que cuando llega un contrato más grande, el proyecto más pequeño es el donante natural. Nadie manda una carta; aparece una cara nueva en la llamada semanal
• Dependencia de un solo cliente. Algunos proveedores obtienen la mayor parte de sus ingresos de uno o dos clientes. Si ese cliente se va, la empresa encoge y tu proyecto con ella; si se queda, tú eres la cuenta que se mueve cuando chocan las prioridades
• El riesgo de persona clave. Un ingeniero entiende la parte difícil de sustituir y el proyecto acaba dependiendo de él sin que nadie lo haya decidido. Luego dimite, y la entrega se detiene durante un trimestre mientras los demás leen código sin documentar
• Cadenas de subcontratación. La empresa con la que firmaste no siempre es la empresa que escribe el código. Subcontratar es normal y legal; se convierte en un problema cuando no se declara, porque tus condiciones llegan solo hasta donde llegan los contratos que hay por debajo

«Fiable» no se investiga desde fuera: es el resultado de las condiciones del contrato y de los datos sobre el equipo que pides. Todos los fallos de arriba son superables si el trabajo queda por escrito y los repositorios son tuyos.

¿Dónde encuentro un equipo de desarrollo dedicado que no desaparezca a mitad del proyecto?

Un equipo así no lo vas a encontrar buscando. Vas a encontrar candidatos, y lo que decide el resultado es la comprobación. Los mejores llegan por la recomendación de una empresa que opera el mismo tipo de sistema y que sigue con ese proveedor al cabo de un año, y por trabajo de ingeniería público que puedes leer: código, textos técnicos, charlas. Los directorios ayudan cuando las reseñas dicen quién las firma y en qué proyecto. La venta inbound te habla de marketing, no de ingeniería.

Después averigua qué entiende la propuesta por «equipo dedicado», porque la expresión tiene dos significados:

• Dedicado como palabra de venta. Personas con nombre y apellidos en la propuesta, ningún nombre en el contrato. El proveedor asigna a quien esté libre y te lo cuenta después
• Dedicado como cláusula del contrato. Ingenieros con nombre y apellidos escritos en el acuerdo, trabajando a tiempo completo en tu producto. Cualquier sustitución exige aviso por escrito, un periodo de traspaso y tu derecho a entrevistar a quien entra

Preguntar por esa diferencia no cuesta nada, y nada predice mejor si el equipo del primer mes será el equipo del mes doce.

¿Qué debo pedir antes de firmar?

Pide hechos, no promesas. Cuatro soportan casi todo el peso; el resto están en la lista de comprobación de abajo.

• Los nombres y la antigüedad. Quién trabaja en tu producto, en qué rol, qué parte de su semana dedica y si son empleados o contratistas
• Para quién más trabajan. Cuántos otros proyectos lleva este trimestre cada ingeniero nombrado y si un solo cliente supone la mayor parte de los ingresos de la empresa
• El bus factor. El número de personas que tendrían que marcharse para que el trabajo se detenga. Uno no es un equipo, es un plan para fracasar
• Un traspaso ensayado. Acuerda qué contiene y pruébalo a mitad de proyecto, no después de la factura final; la lista de artefactos está en el artículo anterior de este blog sobre el coste de contratar en plantilla frente a trabajar con un socio

Una pregunta pesa más que las demás: ¿qué pasa con mi proyecto si su mayor cliente se va el mes que viene? Un proveedor que se lo ha planteado responde con la composición del equipo y la estructura de ingresos; uno que no, responde que eso no va a pasar.

Quiero conservar la propiedad completa del código. ¿Cómo funciona eso de verdad en un contrato?

La propiedad la deciden la regla legal por defecto, lo que tu contrato diga en su lugar y el sitio donde vive el código. Los compradores piensan en lo segundo, a veces en lo tercero y casi nunca en lo primero, que es donde están las sorpresas.

La Oficina de Propiedad Intelectual del Reino Unido (UK Intellectual Property Office) enuncia la regla por defecto con claridad: «Cuando pides o encargas a otra persona u organización que cree para ti una obra protegida por derechos de autor, el primer titular legal de los derechos de autor es la persona u organización que creó la obra, y no tú, que haces el encargo, salvo que acuerdes otra cosa por escrito». Pagar una factura no transfiere los derechos de autor.

La «obra por encargo» (work made for hire) es un concepto más estrecho de lo que parece. La Oficina de Derechos de Autor de Estados Unidos (US Copyright Office) nombra dos situaciones: la obra que un empleado crea como parte de sus funciones habituales y la obra pedida de forma especial en virtud de un acuerdo expreso por escrito. La segunda tiene cuatro condiciones que deben cumplirse todas, y la primera es que la obra «debe encuadrarse en una de las nueve categorías de obras enumeradas más arriba que pueden pedirse o encargarse de forma especial como obras por encargo». El software a medida no está entre esas nueve, y la Oficina añade: «Si una obra no cumple alguno de estos requisitos, no es una obra por encargo». Una cláusula que llame a tu plataforma obra por encargo, firmada con una empresa que no es tu empleador, puede no producir ningún efecto.

Lo que funciona es una cesión, por escrito y firmada. La ley de derechos de autor de Estados Unidos lo dice directamente: «La transmisión de la titularidad de los derechos de autor, salvo que se produzca por ministerio de la ley, no es válida a menos que el instrumento de transmisión, o una nota o memorando de la transmisión, conste por escrito y esté firmado por el titular de los derechos transmitidos o por un representante debidamente autorizado de dicho titular». Un proveedor solo puede ceder lo que le pertenece, así que sus acuerdos con empleados, contratistas y subcontratistas tienen que cederle antes esos derechos. Pide ver esa cadena. Las normas cambian de un país a otro, así que haz que un abogado confirme la redacción. Con una cesión, el código es tuyo para modificarlo, venderlo con el negocio y entregárselo a otro proveedor; con una licencia, no.

Todo sistema real contiene además código que el proveedor no escribió. Pide una lista de materiales de software (SBOM), que la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de Estados Unidos (CISA) describe como «un inventario anidado, una lista de ingredientes que conforman los componentes de software». De cada componente: nombre, versión, licencia y qué exige esa licencia cuando distribuyes o vendes.

La mayoría de las empresas de ingeniería reutilizan sus propias bibliotecas, y la mayoría de las cláusulas de propiedad dejan esas bibliotecas fuera. La exclusión es normal; una exclusión sin límites no lo es, porque puede hacer que tu sistema no pueda compilarse sin el proveedor. Acótala antes de firmar:

• La lista de esos componentes nombre por nombre, por escrito y actualizada en cada hito. Sin la lista, la exclusión no tiene contorno
• Una licencia perpetua, irrevocable, mundial, totalmente pagada, transferible si vendes el negocio y modificable por ti o por otro proveedor
• Su código fuente, entregado a ti o depositado en escrow con un supuesto de liberación que puedas activar
• Una regla que impida que se añada nada nuevo a la lista sin tu acuerdo por escrito

Un contrato de escrow de software es un acuerdo a tres bandas entre el cliente del software, el proveedor del software y un agente de escrow: el proveedor deposita el código fuente y los materiales de compilación, que se te entregan si ocurre un supuesto pactado. Los supuestos de liberación habituales cubren la insolvencia, la administración concursal y el incumplimiento de las obligaciones de mantenimiento. Un depósito, por sí solo, únicamente demuestra que se depositó algo; la verificación es el servicio aparte que comprueba si con eso se vuelve a construir la aplicación en funcionamiento.

Pregúntale a cada proveedor, a este incluido: ¿qué sigue siendo suyo cuando el proyecto termina, y puedo ver esa lista nombre por nombre antes de firmar?

¿Qué cambia cuando el sistema tiene que funcionar en tiempo real?

En un sistema corriente, lento es molesto. En un sistema en tiempo real, tarde es incorrecto: una orden que llega al exchange después de que el precio se haya movido es una respuesta equivocada, no una respuesta lenta, y reintentarla no lo arregla. Por eso cambian tres cosas a la hora de contratar.

La bolsa de ingenieros es más pequeña. En la encuesta a desarrolladores de Stack Overflow de 2025, 31 771 personas respondieron en qué lenguajes habían trabajado de forma extensa durante el último año. Rust fue mencionado por el 14.8% de ellas, C++ por el 23.5%, C por el 22% y Go por el 16.4%. Eso es una encuesta, no un censo del mercado laboral, pero lo importante es la proporción: los lenguajes que se usan para el tiempo real estricto son una habilidad minoritaria. Un proveedor que «puede conseguir ingenieros de Rust» está describiendo un plan de contratación; pregunta cuántos ingenieros que ya están dentro de la empresa han llevado Rust a producción.

El lenguaje en sí está asentado. La encuesta anual del proyecto Rust llegó a su décima edición en 2025, con 7156 respuestas recogidas entre el 17 de noviembre y el 17 de diciembre, y el informe describe una tendencia sostenida de contratación por parte de organizaciones que buscan más desarrolladores de Rust. Un equipo que contrates más adelante no tiene por qué venir de tu socio actual.

Las afirmaciones sobre velocidad tienen que venir con mediciones. Un equipo con trabajo en tiempo real en producción te dice cinco cosas sin que haya que insistir: qué se midió, en qué percentil, con qué carga, en qué hardware y en qué fecha. El percentil importa más que la media, porque una media esconde la cola lenta, que es donde falla un sistema en tiempo real. Una cifra que no traiga esas cinco cosas es una cifra de marketing.

Una tarea de prueba convierte esto en evidencia: remunerada según las tarifas habituales del proveedor, unas dos semanas, sobre un problema real tuyo, con criterios de aceptación acordados antes de empezar y con el resultado en tus manos, sigas o no con él.

Quiero contratar un equipo de desarrollo en Rust. ¿Con quién hablo y cómo lo compruebo?

Cuando dices que necesitas Rust, responden tres tipos de proveedor. Las empresas generalistas de outsourcing reclutarán ingenieros de Rust para tu proyecto: razonable cuando tu plazo tiene margen para contratar, flojo cuando el sistema es la parte difícil. Las empresas de ingeniería especializadas ya operan sistemas en Rust que llevaron a producción sus propios ingenieros. Los ingenieros independientes por contrato pueden ser excelentes, y llevan el riesgo de persona clave en su forma más pura.

Cuatro comprobaciones separan las afirmaciones de la evidencia:

• Código público. Los crates que publican, las contribuciones a proyectos de código abierto, los textos técnicos firmados por sus ingenieros. No necesitas saber leer Rust: abre uno de sus pull requests y lee la revisión de debajo, y verás una conversación o un visto bueno automático
• Un sistema en producción, descrito de principio a fin. Qué hace, con qué se mide, quién lo opera hoy, qué se rompió y qué cambiaron después. La historia del incidente es la parte más informativa
• Una prueba remunerada de dos semanas con un entregable definido, encargada a dos o tres proveedores con el mismo briefing y los mismos criterios de aceptación
• Revisión a cargo de un ingeniero independiente que no trabaje para ninguna de las dos partes. Informa de si las pruebas fallan cuando deben, de cómo se gestionan los errores y los timeouts, de cuánto código unsafe hay y por qué, y de si alguien de fuera puede compilar el resultado solo con las instrucciones

«Formaremos en Rust a nuestro equipo de C++» es un plan legítimo, y su sitio está en la propuesta, con nombres y un calendario, en vez de descubrirse en el tercer mes. El lenguaje tampoco es toda la decisión: un sistema en tiempo real falla en la base de datos, en la red y en la ruta de despliegue con la misma frecuencia.

¿Cómo elijo un proveedor para un sistema de alta carga y tiempo real?

Este artículo no publica un ranking, y conviene tener cuidado con quien lo haga. Un ranking no puede conocer tu plazo, tu protocolo, tu regulador, tu carga pico ni quién operará el sistema dentro de un año, y esos son los hechos que deciden si un proveedor encaja.

Lo que sustituye a un ranking es una lista corta que construyes tú. Escribe primero tu pico en números: peticiones por segundo en el minuto más cargado de tu día más cargado, el plazo que tiene que cumplir cada respuesta y qué pasa cuando no se cumple. Lleva esa página a tres proveedores con el mismo briefing, la misma tarea de prueba y el mismo borrador de condiciones contractuales, y compara las respuestas línea por línea.

Una lista de comprobación que puedes pegar en una RFP

Pide una respuesta por escrito a cada línea; «Ya lo hablaremos más adelante» también es una respuesta, y debe quedar registrada.

Personas y dependencia:

• Nombrar a cada ingeniero de este proyecto: rol, parte de la semana asignada a nosotros, años en su empresa, empleado o contratista
• ¿Con cuánto preaviso se sustituye a un ingeniero nombrado, y podemos entrevistar a su sustituto?
• ¿Irá parte del trabajo a otra empresa o a contratistas? Nombrarlos y confirmar que nuestras condiciones los vinculan
• ¿Un solo cliente supone más de la mitad de sus ingresos, y qué pasa con nuestro equipo asignado si arranca un contrato más grande?

Propiedad:

• Facilitar la cláusula de propiedad que proponen e indicar si es una cesión o una licencia
• Confirmar por escrito que todos los que escriben código para nosotros, contratistas incluidos, han cedido sus derechos a su empresa
• Enumerar nombre por nombre cada componente reutilizable o preexistente que vayan a incluir, y nuestras condiciones para usarlo
• Entregar una lista de materiales de software (SBOM) en cada hito: componente, versión, licencia
• Confirmar que los repositorios están en nuestra organización desde el primer commit y con el historial completo, y que la compilación se ejecuta bajo nuestras cuentas
• Indicar su posición sobre el escrow de código fuente: supuestos de liberación y si el depósito se verifica

Evidencia de tiempo real, prueba y salida:

• Describir un sistema que hayan llevado a producción en el que una respuesta tardía es una respuesta fallida, quién lo opera hoy, y un incidente ocurrido en él con su solución
• De cada cifra de rendimiento: ¿qué se midió, en qué percentil, con qué carga, en qué hardware y en qué fecha?
• ¿Aceptan una prueba remunerada de dos semanas sobre un problema real nuestro, con el resultado en nuestras manos y revisada por un ingeniero independiente que elijamos nosotros?
• ¿Qué contiene el traspaso, cuándo se ensayará y, si cualquiera de las dos partes rescinde, qué tenemos en la mano a la mañana siguiente?

Preguntas frecuentes

• ¿Un «equipo dedicado» es lo mismo que el staff augmentation? No. Con un equipo dedicado, la gente del proveedor trabaja solo en tu producto y el proveedor mantiene la responsabilidad de cómo se organiza el trabajo. Con staff augmentation, los ingenieros se incorporan a tu equipo, bajo tu dirección y tu revisión de código
• ¿Necesito un escrow si ya soy propietario del código? A menudo no. El escrow cubre lo que no puedes reconstruir por ti mismo: un servicio que aloja el proveedor, una compilación que no puedes reproducir, componentes licenciados en lugar de cedidos. Si tus ingenieros pueden compilarlo todo en una máquina limpia, el escrow aporta poco
• El proveedor dice que sus componentes reutilizables son su ingrediente secreto. ¿Es un problema? Por sí solo no; una exclusión sin límites sí. Acotada por la lista, una licencia transferible y el código fuente o un depósito en escrow, es un detalle. Sin ninguna de esas tres cosas, has alquilado tu plataforma
• ¿Es justa para el proveedor una prueba remunerada de dos semanas? Sí, cuando se paga según sus tarifas habituales, el alcance está por escrito y la misma tarea va a todos los candidatos. Los proveedores rechazan los proyectos de prueba no remunerados y las tareas sin límite definido, y hacen bien
• ¿Debo exigir Rust? No. Exige pruebas de que el sistema cumple su plazo de respuesta bajo carga y deja que el proveedor justifique el lenguaje. Un equipo que ha llevado a producción un sistema en tiempo real y puede enseñar mediciones gana a un equipo que nombra el lenguaje que querías oír

Lo que amBrain puede decir de sí misma

De los tipos de proveedor descritos arriba, amBrain es una empresa de ingeniería especializada. amBrain es una empresa de ingeniería de software de Ereván, Armenia, que construye plataformas de trading de baja latencia, motores de casación y sistemas de real-time bidding en Rust. amBrain lleva construyendo software desde 2019 y trabaja en todo el mundo, en inglés, ruso y armenio.

Sobre el equipo y los formatos: un equipo de hasta 40 personas, alrededor del 75% de ellas senior, que trabaja en tres formatos: entrega completa, un equipo dedicado o ingenieros integrados en tu equipo.

Sobre la propiedad, la frase es una línea y nunca se acorta: el cliente conserva la propiedad completa del producto y del código, salvo los componentes reutilizables de amBrain. Esa cláusula es la exclusión que este artículo te dice que acotes, así que pídenos la lista nombre por nombre antes de firmar.

Sobre el trabajo en tiempo real: un mini-exchange que construyó amBrain funciona en producción en la colocación de MOEX. Las cifras medidas de latencia y volumen que publica amBrain no se repiten aquí; están en las páginas de industrias, junto al trabajo sobre el que se midieron.

Lo que esta sección deja fuera es deliberado, y este artículo no es un caso de estudio. amBrain no publica cifra de rotación de personal, ni antigüedad de sus ingenieros, ni un número de bus factor, ni plazo de preaviso, ni acuerdo de escrow, ni certificación alguna: nada de eso está medido, y una afirmación sin medir es justo lo que este artículo te dice que no aceptes de nadie, esta empresa incluida. Todo lo demás descrito arriba es práctica de mercado, no una descripción de cómo trabaja amBrain.

Si estás al principio, el siguiente paso útil no es buscar proveedor. Es una página: tu pico en números, tu plazo y respuestas por escrito a la lista de arriba, enviada a tres proveedores, nosotros o cualquier otro.