How We Stop 80% of Integration Bugs Before Ever Building a PCB

What we talked about.

Peter Brady, founder of Certo Systems, joins Sunny Ray to explain how his company lets software teams build and test against hardware before it physically exists. Drawing on nine years in electrical engineering and hardware roles, including submarine sonar software work alongside integrator Lockheed Martin and later counter-unmanned aerial systems using RF technology in defense contracting, Brady describes the recurring bottleneck of software teams waiting on scarce, expensive hardware. He explains how Certo EMU codifies hardware behavior into a virtual hardware behavior file, using TCL scripting to mock system calls at the operating system level so engineers can develop and test without physical devices. The conversation covers importing schemas from existing header files, emulating registers and system calls, observing timing and payloads, and future plans for cloud based multi instance emulation and raw data playback. Brady also shares his path from a power grid operator trainee role through defense contracting frustrations that pushed him to found his own company, aiming to bring certainty to hardware and software integration through emulation.

Certo Systems lets teams build and test software against hardware behavior before the hardware or firmware even exists.

The questions, and the answers.

What are you building at Certo Systems?

I'm building a hardware mocking tool that works at the operating system level, using file descriptors to spoof hardware. It lets you define what data comes in and out, so software teams can interact with virtual hardware behavior without needing the actual device.

What drew you to the hardware layer initially?

I started in general engineering wanting to work in alternate energy, but I didn't understand the underlying electricity generation. Electrical engineering classes in power electronics and analog circuit design pulled me toward the electric grid, which led me to a system operator trainee role.

What did years at defense and intelligence contractors teach you about hardware and software teams breaking down?

On the submarine sonar project, we constantly waited on integrators like Lockheed Martin for hardware and locked down operating systems. Later in counter-UAS RF work, teams often shared a single million dollar piece of equipment among dozens of engineers, causing constant clashes and delayed timelines.

When did it click that you could codify hardware behavior so software teams could build against it before hardware existed?

It clicked while experimenting with PulseAudio, a Linux audio server. I realized you could subscribe to data streams and manipulate them, and since Linux uses file descriptors as its hardware interface, I saw a way to spoof that interaction without requiring a new API, similar to how a debugger works.

You claim hardware development can now be fully agile. Can you walk me through that?

Software can make requests to a virtual hardware behavior file, and the Serto engine runs it without needing a UI, working in a CI environment. Eventually kernel drivers and hardware description language files like Verilog could plug into this so real hardware and software mocks can both make requests against the same modeled behavior.

What made you leave a stable defense career to fix this problem yourself?

I grew frustrated that my work quality suffered because I couldn't properly test changes. Our simulators were outdated but I wasn't allowed to improve them, since the government prioritized paying for immediate features over long-term tooling. I realized building something affordable myself could actually fix that for other teams too.

Can you explain plainly what Certo lets a hardware team do on day one?

You import your existing schemas or header files to define your structs and system calls, or use templates like USB. Then you script behavior per system call using TCL, defining variables like registers. Software engineers can toggle emulation, override return values, and observe system call timing and payloads to verify health.

Your first wedge is RF and software defined radio. Why start there?

I'm starting there mainly because it's what I know best from my own experience, so I can speak to the pain points more credibly. I'm not entirely certain yet where the product expands from there, but that domain is where my personal frustration and expertise both originated.