Resumen

Systellar · Deep-tech B2B

De hipótesis a plataforma aeroespacial

Cuando la solución de partida no es la que hace falta

Systellar, una startup deep-tech de Barcelona, quería construir synapse™: una plataforma para diseñar satélites. Los founders llegaron con una idea clara: un chat de IA como puerta de entrada al producto. Sesión a sesión, entendiendo el dominio con ellos y con el feedback de ingenieros externos, llegamos a otra solución: un modelo vivo del satélite donde el ingeniero hace MBSE sin saber que lo hace, y donde los agentes de IA trabajan con las mismas reglas que una persona.

Rol

Senior Product Designer · freelance · único diseñador

Cliente

Systellar Space

Fechas

Verano de 2025 · 10 semanas

Equipo

2 cofundadores: CEO (especialista MBSE) y CTO (operaciones de satélites) · equipo de desarrollo pequeño

Alcance

Arquitectura, Requisitos, Verificación, Workflows, Control de versiones y la experiencia del agente de IA

Contexto

Startup deep-tech de Barcelona, hoy acelerada por Techstars. Cuando entré no había producto, solo una base técnica y una idea de solución: un chat de IA.

En 30 segundos

Resumen en 30 segundos

Problema

En un satélite, un cambio en un componente afecta a masa, energía y térmico. Pero cada dato vive en una hoja de cálculo, un script o un PDF distinto, y los desfases se descubren tarde, en integración o en ensayos.

Solución

La idea inicial era un chat de IA. Tras entender cómo trabajan los ingenieros, la cambiamos por una plataforma donde todo el satélite es un único modelo vivo. Los ingenieros trabajan con componentes y conexiones físicas, no con sintaxis. Cada cambio muestra su impacto antes de aplicarse, y los agentes de IA pasan por la misma revisión que una persona.

Impacto

De la pizarra a producto en 10 semanas. Un año después, Tumbleweed trabaja su nave Oasis en synapse™, y su CTO destaca que es más fácil de entender que el software de ingeniería habitual.

Impacto

• 10 semanas — De cero producto a una plataforma demostrable con clientes e inversores, con cinco módulos diseñados.
• 1 cambio de rumbo — Del chat de IA como centro del producto a un modelo vivo del sistema con la IA trabajando dentro.

Qué pasó después

Mi encargo terminó con esas 10 semanas, con todos los entregables cerrados. Lo que vino después es recorrido del producto, no resultado mío, pero confirma la dirección:

1. Systellar entra en Techstars London.
2. Finalista del EU Startup Summit, entre 15 elegidos de más de 1.600 candidaturas.
3. Tumbleweed elige synapse™ y trabaja su nave Oasis en él. Su CTO destaca que es más fácil de entender que la mayoría del software de ingeniería.

Los hitos de la empresa (Techstars, EU Startup Summit) son contexto. El impacto atribuible al diseño es el tiempo a producto y la adopción por un equipo de ingeniería real.

El problema

Los satélites no se complican por falta de cálculo, sino porque las disciplinas pierden la sincronización. El presupuesto de masa vive en una hoja de cálculo, los requisitos en un PDF que nadie reabre tras la firma y las interfaces en presentaciones. Cuando cambia un valor, nada avisa de qué depende de él.

La respuesta de la industria existe: el MBSE con SysML v2, un modelo del sistema legible por máquinas. Pero las herramientas tradicionales exigen semanas de formación antes de modelar el primer subsistema, así que los equipos pequeños y rápidos no lo adoptan. El problema no era técnico. Era de adopción.

Discovery

No venía del sector aeroespacial, y el punto de partida ya estaba decidido: un chat de IA. Antes de diseñarlo, necesitaba entender qué hacen estos ingenieros cada día y por qué sus herramientas actuales (CATIA, Cameo, Excel) no resolvían la coordinación. Los founders habían construido modelos de sistema en Airbus y la ESA y operado 8 satélites, así que fueron mi primera fuente de dominio.

• Sesiones cada 2–3 semanas con los dos founders: primero revisábamos avances y conclusiones, y después bocetábamos juntos cómo veían ellos cada parte del satélite.
• Feedback de ingenieros externos, que los founders recogían y traían a cada revisión.
• Entre sesiones, trabajo con los materiales reales que me compartían: hojas de masa, interfaces y matrices de requisitos.

Partimos de cuatro protopersonas que definimos con los founders: un comercial técnico, una ingeniera de sistemas junior, un ingeniero jefe de integración y una responsable de normativa. Eran hipótesis, no research, pero sus frustraciones coincidían: información dispersa, desactualizada y sin saber cuál es la buena. Y con la IA había un patrón claro: la usarían si les ahorra trabajo, pero solo si respeta sus estándares y su trabajo se puede revisar.

1. «Si no encuentro rápido la información correcta, pierdo una oportunidad de negocio.»
2. «Si tuviera ejemplos claros de documentos anteriores, aprendería mucho más rápido.»
3. «No tengo tiempo para revisar cada detalle, necesito que la documentación sea clara desde el inicio.»
4. «Sin una documentación clara y precisa, el proyecto no pasa la revisión.»

