Questions.

We design and build the electronics and the firmware inside physical products. A client comes to us with a product they want to exist — a soldering iron, a pill case, a diagnostic instrument — and we take it from the first block diagram through to the boards coming off a manufacturing line.

That covers electrical design, firmware and embedded software, connectivity, design for manufacturing, test, and the program management that holds the schedule together. It does not cover the industrial design or the enclosure.

Both, and the combination is powerful. Most of the problems that cost a hardware project its schedule sit on the boundary: a sensor reading that is noisier than the datasheet promised, a power rail that sags when the radio transmits, an address conflict between two chips.

A team that only writes firmware has to ask for a board change. A team that only designs boards has to ask for a firmware workaround. We can look at a problem and pick whichever side is cheaper to fix. On Enso that meant solving an I2C address conflict in firmware instead of respinning the board.

We are also happy to do one and not the other. On Humane we started as hardware oversight and were asked to take over the firmware later.

Yes, and that is the work we are built for: complete system design from the earliest ideas through mass production.

Not every project goes the whole way, and that is fine. Some end with working prototypes, because prototypes were the goal. Some end by handing the electrical design to a JDM who makes the small changes a line needs. On others — iFixit is the example — we share ownership of the electrical and test fixture design with your team through the scale-up to high volume manufacturing.

Tell us where you want it to end and we will shape the engagement to that.

No. Intercreate does not do mechanical design, but we work closely with our trusted mechanical engineering partners.

Where the two sides meet is the mechanical control outline — the drawing that fixes board shape, keep-outs, connector positions and mounting points. We work with the mechanical engineers to arrive at a board size and shape that suits both the circuit and the enclosure. The mechanical design itself is theirs. On Emme the mechanical work came from Spanner Product Development and our engineers were in the room with them from the first planning session.

If you do not have a mechanical partner yet, ask us. We have worked alongside several and can tell you who fits the kind of product you are building.

We build the device side of it, and the interface the app is written against. That means the Bluetooth or network link, the commands and data the app can send and read, and the firmware framework underneath — built first, so that app development has something stable to sit on.

Often the app itself is written by your own software team or a specialist studio, and we work with them. We also build apps when that is what a project needs. On Emme we implemented BLE so the case could tell the phone what had happened to it, then built an app on top of that framework. On Enso the app records a heartbeat, stores it in the cloud and pulls it back, and we built everything on the device end of that.

We also work in Android and AOSP, on products that run a full operating system rather than a companion app. Navdy, an aftermarket head-up display that sat on a car's dashboard, and Orro, a smart light switch, are two of the products that work has gone into.

Consumer tools, medical and diagnostics, wearables, health and wellness, industrial, and connected consumer devices.

The published examples: a portable soldering iron and power station for iFixit, a compute module for Roche's instrument test setups, a smart birth control case for Emme, a device that plays your heartbeat back to you for Enso, the charge case and charge pad for Humane's AI Pin, a Wi-Fi landline for kids for Tin Can, a power and cooling case for Genius Sports, and a rigid-flex board for an AR light engine for Avegant. Other clients include Google, Logitech, Intel, Sphero, Fellow, Eight Sleep, Terra Kaffe, Level, AethLabs, Vantage Robotics, Raya Power, Halo and Orro.

What the list has in common is not an industry. It is products with hard physical constraints — power, size, heat, radio, cost — where the electrical and firmware decisions have to be made together.

Though we tailor our process to each project, there are typically four phases:

Architecture. Component selection, signal and power block diagrams, collaboration on the mechanical control outline, breadboarding and simulation, the non-form-factor schematics and layout, the firmware architecture and test framework, device drivers on dev kits, OTA update support, and bring-up.

Form factor. The improvements from the non-form-factor build folded in, collaboration on the detailed MCO, final schematics and layout, firmware application development, cloud and device interfacing, manufacturing support and a second bring-up.

Manufacturing prep. Automated test fixture design, DFM improvements, collaboration with the contract manufacturer, support for regulatory and environmental testing, firmware feedback from user trials, and EVT, DVT, PVT and mass production management.

Post-launch. Bringing the BOM cost down, RMA triage, statistical process control, support for the line, OTA updates going out to users, fleet management of the data coming back from the field, support of the IC supply chain, and a formal hand-off of the design.

There is more detail on how we work.

Because the cost of changing your mind is completely different on the two sides.

