System Forge started from a practical need. When I left Valispace/Altium and started working at SSC as a systems engineer, I wanted tools that would let me design systems properly, keep full traceability and generate useful outputs like interface diagrams and reports.

Valispace was a great solution, but with the acquisition by Altium, the priorities changed and the tool started focusing more on Requirements then on System Design. I tried other tools, but none of them really felt right. Some were too expensive. Some had bad UX. Some were much better at diagrams than text, while others leaned the other way.

That mattered to me because I don't work in only one mode. Text is faster for many tasks. Diagrams are easier to understand in others. I wanted a tool that let me move naturally between both.

SysML v2 felt like a good place to start, so I began building my own approach around it. The goal was not just to support SysML, but to make it feel more flexible and intuitive.

The bigger idea behind System Forge was to make SysML the engine, not the interface. I wanted beginners to be able to model systems without having to learn raw SysML first, while still leaving that layer available for power users who wanted more control.

The kinds of systems I had in mind were the ones I knew best: aerospace, robotics and other complex engineered systems where structure and traceability matter.

The journey to get there was iterative. I started the first repository on April 25 2025, but went in the wrong direction and restarted the project three times. Each restart represented a new attempt at the architecture and each time I incorporated lessons from the previous version. The repository that powers the current version was created on May 30th, 2025. By the fourth iteration, the architecture had matured enough to feel solid.

One of the main lessons from the project was how hard UX is for this kind of tool. The challenge is not only supporting the right concepts. It is deciding where menus should live, when options should appear, how much to show and how not to overwhelm users. That part takes a lot more thought than it seems from the outside. Most people jump into developing solutions that fit other problems, but not necessarily the exact combination of problems you have to solve.

Even so, I am proud of the UX work. Systems engineers who saw the project, including people who found it through LinkedIn, often said it felt good and interesting. That mattered, because better UX was one of the main reasons I built it in the first place.

At the same time, the project made something else clear: SysML is confusing for most people. Even when the underlying model is powerful, the concepts can still be a barrier. That pushed me toward building UI abstractions that hid SysML's complexity. For example, introducing simpler, more intuitive, nomenclature and smart functions like "reusing" that could automatically convert part usage into part definition and recreate objects. The goal was to give users a simpler language and logic to work with, so they didn't have to worry about the subtle distinctions between usage and definition, or where to place things in the hierarchy.

In the end, System Forge became more of a learning-heavy project than a product I pushed all the way through. It slowed down naturally. Other projects started pulling harder and life also got in the way, including a period where I was dealing with personal changes and the possibility of moving back to Portugal.

It is still live at systemforge.app, but mostly in maintenance mode now. If you are reading this and got interested, reach out! If there is a real need, I would love to revisit this project, since I do have a special feeling about it.

I still think the core idea was good: model systems the way you think, visual when needed, textual when faster, with SysML compatibility underneath. Even if I am not actively pushing it right now, it taught me a lot about systems tooling, abstraction and the gap between modeling power and usable product design.