Tienes la idea de producto de un terminal de trading, presupuesto y ningún equipo de ingeniería. Contratar uno y contratar a un socio para que lo construya no son dos precios de lo mismo: reparten el tiempo, el conocimiento y el riesgo de otra manera. Esto es lo que te cobra cada vía, lo que tiene que haber en el traspaso y lo que tienes en la mano el día en que el trabajo se detiene.
Tienes la idea de un terminal de trading, presupuesto para él y ningún equipo de ingeniería. La pregunta que viene después casi siempre se plantea como una comparación de precios: cuánto cuesta contratar ingenieros y cuánto cuesta que una empresa lo construya y te lo entregue.
Ese planteamiento esconde la decisión. Las dos vías terminan con código que funciona. Se diferencian en cuándo existe la primera versión utilizable, quién entiende el sistema un año después, qué pasa cuando se va una persona clave y qué tienes en la mano si el trabajo se detiene.
La respuesta corta: compara las dos vías por cuatro cosas y no por la tarifa - el tiempo hasta una versión que puedas poner delante de un trader, dónde vive el conocimiento del sistema, qué sobrevive a una marcha y qué te pertenece el día en que el trabajo se detiene. Una vía que gana en tarifa y pierde en las cuatro es la más cara.
Un terminal de trading no es un solo sistema. Es una ruta de datos de mercado, una ruta de entrada de órdenes, verificaciones de riesgo pre-trade, conectividad con venues o brókers, estado de posiciones y cuentas, una pantalla que debe seguir redibujándose mientras el libro se mueve, y un back office que lo concilia todo tras el cierre.
Cuando contratas, no compras ese sistema. Construyes la organización que lo va a producir, y el conocimiento de cómo funciona parte de cero y se acumula en las cabezas de las personas que empleas. Es un activo mientras se quedan y es todo el riesgo cuando no.
Cuando contratas a un socio, compras un sistema más un historial de decisiones que ya existe en otro sitio. El conocimiento parte de un nivel más alto y el primer día está fuera de tu empresa. Que llegue a entrar es una cláusula del contrato y una práctica de trabajo, no algo que ocurra solo.
Conviene ser concreto sobre qué significa aquí el conocimiento del sistema, porque no es el código fuente:
Nada de eso vive en un repositorio por defecto. Vive en una persona hasta que un proceso lo obliga a pasar al papel, sea esa persona tu empleado o un ingeniero del socio.
La vía de contratar tiene delante una cola que el presupuesto no elimina. Escribes un puesto que puedas defender técnicamente, buscas candidatos en un mercado donde escasean los ingenieros de trading, entrevistas por competencias que dentro de tu empresa nadie sabe aún evaluar, esperas los preavisos y luego pasas el primer tramo viendo cómo un equipo nuevo discute sobre una arquitectura en vez de construirla.
La vía del socio empieza por el alcance en lugar de por la búsqueda de gente, y de ahí viene la diferencia de tiempo. Lo que no elimina es el trabajo que solo tú puedes hacer: decidir para qué sirve el terminal, qué instrumentos y qué venues importan primero, y quiénes son los primeros usuarios.
Y una parte del calendario no pertenece a ninguna de las dos vías. Estos elementos van a su propio ritmo, sin importar quién escriba el código:
Así que la comparación honesta no es una carrera entre dos fechas de entrega. Es la pregunta de qué vía pone menos cosas fuera de tu control por delante del trabajo, y cuál empieza antes las partes en las que sí influyes.
Haz la misma pregunta a las dos vías. Si el ingeniero que escribió el handler de datos de mercado deja de trabajar el lunes, qué pasa el martes, y qué pasa en el trimestre siguiente.
En un equipo pequeño que has contratado, la respuesta suele depender de un solo nombre. Los equipos iniciales concentran el conocimiento por diseño: una persona es dueña del hot path, otra de la conectividad, y el roadmap se reorganiza en silencio en torno a quien sigue ahí. Con un socio depende de si más de un ingeniero de su lado ha leído el código, y de si tu contrato lo exige.
Ninguna de las dos estructuras es segura por sí misma. Un socio con un único ingeniero en tu cuenta está tan expuesto como un equipo interno de dos personas, y la defensa es idéntica en ambos casos: conocimiento escrito mientras se crea, y no reconstruido después.
Una prueba de aceptación que sirve para cualquiera de las dos vías: toma a un ingeniero que nunca ha visto el sistema, dale la documentación y una máquina limpia, y pídele que levante el terminal en un entorno de pruebas y coloque una orden. Todo lo que tenga que preguntarle a una persona es conocimiento que todavía no posees.
La palabra traspaso cubre dos hechos muy distintos. Uno es una transferencia de archivos. El otro es la transferencia de la capacidad de seguir adelante sin las personas que lo construyeron, y solo por el segundo merece la pena pagar.
Escribe el segundo en el alcance como una lista de artefactos, cada uno con su prueba de aceptación. Una lista razonable tiene este aspecto:
Un traspaso que nunca se ha ensayado es un plan, no un entregable. Ensáyalo a mitad de la construcción, no después de la factura final, y el ensayo es sencillo: tus ingenieros despliegan un cambio y lo revierten mientras quienes escribieron el sistema miran.
La propiedad es una cuestión distinta del traspaso, y se cierra en el contrato antes de empezar el trabajo, no se descubre al final. Nuestra respuesta cabe en una frase, y no la acortamos en ninguna versión de ningún documento.
El cliente conserva la propiedad completa del producto y del código, salvo nuestros componentes reutilizables. Esa excepción es la parte que hay que leer con lupa con cualquier socio, el nuestro incluido: pregunta cuáles son los componentes reutilizables, en qué términos los sigues usando, si el sistema compila sin nada que no puedas reconstruir por ti mismo, y qué pasa con esos componentes si la colaboración entre los dos termina.
La pregunta suele plantearse como algo binario - contratar un equipo o entregarle todo a otro. En la práctica la mayoría de los proyectos quedan entre esos dos polos, y esa posición puede cambiar a medida que el sistema madura.
Tres formatos: entrega completa, un equipo dedicado o ingenieros integrados en tu equipo. Así describimos nuestra parte, y la diferencia entre los tres no es la factura - es quién lleva el plan, quién lleva las prioridades y quién responde por el resultado.
Ese último punto disuelve buena parte de la pregunta inicial. La versión más sólida de la vía del socio contempla tu propio equipo desde el principio: contratas contra un sistema que ya existe, tus entrevistas se apoyan en el código que el candidato va a mantener, y lo primero que lee alguien recién incorporado es un registro de decisiones y no un repositorio en blanco.
Comparar tarifas es el número menos útil de esta decisión, porque las dos vías te facturan en unidades distintas. Pon ambas listas una al lado de la otra y calcula su coste con honestidad.
La vía de contratar te cobra por:
La vía del socio te cobra por:
Después calcula el coste de las salidas, porque las dos vías tienen una. La vía de contratar termina reduciendo un equipo que construiste, y el conocimiento se va en esas cabezas. La vía del socio termina con un traspaso que ensayaste o no ensayaste, y la distancia entre esos dos finales es el riesgo de la vía.
Antes de firmar nada, pasa las dos opciones por una sola pregunta: si esto se detuviera el viernes, ¿qué seguiríamos teniendo el lunes? Respóndela en artefactos - repositorios, entornos reproducibles, documentación y personas capaces de reconstruir el sistema a partir de ellos -, porque las intenciones no sobreviven a una marcha y los artefactos sí.
Lo que amBrain puede sustentar públicamente: llevamos construyendo software desde 2019 en Ereván, Armenia, con los hot paths escritos en Rust, construimos el terminal de trading Spectre Trade, y un mini-exchange que construimos funciona en producción en la colocación de MOEX. Si estás sopesando contratar frente a trabajar con un socio para un terminal propio, lleva la lista de traspaso de arriba a la primera conversación y pide a quien tengas enfrente, nosotros incluidos, que la responda línea por línea.
Traiga su arquitectura actual y el modo de fallo que le preocupa, y lo repasaremos juntos en media hora.