Changing a board after layout means a new fabrication run, new assembly, new lead times and new money — weeks, at best. So hardware gets waterfall: requirements and the non-form-factor board in the architecture phase, then form factor, then EVT, DVT and PVT during manufacturing prep, each step largely settled before the next starts.

Changing firmware means a rebuild. So firmware gets agile, and the firmware milestones integrate with the hardware milestones without depending on them.

That only works with the supporting practices actually in place: automated unit and integration tests, TDD, a story tracker, early OTA support, and a proper hardware abstraction layer so the next board revision does not invalidate the application code.

Earlier than most people do. The decisions that set a product's cost, size, battery life and schedule are made in the first few weeks — which chip, which radio, how power is distributed — and they are the decisions that are expensive to revisit later.

The best moment is when you know what the product should do and have not yet committed to how. We can run the architecture phase, prove the risky parts on a non-form-factor board, and give you a cost and schedule based on something measured rather than estimated.

That said, we join projects at every stage. On Humane we came in to oversee hardware designs someone else had drawn, and later took over firmware that was already written and not production quality. If a project is already underway or already in trouble, that is a normal conversation to have with us.

If you only have an idea and no requirements yet, talk to us anyway. Working out what the product has to do is part of the first phase.

A non-form-factor board is a deliberately oversized first version of the electronics, built before anyone is constrained by the enclosure. It exists to prove the architecture while changing it is still cheap.

We use that phase to validate the signal and power block diagrams, to breadboard and simulate the parts of the design we are least sure about, and to find the decisions that cost less to change now than after layout. Spreading the circuit out makes it easy to probe, cut and rework, which is exactly what you want from a board whose job is to be wrong in informative ways.

On the iFixit Power Station and Soldering Iron the non-form-factor phase is what established there should be three boards rather than fewer, and it surfaced a safety decision: individually replaceable battery cells were replaced with a safer way of swapping the whole pack.

Bring-up is the first time firmware runs on a new board, and it is a milestone we treat seriously because it is where the assumptions hardware and firmware made about each other meet reality.

Power comes up one rail at a time and gets measured. Each interface is proven in turn. The device drivers we have been writing on dev kits while the boards were being fabricated move onto the real hardware, and the differences between the dev kit and the real thing come out.

Problems found at bring-up are either a board change or a firmware change, and because we do both we can choose. That choice is often what protects the schedule.

They are the three factory builds between a working design and mass production, and each one asks a different question.

EVT, engineering validation test, is the first build at the factory in small numbers. Does the design work at all when somebody other than the design team assembles it?

DVT, design validation test, is larger and uses production tooling. Does the product meet its specification and pass certification — drop, temperature, radio compliance?

PVT, production validation test, runs on the real line at close to real speed. Can the factory build this, repeatably, at the rate the forecast needs?

Mass production follows. Test fixtures get developed and refined across these builds — on iFixit, running the first versions through EVT and DVT is what showed the test software needed work, and fixing it cut test time 50 to 70%.

Supply is part of electrical design, not a separate problem that arrives later. We select alternates and second sources as we go, which matters as much for obsolescence as for price.

The 2020–2022 microcontroller shortage is the honest test of that. We secured STM32 parts ahead of the EVT builds by leaning on distributor contacts. Where that did not work — the battery charger and the PMIC were both more than a year out — we designed in replacements with less supply risk rather than waiting for the originals.

After launch, supporting the IC supply chain stays part of the job.

Deliberately ordinary ones, so that nothing about the project depends on a tool your team cannot get.

Altium Designer for PCBA and FPCA design. The GNU toolchain for compilation. GitHub for both hardware and software design assets. Linear for features, progress and bugs. Smartsheet for schedule tracking. Slack for day-to-day communication.

The build tooling we use on firmware projects is open source and public, so your engineers can read it and keep using it after we hand over — see our CMake build and test tools.

A shared channel and a regular meeting, set up at the start. Collaboration that depends on people remembering to send updates does not survive a busy month.

Features, progress and bugs go in one tracker that both sides can see. Requirements are agreed in writing before work starts, so there is a document to point at when a question comes up six weeks later.

Roche shows why the written part matters. We wrote a product requirements document with an electrical engineer on their team that set out exactly what we would deliver and what success meant. Halfway through the project our liaison left the company — and because the goal and the deliverables were written down, we could bring the replacement up to speed quickly. The module was delivered in five months, on time and on budget.

