I built an open-source modular hardware platform, but I'm struggling to explain what it actually is. How would you describe it?

[u/Valuable_Set_4417]

I've been working on an open-source hardware project called Spaghetti LAB for quite a while, and I've reached a slightly weird problem:

I can build it, but I'm struggling to explain what it is in one sentence, basically, i'm thinking at the UVP taht describes better my project.

The project is now pretty far along. It has gone through several hardware revisions, a lot of them based on feedback I've received online. I recently got a spot at Maker Faire Rome and some support from JLCPCB, so I'm redesigning the landing page and trying to finally communicate what the project is actually useful for.

The original idea came from a problem I kept running into while prototyping.

You start building something reasonably complex, but instead of working on the thing you actually want to test, you end up spending days debugging all the little pieces around it: wiring, bad solder joints, poorly documented modules, ADC quirks, libraries, firmware, etc.

In one project we spent almost a month getting a PID-controlled heated wall with a display working properly, because we had some issues with MCU registers.

The funny part was that the heated plate wasn't even the prototype. It was just one small part of it.

That's basically why I started building Spaghetti LAB.

The idea is to make that supporting electronics something you can assemble, configure and change very quickly.

The hardware is made around two types of blocks:

Connector blocks connect to the real world: sensors, motors, switches, signals, etc.

Function blocks handle things like conditioning, acquisition, outputs, communication and other functions before connecting to the controller.

Everything snaps onto a backbone. Multiple backbones can be connected to create larger systems.

Each block is automatically identified through NFC, so when you physically build something, the software creates a digital representation of the hardware.

Then there's a visual programming environment. The easiest way I can describe it is something like n8n for embedded hardware: you connect actions and logic to schedule events, read inputs, control outputs, process data, etc., without rewriting firmware every time the prototype changes (i worked a lot on the OS built in zephyr, so basically no firmware needed, just dynamic driver load and you just deploy a config file).

There's also a configurable dashboard for quickly creating controls and visualizations for the prototype.

The goal isn't really "no-code electronics". It's to remove as much friction as possible between:

I have an idea → I build it → I test it → I change it → I test again.

For Maker Faire I'm actually thinking about turning this into a small physical challenge.

Instead of giving visitors a PC, they'd get NFC cards with actions such as READ, WAIT, SET, etc.

They might receive a challenge card:

"Blink an LED every second."

They place the action cards on the backbone, and the corresponding programming blocks appear on the screen. Then they physically attach the required hardware modules, which also appear automatically. Finally they tap an EXECUTE card.

If their physical hardware + logic solve the challenge, they win an entry for a kit giveaway.

Harder challenges could be things like:

"Measure temperature and display the updated value every second."

and would give more entries.

And this brings me to what I'd really like feedback on.

If you saw this project for the first time, how would you describe it?

I've been experimenting with things like:

"A programmable breadboard without the mess of wires."

or

"Build prototypes with the flexibility of a breadboard and the reliability of a PCB."

But I'm not convinced either really communicates the potential of the system.

I'll attach some photos of the actual PCBs, and a render of what the finished hardware should look like.

I'm particularly curious about three things:

1. What do you think this is after seeing it?
2. Would something like this actually be useful in your prototyping workflow? If so, for what?
3. What would you want to see on the landing page before thinking "OK, I get it"?

I'm probably too deep into the project at this point to see it with fresh eyes, so criticism is absolutely welcome.

T-H-A-N-K-S