Protopersonas iniciales. Hipótesis de partida, no resultado de research.

1. El momento clave fue intentar trazar cómo se usaría el chat en un flujo de trabajo real. El chat respondía preguntas, pero el trabajo seguía viviendo en hojas de cálculo y documentos. Cuanto más mirábamos cómo trabaja un ingeniero, menos sentido tenía.
2. Los ingenieros piensan en componentes y cables, no en bloques y relaciones del estándar. La sintaxis de SysML v2 era una barrera, no una ayuda.
3. Lo que necesitaban primero no era dibujar el sistema, sino saber qué se rompe cuando algo cambia.
4. Un agente de IA solo genera confianza si su trabajo se puede revisar igual que el de un compañero.

Decisiones

Tres momentos en los que la decisión correcta no era la obvia.

Del chat al modelo: cuestionar la solución de partida

Los founders llegaron con un chat de IA como corazón del producto. Tenía sentido en una demo y es lo que el mercado espera ver. No diseñé pantallas del chat: empecé por wireframes para entender la arquitectura del producto, pensando siempre en cómo trabaja un ingeniero. Y ahí el chat se quedaba fuera del flujo: respondía preguntas mientras el trabajo seguía en hojas de cálculo y documentos.

El cambio no fue de un día para otro. El chat fue perdiendo peso sesión a sesión, hasta una reunión con los founders en la que quedó claro para todos que no era el centro del producto. No hizo falta ganar una discusión: bastó con poner la forma de trabajar del ingeniero delante de la idea.

Llegamos a otra solución: primero el modelo del sistema, y la IA trabajando sobre él. Diseñé cómo funcionaría el agente dentro del producto y cómo se vería: en lugar de responder en una conversación, actúa sobre el modelo y su trabajo llega como un cambio pendiente de revisión, igual que el de cualquier ingeniero.

Con una sola instrucción, el agente cambia un valor, relanza los cálculos que dependen de él, recomprueba los requisitos y lo entrega todo como merge request. Los agentes externos se conectan por MCP con las mismas reglas. Todo se apoya en la misma decisión: poner el modelo en el centro.

Esconder el estándar sin esconder los datos

Lo obvio era exponer SysML v2 tal cual: es el estándar y el argumento técnico del producto. Pero eso nos convertía en una herramienta más para especialistas. Tradujimos el estándar a tres piezas que cualquier ingeniero reconoce: nodos (componentes con masa, consumo y volumen), puertos (lo que entra y sale) y requisitos (reglas que se comprueban solas). El modelo formal sigue debajo, completo. Si alguien cambia un componente o un valor, no recibe un error de sintaxis: cada requisito afectado se marca al momento, sin releer documentos ni comprobar a mano.

Revisar cambios como en software, pero con física

Un diff de software compara líneas. En un satélite, más batería puede romper el límite de masa del lanzador. Diseñamos la revisión como un merge request de ingeniería: antes de consolidar un cambio se ve el antes y el después de cada valor y qué requisitos y márgenes quedan comprometidos. Cambiar es fácil; aplicar sin ver el impacto, imposible.

Lo que no construí

En un 0 → 1 de 10 semanas, decidir qué no hacer pesa tanto como lo que se hace.

No diseñé para todos a la vez. Al pasar del chat al modelo, el usuario principal pasó a ser el ingeniero. El comercial técnico se quedó fuera de esta primera versión: lo que necesitaba era consultar información, algo más parecido a un buscador sobre la documentación que a una zona de trabajo.

No hice un lienzo de dibujo libre al estilo Miro: cajas y flechas sueltas habrían roto el modelo, así que cada línea es una conexión física real y lo imposible no se puede trazar. No di opciones de color ni de estilo: el color solo indica estado, nunca es decoración. No dejé que nada, ni personas ni agentes, cambiara márgenes de seguridad sin aprobación explícita. Y no rediseñé lo que el estándar ya resolvía bien: el modelo formal se quedó intacto debajo de la interfaz.

Proceso

Primero la arquitectura, después lo visual. Los wireframes sirvieron para decidir qué era el producto antes de decidir cómo se veía, y fueron los que hicieron evidente que el chat no era el centro.

1. Entender el dominio con los founders
2. Wireframes para definir la arquitectura del producto
3. Cambio de rumbo: del chat al modelo del sistema
4. Diseño visual sobre la arquitectura ya validada
5. Librería de componentes

Una librería de componentes para un equipo pequeño

Con un solo diseñador y un equipo de desarrollo pequeño, la librería no era un lujo: era la única forma de mantener la consistencia sin revisar cada pantalla. No necesitaba la profundidad de un sistema de diseño multicliente como Ethos, pero sí la misma lógica. Partí de una base existente y la adapté por completo a Systellar: los componentes representan objetos de ingeniería (nodos del modelo, bloques de requisitos, estados de verificación), no piezas genéricas de SaaS.

• Tokens de estado: el color solo indica estado, nunca es decoración.
• Nodos componibles: un nodo simple puede convertirse en contenedor de subsistemas sin perder proporciones ni puertos.
• Un único inspector lateral: la misma estructura sirve para editar un requisito, un documento o el acceso de una persona.