Yes, on every project, without exception. We also review designs somebody else drew, when a manufacturer or another partner is the one responsible for them.

A review is where someone who did not draw the schematic looks at it before it goes to fabrication. The cost of an hour of that is nothing next to the cost of a board respin, and the things it finds are rarely subtle in hindsight.

What is uncommon in this field is having the client in the room for them. We think a design review works best when the people who commissioned the product are involved in it, and we run them that way wherever a client wants to be.

We also document experiments and test plans, so a result from month two is still checkable in month eight.

It is a fair question to ask, and the answer depends on what you need from us rather than on headcount alone.

What eleven people buys you is that the people in the meeting are the people doing the work. The team is ten electrical and firmware engineers and a senior program manager, and both partners — Dave Desrochers and Rob Helvestine — are principal engineers who are still on projects. Nobody is handed off to a different team after the proposal.

What it also means is that we take on a certain number of programs at once and we are straight with you about capacity before we start. We are not the right choice if you need thirty engineers on a product next month.

Two examples of scaled projects: three boards and five test fixtures on iFixit, and on Humane a three-month sprint from zero to production-quality firmware on an accessory shipping alongside a major launch.

The engineers whose names are on the work. Our case studies name the principal engineer who led them, so you can see who did what before you hire us.

A typical project has a principal engineer who owns the technical direction, the electrical and firmware engineers doing the work, and a program manager keeping the schedule and the communication honest. On smaller projects those roles overlap. Both partners are practicing engineers and take project work themselves.

Rigid PCBAs and custom flex assemblies, including high-speed signaling, radio frequency and power systems.

Flex matters more often than people expect, because it is what gets a circuit into a space a rigid board cannot reach. The Humane Charge Case shows what that looks like: a curved enclosure with tight internal volume and fixed positions for sensors and connectors ruled out any conventional layout, and the final design packed two rigid boards and two custom flex boards inside it. The ground-up design there came from Humane's contract manufacturer; our job was to make sure it met specification and integrated with the AI Pin.

The work runs from component selection and schematics through layout, bring-up and hardware validation — plus the alternates and second sources that keep a design buildable when a part goes end-of-life.

Yes. The mechanical control outline is the normal starting point for the form factor phase, and we work to it rather than against it.

If the outline turns out to be impossible — and sometimes it is, when the circuit simply will not fit in the volume — we come back with what would have to change and what it costs, early enough for the mechanical team to do something about it. That conversation is much cheaper in the non-form-factor phase than after tooling.

Often, yes, if that is a stated goal from the start. It is a design decision about which interfaces to expose, not something that can be retrofitted.

Roche asked exactly this question: could one common PCBA cover test setups nobody had specified yet? It could. The compute module we delivered exposes CAN, I2C, PWM and IO-Link to a backplane board, so future test setups reuse the module instead of starting over.

The trade is cost and size against flexibility. Worth making explicitly rather than by accident.

It happens on most projects. What matters is whether the fix costs you a respin.

On Enso, the first form factor boards came back with an I2C address conflict designed in — two devices wanting the same address on the same bus. A respin would have cost schedule and budget. Instead we configured the pins dynamically in firmware, based on which device the MCU needed at the time. The project stayed on schedule.

That option exists when one team can see both sides. On Enso the schematics and layout came from the project's hardware contractor while we wrote the firmware, and knowing both is what turned a respin into a firmware change. When a respin genuinely is the right answer we say so, and we fold the other pending changes into the same iteration so you pay for one spin rather than two.

Yes, from the first week, and it is one of the things that keeps a firmware schedule separate from a hardware schedule.

Unit and integration tests run automatically. We practice test-driven development. Because those tests run on a PC rather than on the product, firmware work can start and be verified before there is hardware to run it on.

The build and test tooling that makes this work is open source — our CMake build and test tools include a unit test framework for the build system itself, not only for the firmware it produces. Your team can read it and keep using it after we hand over.

Yes, and we plan for it from the start rather than adding it late. Over-the-air updates are supported early in the architecture phase, so updating a device is a solved problem long before anyone needs it.

Two reasons to do it that way. The first is that a bootloader and an update path are hard to retrofit into a design whose memory map and power budget were set without them. The second is that the worst outcome, an update that leaves a device unable to boot, is what those early decisions are there to guard against. On Enso that meant a custom bootloader with integrity checks, so a device is never left running mismatched firmware across its two chips.

