Menu — services & more

AI & Agents

AI Strategy Consulting MCP Servers, Plugins & AI Skills AI Agent Development Voice AI Agents Video AI Agents Chatbots & RAG Generative AI Apps Development AI Integration AI Business Process Automation

Build & Design

E-commerce Development Full-Stack Web Development Mobile App Development Product Rescue UI/UX & Product Design 3D, Animation & Computer Vision Product & Technology Consultation

Teams & Scale

Product Engineering Team Staff Augmentation Legacy Modernization Custom ERP, CRM & Operations DevOps & Cloud Engineering Data Engineering & AI Data Readiness API Integrations

Hardware & IoT Lab

Embedded Firmware IoT & Edge AI Hardware & PCB Design Prototyping, Assembly & Testing Hardware & IoT Lab →

Audit & Human Oversight

Protection from AI Threats Code & Developer Audit AI Code Cleanup & Cloud Cost Optimization Code Review as a Service QA & Test Automation

All services → Industries Our Work About

C++ and embedded engineering for code you cannot roll back.

A bad web release is embarrassing for twenty minutes. A bad firmware release is a truck roll, a bricked unit, or a machine that stops with something expensive inside it. We write and modernise the kind of software where the recovery path is designed before the feature path.

FACT 01Modernised the C++ control software driving tunnel-boring machines — with the machines still in service.

FACT 02Built the operating system, firmware and software for a smart electric power station, over three years.

FACT 03Shipped kernel-level detection and automated remediation inside a security product — Linux kernel modules and Windows drivers.

See an update survive a power cut ↓

30 minutes, working session. You leave with a one-page read of your system either way. Nobody follows up more than once.

Electronics, from schematic to enclosure

We design the device, the board and the enclosure, order fabrication and components, then assemble, program and test on our own bench. The firmware is written by the people who drew the schematic — which is the difference between debugging a board and arguing with a supplier about one.

DESIGN

Device design — the electronics, the firmware and the mechanics decided together
PCB design — schematic and layout in Altium
Enclosure design — mechanical CAD in SolidWorks, built to be assembled and serviced
Prototyping — a first working unit before anyone commits to a production run

ASSEMBLY

SMT assembly
Through-hole assembly
Enclosure assembly — boards, wiring, panels and glands into the finished unit
Small batches assembled in-house; larger runs prepared for a contract manufacturer

TESTING

Functional testing — every unit exercised on the bench before it ships
Test fixtures built for the board, so testing scales past one careful person
Pre-compliance checks, so the certification lab is a formality rather than a surprise

Schematic and PCB layout of the same board, side by side — SCHEMATIC → LAYOUT

Exploded CAD view of a device: enclosure halves, front panel, display and boards — DEVICE DESIGN

Enclosure with a machined display window and its board on the bench — ENCLOSURE DESIGN

First prototype mounted in its enclosure, modules point-to-point wired — PROTOTYPE

Bare printed circuit board with its components laid out around it — BOARD + BOM

A fabrication batch of boards standing in an antistatic rack — FABRICATION BATCH

A through-hole connector being placed with tweezers — THROUGH-HOLE

A run of assembled modules in a carrier, ready for test — ASSEMBLY RUN

A board clamped in a bed-of-nails test fixture — TEST FIXTURE

An assembled board on the bench wearing its PASS label — FUNCTIONAL TEST — PASS

OUR BENCH AND OUR BOARDS. NO STOCK PHOTOGRAPHY ON THIS PAGE.

The conditions we usually get called into

None of these mean anyone did a bad job. They are what software near hardware looks like after it has been earning money for a decade.

INHERITED C++

The codebase predates the team

Fifteen years of C++, written by people who have left, with conventions from three eras interleaved. It works. Nobody wants to touch it, and every estimate for changing it carries a silent risk premium.

UPDATE PATH

The update mechanism was an afterthought

No robust bootloader, so an interrupted update bricks the unit. Every firmware release is now a genuine risk, and the release cadence has collapsed to twice a year.

FIELD ONLY

The bug that never happens on the bench

Eleven days of uptime, one customer, temperature-dependent. Somewhere there is a race, a leak or a drifting sensor — and the only evidence is a log that was never designed to be read.

ARCHITECTURE

The rewrite that cannot happen

Everyone agrees the architecture is wrong. Nobody can stop the machines for six months. So nothing changes, and the codebase gets one more layer of workaround per year.

