Firmware that works, and stays maintainable
Firmware is the invisible foundation of your smart product. You need to be able to trust it. That starts with a good architecture, strong tooling and deliberate technology choices.
We build firmware you can build on. Literally.
From scratch, on your hardware or on a platform we choose together. Clean architecture, built to grow with you.
We also design hardware. When we do both, they're aligned from the start.
You already have a PCB, your own or from a third party. We write the firmware that runs on it.
4G, secure communication over MQTT and firmware updates in the field. Built on our sensor-link building blocks, so you don't have to build that yourself.
Together we define the requirements: what should the system do, under what conditions, and what are the boundaries? That sets the direction for every choice that follows.
We start with a clear software architecture: which tasks does the system run, how do they communicate, and where are the boundaries? That prevents spaghetti code and makes your firmware extensible. For more complex projects we use async Rust and the actor model to keep functionality and responsibilities neatly separated.
We set up a complete development environment: a working Blinky or Hello World! as a starting point, flashing tools, CI workflows with automated tests, and a clear project structure, so your team can be productive from day one.
Every change is tested and reviewed. That way we catch mistakes early and keep quality high as the project grows.
The future of the project depends on documentation. We document what matters: how to build the firmware, which configuration is important, how to connect the debugger for flashing, how the architecture fits together and how a firmware update works in the field.
That works too. We have plenty of experience with C on embedded.
To be honest, a C project usually takes more time than the same project in Rust. That has nothing to do with how well we know C: reaching the same quality in C takes more discipline and more testing. You will see that in the price.
Do you have an existing C codebase you want to extend or maintain? Then C is usually the logical choice. For new projects we recommend Rust, but the choice is yours.
Jitter B.V. has been developing firmware for embedded systems for more than ten years, five of them in Rust, these days mostly on STM32. Our embedded engineers have been through the learning curve and know where the pitfalls are. We use that experience on your project. Want to see how we work? The firmware for our sensor-link building blocks is open source.