After launch, OTA updates are part of how a product is supported: firmware feedback from user trials and from the field goes back out to users.

Yes. We wrote a custom bootloader to do it, because no vendor supported the arrangement.

Most devices have a single MCU with built-in bootloader support. Enso had physically separate main and BLE chips, and no vendor had an answer for upgrading both. We wrote a bootloader with integrity checks that upgrades the pair together, so a device is never left running mismatched firmware on the two halves.

Field upgrade is where connected products go wrong, and the problem does not stop at the protocol. The work that goes into getting an update path right is the same work every time, which is why we made ours reusable and published it as smpclient and smpmgr.

RTOS, Linux and POSIX, and bare metal where the chip demands it.

In practice that has meant FreeRTOS — used on Enso alongside a vendor PPG signal-processing library to read heart rate — and Zephyr, which our open-source smpclient and smpmgr tools target. We also do AOSP and Android work on products that need a full operating system.

The choice is driven by the product, not by preference. What stays constant is a proper hardware abstraction layer underneath, so the application code survives a change of board or chip.

Yes. Some chips do not give you the option, and the work then includes the build system as well as the firmware.

The Humane Charge Case is the example. The chosen MCU meant bare-metal development, and we built the entire build system from scratch — three months from zero to production-quality firmware, with field upgradeability included.

That project also shows why electrical depth matters on bare metal: sweat could form on the charging contacts and create intermittent shorts during charging, which over time discolored the contacts. We characterized the failure mode and wrote firmware that detects it and handles it gracefully.

There is a saying that software is never finished, only abandoned. We would rather ours was not, so handover is part of the process and not an afterthought.

Concretely: we write maintainable, modular source code for somebody else to pick up. Hardware and software design assets live in your GitHub. The build tooling is open source, so nothing in the build depends on us still being there. And if you are building an in-house team to take the work on, we train them on the codebase and the hardware design assets, and sit in on technical interviews where that helps.

At the end of a project there is a formal hand-off of the design.

Yes, local and overseas, and with third-party test vendors. We have years of experience working directly with them rather than through an intermediary.

On iFixit that meant three trips to Taiwan across 2023 and 2024, plus a great many remote hours supporting the engineers on site. Being in the factory is how you find out that a fixture is slower than it needs to be, or that an operator has invented a workaround nobody documented.

We can work with a contract manufacturer you have already chosen, and we will tell you honestly what we think of the fit.

Up to 1000 units a day, with contract manufacturers and third-party test vendors.

At that rate, test stops being something you improvise on the line. The log file formats, the limit analysis, the statistical process control and the automation that minimizes logistics all get designed in advance, because a fixture that takes thirty seconds too long multiplies by a thousand every day.

That is also where fixture design pays for itself. On iFixit, redesigning parts of the fixture software interface along with some hardware changes cut test time by 50–70% at each station.

A bed-of-nails fixture is a test jig with an array of spring-loaded pins that press onto test points on a bare board. An operator drops a board in, closes the lid, and every circuit is checked in a few seconds.

You need one per board if you are building at volume — it is how a factory catches a bad solder joint before it becomes a returned product. You probably do not need one for a prototype run.

iFixit shows the shape of it: three unique PCBAs meant five fixtures — a bed-of-nails for each of the two main boards, a functional fixture for the user interface board, and two final assembly fixtures for the built units.

Fixtures need the board to be designed with them in mind, with test points a pin can reach. That is part of DFM, and it is why fixture design starts before the layout is final.

Yes. On iFixit it was three trips to Taiwan over 2023 and 2024, around the EVT, DVT and PVT builds, with remote support between them.

Being there matters most at the first builds, when the fixtures meet real operators and real volume for the first time, and when a problem needs someone who can look at the board and the firmware in the same afternoon.

Travel is agreed in advance as part of the engagement.

Launch is not the end of the engineering, and we stay involved when a client wants that.

Post-launch work covers bringing the BOM cost down. Supply chain management, including qualifying and approving alternate parts as the originals change or go end-of-life. Continued firmware development, with OTA updates going out to users. Fleet management: watching the data coming back from devices in the field to find and fix bugs. RMA triage, which is the fastest signal that something in the design or on the line is wrong. And statistical process control on the measurements coming off the line, so drift is corrected before it produces failures.

Then a formal hand-off of the design, whenever you want that to happen.