Aprendizajes

1. La primera decisión de diseño fue cuestionar la solución. Un chat era la respuesta obvia para un producto con IA; entender el trabajo real fue lo que mostró que el valor estaba en el modelo, no en la conversación.
2. Con usuarios expertos, la complejidad no se esconde: se ordena. Ocultar la sintaxis funcionó porque nunca ocultamos los datos.
3. La confianza en un agente viene del proceso, no de la conversación. Darle las mismas reglas que a una persona (permisos, revisión, trazabilidad) resolvió más dudas que cualquier explicación en pantalla.

Qué haría ahora

Systellar ya ha construido parte de lo que venía después: agentes más autónomos y trabajo en paralelo con ingenieros. Si volviera hoy, me centraría en tres cosas:

• Medir el ahorro real. La web promete recuperar tiempo de ingeniería. Lo validaría con equipos como Tumbleweed, midiendo cuánto trabajo de reconciliación manual desaparece.
• Revisar a escala de agente. Cuando los agentes generan muchos cambios a la vez, revisar cambio a cambio no escala. Agruparía la revisión por intención: qué querías conseguir y qué se ha tocado para ello.
• Salir del espacio. La ambición de Systellar es cualquier hardware complejo, no solo satélites. Comprobaría qué parte del modelo mental de nodos, puertos y requisitos funciona en otros dominios y qué hay que adaptar.

Cierre

En este proyecto, lo más valioso no fue una pantalla, sino cambiar la solución de partida. La idea era un chat; el producto acabó siendo un modelo vivo del satélite con agentes trabajando dentro, y un año después un equipo real trabaja su nave en él.

En deep-tech, el diseño es lo que decide si la tecnología llega a usarse.

In English

synapse™, a satellite engineering platform · Systellar

0 → 1 in 10 weeks · A year later, a real team is building its spacecraft in synapse™

In 30 seconds

In 30 seconds

Problem

In a satellite, a change to one component affects mass, power and thermal. But every piece of data lives in a different spreadsheet, script or PDF, and mismatches are found late, during integration or testing.

Solution

The initial idea was an AI chat. Once we understood how engineers work, we replaced it with a platform where the whole satellite is a single living model. Engineers work with components and physical connections, not syntax. Every change shows its impact before it’s applied, and AI agents go through the same review as a person.

Impact

From whiteboard to product in 10 weeks. A year later, Tumbleweed is building its Oasis spacecraft in synapse™, and its CTO says it’s easier to understand than typical engineering software.

Decisions

Three moments where the right decision wasn’t the obvious one.

From chat to model: questioning the starting solution

The founders came in with an AI chat as the heart of the product. It made sense in a demo and it’s what the market expects to see. I didn’t design chat screens: I started with wireframes to understand the product’s architecture, always thinking about how an engineer works. And that’s where the chat fell outside the workflow: it answered questions while the work stayed in spreadsheets and documents.

The shift didn’t happen overnight. The chat lost weight session by session, until a meeting with the founders where it became clear to everyone that it wasn’t the centre of the product. There was no argument to win: putting the engineer’s way of working in front of the idea was enough.

We arrived at a different solution: the system model first, with AI working on top of it. I designed how the agent would work inside the product and how it would look: instead of answering in a conversation, it acts on the model and its work arrives as a change pending review, just like any engineer’s.

With a single instruction, the agent changes a value, re-runs the calculations that depend on it, re-checks the requirements and hands it all over as a merge request. External agents connect through MCP under the same rules. It all rests on the same decision: putting the model at the centre.

Hiding the standard without hiding the data

The obvious move was to expose SysML v2 as is: it’s the standard and the product’s technical argument. But that would have made us one more tool for specialists. We translated the standard into three pieces any engineer recognises: nodes (components with mass, power draw and volume), ports (what goes in and out) and requirements (rules that check themselves). The formal model is still underneath, complete. If someone changes a component or a value, they don’t get a syntax error: every affected requirement is flagged instantly, with no rereading documents or checking by hand.

Reviewing changes like software, but with physics

A software diff compares lines. In a satellite, more battery can break the launcher’s mass limit. We designed review as an engineering merge request: before a change is committed you see the before and after of every value and which requirements and margins are put at risk. Changing is easy; applying without seeing the impact is impossible.

Process

Architecture first, visuals second. The wireframes were for deciding what the product was before deciding how it looked, and they’re what made it obvious that the chat wasn’t the centre.

1. Understand the domain with the founders
2. Wireframes to define the product architecture
3. Change of direction: from chat to system model
4. Visual design on top of the validated architecture
5. Component library

A component library for a small team

With a single designer and a small development team, the library wasn’t a luxury: it was the only way to keep things consistent without reviewing every screen. It didn’t need the depth of a multi-client design system like Ethos, but it did need the same logic. I started from an existing base and adapted it entirely to Systellar: the components represent engineering objects (model nodes, requirement blocks, verification states), not generic SaaS pieces.

• State tokens: colour only signals state, never decoration.
• Composable nodes: a simple node can become a container for subsystems without losing its proportions or ports.
• A single side inspector: the same structure works for editing a requirement, a document or a person’s access.