OPERATOR UI

The HMI is an insult to the machine

Precise, expensive hardware fronted by an operator interface from 2009 that nobody can use without training — so the equipment runs at a fraction of what it can do.

TEST GAP

Nobody can test the hardware path

The suite covers the parts that never touch the device. The parts that do are tested by a person with a bench, occasionally, before a release.

Run in production, not claimed

Four pieces of work, stated flatly. Each links to its own case page.

TUNNEL BORING
CIVIL ENGINEERING
C++ / HMI

Control software for tunnel-boring machines, modernised in service

Aging C++ driving tunnel-drilling equipment. The hard part is exactly that: no window in which everything stops, so the modernisation was staged, and every change had to be safe against a machine that is underground and working. Client–server C++ with calibration storage over EEPROM and flash, and a touch-first operator interface built for gloved hands.

RESULT: 90% less manual operation · 240% efficiency gain

ENERGY HARDWARE
3 YEARS
OS / FIRMWARE

Sonnenrepublik — embedded R&D for a novel power station for PV systems

A multi-year firmware programme for sonnenrepublik.de. This is a product people plug their house into: the update path, the failure modes and the recovery behaviour are the product, not features of it. CI ran with a real device attached — the hardware path was covered by tests, not by a person with a bench.

SECURITY
KERNEL LEVEL
LINUX / WINDOWS

Kernel-level detection and automated remediation in a security platform

EDR, SIEM, IPS and IDS in one open-source-based product, with detection in Linux kernel modules and Windows drivers. Code at that level fails in ways that take the whole machine with it, and remediation that acts automatically has to be right more reliably than a human on a rota would be.

R&D
PROTOTYPE
SIGNAL

BCI × AR glasses — an R&D prototype

An EMOTIV brain–computer interface paired with Magic Leap AR glasses, plus our own TheCap smartcap. The hard part is signal: a noisy biological input, on a wearable, turned into something a system can act on without acting on noise. This was R&D and we present it as R&D.

Bring the system behind numbers like these. We will tell you where we would start.

Cut the power yourself

Two devices receive the same firmware update. One writes over its only image. One writes to a second partition and keeps the old image until the new one boots. Start the update, then cut the power whenever you like — mid-write is the interesting moment.

SCHEMATIC — SIMPLIFIED FLASH MAP, NOT A REAL DEVICE T+0.0s

DEVICE A — SINGLE PARTITION, NO FALLBACK

STATE: RUNNING v1.4

Waiting. The only copy of the firmware is the one about to be overwritten.

DEVICE B — A/B PARTITIONS, ROLLBACK ON FAILED BOOT

STATE: RUNNING v1.4

Waiting. Slot A stays intact whatever happens to slot B.

The difference is not the write. It is everything designed around the write: the second slot, the boot counter, the rollback on failed boot, the brown-out behaviour. That design work happens before the first feature — on the Sonnenrepublik programme it is what made a home power station updatable at all.

A board under test on the bench in our hardware lab, with probes and a wire harness attached

The device on the other end of the pipeline

A test that runs against hardware, not against a mock

The rollback above is only real if something exercises it. This is the other end of that pipeline: a board on the bench with probes and a harness on it, running the firmware a release will ship. Our hardware lab in Chisinau, Moldova. Sonnenrepublik case →

The work, as we actually sell it

Timelines are indicative ranges and depend on scope. Where a job is unpredictable, the range says so.

A written read of the system you inherited

2–3 WEEKS

Architecture, the parts that are safe to change, the parts that are not, the update path, and what a modernisation would cost in sequence. Fixed price. You keep it either way.

Staged modernisation with the machines running

12–30 WEEKS

Module by module, tests pinning the behaviour that has to stay identical, and no window in which the system stops — the tunnel-boring pattern.

Firmware update and recovery path

6–14 WEEKS

Bootloader, A/B partitions, rollback on failed boot, an update that survives power loss mid-write. Usually the highest-return work available on an existing product.

The field bug

3–8 WEEKS

Instrumentation designed for a device nobody can attach a debugger to, sanitiser and static-analysis passes, and a reproduction rig. Priced honestly: some of these are found in a week and some take a quarter.

Operator interfaces for real machines

8–16 WEEKS

An HMI built for someone wearing gloves, in poor light, who needs the machine’s state legible at a glance — not a dashboard that looks good in a screenshot.

