Spacebackend: convertir el manual de un componente en el software que lo hará volar
Todo empieza con un PDF. Lo manda el fabricante de una pieza —un sensor de estrellas, una rueda de reacción, una radio— y explica, en varios cientos de páginas, cómo hay que hablarle a ese trozo de metal: qué byte va en qué posición, cada cuánto contesta, qué hace si no contesta, qué voltaje tolera. En la industria se llama documento de control de interfaz. Un ingeniero se lo lee entero, lo interpreta y escribe a mano el programa que hará que la pieza y el ordenador de a bordo se entiendan.
Ese trabajo se mide en semanas. A veces en meses, porque el documento tiene huecos, contradicciones o frases que admiten dos lecturas, y cada duda se resuelve con un correo al proveedor y una espera. Y hay que repetirlo con cada componente, de cada satélite, cada vez. Un satélite pequeño puede llevar veinte o treinta piezas de proveedores distintos.
Spacebackend nació para meterle una máquina a ese cuello de botella. La empresa se constituyó en Luxemburgo en agosto de 2024, tiene filial en España y en enero de 2026 cerró una ronda inicial de 1,8 millones de euros. Su producto, Lynapse Studio, no llegó al mercado hasta la segunda mitad de ese mismo año.
Qué hace exactamente
Lynapse Studio coge la documentación del fabricante y la convierte en un modelo digital de la pieza. A partir de ahí genera el código que la controla, lo prueba y lo valida en un entorno virtual que simula las condiciones de vuelo. El código sale sin atarse a una plataforma concreta, así que el mismo trabajo sirve para más de una misión.
La parte de inteligencia artificial está donde más molesta el trabajo humano: leer los documentos de interfaz y las hojas de características y señalar sola lo que está ambiguo o directamente falta. Esas son las semanas que un equipo de ingeniería quema resolviendo a mano, correo va, correo viene. El resto del proceso —la generación del código, las pruebas— es determinista, y eso importa en un sector donde nadie firma un componente que se comporte de manera distinta en dos ejecuciones iguales.
La promesa que repiten en su web y en las notas de la ronda es la misma: bajar la integración de hardware y software de años a días. Puede consultarse en spacebackend.com.
Quién está detrás
El fundador y consejero delegado es Dmitry Goldenberg. El equipo se reparte entre Luxemburgo y España y viene de Google, de Israel Aerospace Industries, de SpaceIL y de iSpace: gente que ha construido productos de consumo, arquitecturas de nube y también módulos de alunizaje.
La empresa no arrancó de cero con el dinero de los fondos. En abril de 2024 entró en el programa de incubación de ESRIC con 200.000 euros. En agosto se constituyó y pasó por Techstars y por Fusion VC. La ronda de 1,8 millones llevó el total levantado por encima de los 2,2 millones e incluyó a Bynd Venture Capital, Draper B1 y Athos Capital, más dinero no dilutivo del Gobierno de Luxemburgo a través de un contrato con la Agencia Espacial Europea dentro del programa nacional luxemburgués, LuxIMPULSE.
Qué había antes
Esto no es un hueco vacío. La forma clásica de hacerlo es el ingeniero leyendo el documento, y sigue siendo mayoritaria. Por encima de ella hay décadas de herramientas de modelado y simulación —el mundo de Simulink y compañía— que permiten diseñar el sistema y generar código a partir del modelo. La diferencia está en el escalón anterior: esas herramientas dan por hecho que alguien ya ha traducido el PDF del fabricante a un modelo utilizable. Ese alguien es el que cobra por semanas de trabajo, y es el escalón que Spacebackend intenta automatizar.
La otra alternativa que existía, y existe, es contratar a una ingeniería que te haga la integración. Sale caro y se paga por horas. Cuando la comparación de un cliente es esa, un programa que hace parte del trabajo puede pedir mucho dinero y seguir pareciendo barato. Ahí está la respuesta a por qué en un sector regulado se puede cobrar bien desde el primer contrato: no compites con una suscripción de 30 euros al mes, compites con un presupuesto de ingeniería y con el coste de un fallo que se lleva por delante la misión entera.
Lo que enseñaron para levantar el dinero
Aquí está lo interesante para quien esté dándole vueltas a montar algo. No hay clientes públicos, ni cifras de facturación, ni producto en el mercado cuando entró el dinero. Lo que sí había: un equipo con historial verificable en misiones reales, un programa de incubación superado con dinero público de por medio, un contrato con la Agencia Espacial Europea vía Luxemburgo y un problema que cualquier ingeniero del sector reconoce en cinco segundos porque lo ha sufrido.
Eso es lo que se compra en una ronda inicial de tecnología dura: no la tracción, sino la credibilidad de que ese equipo concreto puede resolver ese problema concreto. En un negocio de márgenes finos y ticket bajo, ese mismo discurso no levanta nada.
A quién le sirve y a quién no
Le sirve a fabricantes de satélites, a integradores y a empresas de robótica que trabajen con muchos componentes de terceros y tengan procesos de validación formales. Cuanto más papeleo y más certificación, mejor encaja.
No le sirve a quien monta hardware con dos o tres piezas conocidas, ni a quien trabaja con componentes que ya tienen sus programas de control hechos y probados. Tampoco a proyectos donde el coste del fallo es bajo: ahí la solución de siempre —un ingeniero y una tarde— sigue ganando por precio.
El producto salió en la segunda mitad de 2026. Con la ronda cerrada en enero y el lanzamiento medio año después, lo que viene ahora es la parte que todavía no se ha visto: cuántas empresas lo pagan y con qué frecuencia vuelven.