Overview

Systellar · Deep-tech B2B

From hypothesis to aerospace platform

When the starting solution isn’t the one you need

Systellar, a deep-tech startup in Barcelona, wanted to build synapse™: a platform for designing satellites. The founders came in with a clear idea: an AI chat as the front door to the product. Session by session, learning the domain with them and with feedback from external engineers, we arrived at a different solution: a living model of the satellite where engineers do MBSE without realising it, and where AI agents work under the same rules as a person.

Role

Senior Product Designer · freelance · sole designer

Client

Systellar Space

Dates

Summer 2025 · 10 weeks

Team

2 co-founders: CEO (MBSE specialist) and CTO (satellite operations) · small development team

Scope

Architecture, Requirements, Verification, Workflows, Version control and the AI agent experience

Context

Deep-tech startup in Barcelona, now accelerated by Techstars. When I joined there was no product, just a technical foundation and an idea for a solution: an AI chat.

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.

Impact

• 10 weeks — From no product to a platform we could demo to clients and investors, with five modules designed.
• 1 change of direction — From an AI chat at the centre of the product to a living model of the system with AI working inside it.

What happened next

My engagement ended with those 10 weeks, with every deliverable closed. What came after is the product’s journey, not my result, but it confirms the direction:

1. Systellar joins Techstars London.
2. Finalist at the EU Startup Summit, one of 15 selected from more than 1,600 applications.
3. Tumbleweed chooses synapse™ and is building its Oasis spacecraft in it. Its CTO says it’s easier to understand than most engineering software.

The company milestones (Techstars, EU Startup Summit) are context. The impact attributable to design is the time to product and adoption by a real engineering team.

The problem

Satellites don’t get complicated for lack of calculation, but because disciplines fall out of sync. The mass budget lives in a spreadsheet, requirements in a PDF nobody reopens after sign-off, and interfaces in slide decks. When a value changes, nothing tells you what depends on it.

The industry has an answer: MBSE with SysML v2, a machine-readable model of the system. But traditional tools demand weeks of training before you model your first subsystem, so small, fast teams don’t adopt it. The problem wasn’t technical. It was adoption.

Discovery

I didn’t come from aerospace, and the starting point had already been decided: an AI chat. Before designing it, I needed to understand what these engineers do every day and why their current tools (CATIA, Cameo, Excel) didn’t solve coordination. The founders had built system models at Airbus and ESA and operated 8 satellites, so they were my first source of domain knowledge.

• Sessions every 2–3 weeks with both founders: first we reviewed progress and conclusions, then we sketched together how they saw each part of the satellite.
• Feedback from external engineers, which the founders gathered and brought to each review.
• Between sessions, work with the real materials they shared with me: mass sheets, interfaces and requirements matrices.

We started from four proto-personas defined with the founders: a technical sales rep, a junior systems engineer, a lead integration engineer and a compliance lead. They were hypotheses, not research, but their frustrations matched: scattered, outdated information and no way of knowing which version is right. And there was a clear pattern with AI: they would use it if it saved them work, but only if it respected their standards and its work could be reviewed.

1. “If I can’t find the right information quickly, I lose a business opportunity.”
2. “If I had clear examples of previous documents, I’d learn much faster.”
3. “I don’t have time to check every detail; I need the documentation to be clear from the start.”
4. “Without clear, precise documentation, the project doesn’t pass review.”

Initial proto-personas. Starting hypotheses, not research findings.

1. The key moment was trying to map how the chat would be used in a real workflow. The chat answered questions, but the work still lived in spreadsheets and documents. The more we looked at how an engineer works, the less sense it made.
2. Engineers think in components and cables, not in the standard’s blocks and relationships. SysML v2 syntax was a barrier, not a help.
3. What they needed first wasn’t to draw the system, but to know what breaks when something changes.
4. An AI agent only earns trust if its work can be reviewed like a colleague’s.

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.

What I didn’t build

In a 10-week 0 → 1, deciding what not to do weighs as much as what you do.

I didn’t design for everyone at once. When we moved from the chat to the model, the engineer became the primary user. The technical sales rep was left out of this first version: what they needed was to look up information, closer to a search engine over the documentation than to a workspace.

I didn’t build a Miro-style freeform canvas: loose boxes and arrows would have broken the model, so every line is a real physical connection and the impossible can’t be drawn. I didn’t offer colour or style options: colour only signals state, never decoration. I didn’t let anything, people or agents, change safety margins without explicit approval. And I didn’t redesign what the standard already solved well: the formal model stayed intact beneath the interface.

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.

Learnings

1. The first design decision was to question the solution. A chat was the obvious answer for an AI product; understanding the real work is what showed the value was in the model, not the conversation.
2. With expert users, you don’t hide complexity: you organise it. Hiding the syntax worked because we never hid the data.
3. Trust in an agent comes from the process, not the conversation. Giving it the same rules as a person (permissions, review, traceability) settled more doubts than any on-screen explanation.

What I’d do now

Systellar has already built part of what came next: more autonomous agents and work in parallel with engineers. If I went back today, I’d focus on three things:

• Measure the real savings. The website promises to win back engineering time. I’d validate it with teams like Tumbleweed, measuring how much manual reconciliation work disappears.
• Review at agent scale. When agents generate many changes at once, reviewing change by change doesn’t scale. I’d group review by intent: what you were trying to achieve and what was touched to get there.
• Go beyond space. Systellar’s ambition is any complex hardware, not just satellites. I’d test which parts of the nodes, ports and requirements mental model work in other domains and what needs adapting.

Closing

In this project, the most valuable thing wasn’t a screen, but changing the starting solution. The idea was a chat; the product ended up as a living model of the satellite with agents working inside it, and a year later a real team is building its spacecraft in it.

In deep tech, design is what decides whether the technology gets used.