Hardware-in-the-loop testing

4–10 WEEKS

A CI pipeline with a device attached to it, so the hardware path is covered by tests rather than by a person with a bench. We run this on our own projects — the Sonnenrepublik firmware ships this way.

Performance work in C++

SCOPE-DEPENDENT

Profiling first, then allocation, cache behaviour and algorithmic change — with before-and-after measurements on your target hardware, not on a laptop.

Electronics, designed and assembled

WITH THE ABOVE

Device, board and enclosure designed here; fabrication and components ordered; assembly and test on our own bench. The bench, in pictures ↑

Hardware we have shipped on

Named because we have run them, not because they are on a keyword list. If your target is not here, ask — the honest answer might be no.

STM32ESP32AVRFreeRTOSSTM32CubeESP-IDFC / C++ / Python

I2CSPIUARTCANModbusBluetooth / ZigbeeJTAG / SWD

Bench work with oscilloscopes and logic analysers; board design in Altium, mechanical in SolidWorks. On the software side: RAII and ownership in the type system, allocation kept out of hot paths, sanitisers over argument, and logging designed for a device nobody can attach a debugger to in the field.

Fluvius engineers in a working meeting at the European Space Agency stand in the Netherlands, laptops open across the table

Near the people who build the hardware

The constraints come from the room, not a datasheet

A working session at the European Space Agency stand in the Netherlands. Firmware arguments are settled the same way everywhere: in front of the device, with the people who have to service it. More about how we work →

What you are probably thinking

“Our machines can’t stop.”

They did not stop for the tunnel-boring modernisation either. That is why the work is staged, with tests pinning current behaviour before anything moves, and why the first deliverable is a written read rather than a change.

“Is this certified functional-safety work?”

No, and we will not imply otherwise. We hold no functional-safety certification and we do not take work that requires one. What we offer is engineering discipline near hardware: recovery paths designed before features, watchdogs, update mechanisms that survive power loss, and instrumentation you can read after a field failure.

“You’re a software agency, not an embedded house.”

Fair challenge — judge the record rather than the label: tunnel-boring control software modernised in service, an operating system and firmware for a power station over three years, kernel-level detection in a security product. If that is not the kind of work you need, we are not the right team and will say so.

“Our codebase is fifteen years old and nobody understands it.”

That is the normal condition of software that has been earning money for fifteen years. The first engagement is a written read of what is actually there, and you keep it whether or not we do the work.

“We tried an outside dev shop and it went badly.”

Usually the same three causes: no senior person accountable, a demo-grade codebase, and a handover that never happened. Here you get direct access to the engineers doing the work, no account-manager layer, a senior architect signing off every project, and tests and documentation as part of the deliverable.

“How long before you’re useful?”

On a system like this, weeks rather than days — and we would rather say that than promise otherwise. The written read is the first useful artefact and it arrives inside a month.

The record behind the pages

200+

Clients served

10+

Years of happy clients

7+

Years our longest clients have stayed

100%

Job Success on Upwork

Many of our clients have been with us for 7+ years straight. The Upwork and Clutch records are independently verifiable.

Hardware, in the room — video

A backpack capture rig, being tried on

Immerse Global Summit, Miami Beach. Time on the floor with real devices is where a page like this gets its numbers — how heavy a rig actually is, how warm it gets, and how long its battery really lasts. About Fluvius →

Not ready to talk? Take the checklist.

One page, 13 questions about your firmware you should be able to answer before the next release — what happens if power fails mid-update, whether a failed boot rolls back, what the watchdog actually protects, what a field failure leaves behind that you can read, whether the hardware path is covered by tests, and how long a bad release takes to reach every unit.

Tell us what the machine does, what the software does to it, and what you are afraid to change.

A free 30-minute working session, not a sales call. You leave with a one-page read: the change we would make first, the recovery path we would check before anything else, and the one thing we would not touch. You keep it whatever you decide, and nobody follows up more than once.

RELATED TECHNOLOGIES → Computer Vision, OpenCV & MediaPipe XR & Spatial Computing PyTorch, TensorFlow & Pandas All technologies

AS AN ENGAGEMENT → Taking over a stalled or inherited build · Legacy modernisation, staged · All 32 services

RELATED SERVICES → Embedded Firmware IoT & Edge AI Hardware & PCB Design Prototyping, Assembly & Testing All services