When you’re building a new electronic product, the software rarely wants to wait for the hardware. Just ask any of our firmware engineers here at Ignys.
Schedules overlap, pressure builds, and everyone wants early confidence that the concept is viable. That’s where development-kit prototypes, often called “devkit lash-ups” become incredibly useful.
But they’re not always the right choice.
Our tribe has seen development kits accelerate projects dramatically. Conversely, we’ve also seen them become a source of false confidence, design drift and late-stage rework. Knowing when to use them (and what to avoid) can save you weeks, or months of delay.
This guide explores some real-world pros and cons, when dev-kit prototyping is appropriate and how to work out just how much functionality your lash-up really needs.
Why devkit prototypes exist in the first place?
Waiting for custom hardware has always been a bottleneck.
Even a fast-tracked prototype run can take weeks, and that’s before you start re-spins. Firmware engineers need something to begin proving concepts, testing interfaces, and validating assumptions.
A dev kit gives you:
-A known-good microcontroller or SoC platform
-Stable power, debug connections and toolchains
-Simple access to I/O, memory and communication peripherals
-A way to start writing production-intended firmware long before the board team finishes layout
In short?
It unblocks development.
But before you race ahead, that doesn’t mean “grab any board and start coding”. Devkits chosen carelessly, can mean you end up building firmware for a system that doesn’t exist.
Where Devkits Shine
Early risk reduction – Dev kits are brilliant for quickly validating the unknowns: Bluetooth stack behaviour, camera interfaces, power consumption, RTOS choices, cloud communication, sensor handling and so on. You can answer big architectural questions before committing them to copper.
Parallel engineering – Firmware and electronics teams can work side-by-side instead of in sequence. This shortens the schedule and helps surface issues early.
Faster iteration – Dev-kit ecosystems (ST, Nordic, NXP, Microchip, TI etc.) come with drivers, demo firmware and example code. While you still need to write production-grade code, these references accelerate early bring-up.
Immediate debugging capability – Built-in SWD/JTAG connectors, built-in power monitoring, serial terminals, and known-good toolchains reduce the early friction so common in brand-new hardware.
Great for stakeholder demos – When carefully structured, a lash-up can help internal teams or investors visualise progress without needing finished hardware.
Where dev-kits quietly create trouble
Board drift – Firmware written around dev-kit pinouts, timing behaviours or peripheral quirks can diverge from what the real product will use. You end up rewriting chunks of code later.
False confidence – A lash-up will often behave better than a power-constrained, thermally limited, production PCB. Don’t assume dev-kit performance equals product performance.
Over-abstracted drivers – Vendor driver libraries often include heavy abstraction layers. They’re helpful for learning, but can hide performance issues, increase code size, or mask the real behaviour you’ll need to optimise on the final design.
Hidden hardware assumptions
Dev kits usually have:
• Different crystal frequencies
• Different power rails
• Different regulator behaviour
• Different analogue front ends
• Over-spec’d antennas or RF paths
Any of these can distort early firmware assumptions.
Debug vs production access – Most dev kits expose every pin. Your production board won’t. If your early firmware relies on having countless debug lines or unused GPIOs, you may run into trouble later.
When a dev-kit prototype is the right choice
A development-kit lash-up is usually appropriate when:
✔ The microcontroller or SoC is already chosen, so you know the exact silicon you’ll use, and an official dev kit exists.
✔ You want to de-risk communication stacks early. Bluetooth, Wi-Fi, LoRa, USB-C PD, Ethernet—these are all well-suited to early prototyping.
✔ You’re validating architectural decisions. RTOS or bare-metal? Interrupt-driven or DMA-heavy design? Sleep/wake behaviour? All ideal for early de-risking.
✔ You want firmware ready for hardware bring-up.
✔ Walking into first prototypes with stable drivers and tested application layers is a huge advantage.
When you should avoid dev-kit prototypes
Even Ignys, big fans of early de-risking, we will sometimes recommend not building a devkit lash-up…
✘ When hardware timing is critical, because things like Motor control, high-speed digital interfaces, precision analogue acquisition or tight synchronisation tasks depend on the exact PCB design.
✘ When power performance is critical, because Dev kits rarely match production-level efficiency. If microamp sleep currents matter, test on near-final hardware.
✘ When mechanical constraints define behaviour… Wearables, compact consumer devices and thermally sensitive products often behave very differently once they’re in their real enclosure.
✘ Finally, when the dev kit hides problems. Devkits can come “fully loaded” so, for example, if the real world product will have limited RAM, encoding pipelines, or strict timing, don’t rely on a devkit with oversimplified peripherals or twice the memory!
How much functionality should the dev-kit prototype include?
Here’s the trap, too little functionality and you learn nothing but too much and you’re effectively building the final product twice.
Wherever possible you should take the Goldilocks approach…
Include every element that carries project risk
If failure of that element would force a redesign, include it.
Examples:
-Wireless stack
-Power mode transitions
-Core sensor fusion logic
-Cloud communication
-Motor control algorithms
Skip anything purely cosmetic – LED behaviour, enclosures, user interface intricacies—these can come later.
Keep hardware additions minimal – Add only the essential external modules (sensors, radios, power stages). Avoid sprawling breadboards or rats’ nests of wires—noise and unreliability cause misleading results.
Match key electrical behaviours where practical – Even if you can’t replicate every detail, prioritise:
-Clock frequencies
-Voltage rails
-I/O drive requirements
-Timing behaviour of critical buses
Treat the lash-up as disposable – It’s a tool, not a prototype of the final device. Avoid the temptation to “evolve” it indefinitely.
To Conclude…
Development kit prototypes are powerful when used with intent. They’re not a shortcut to avoid thinking about your hardware architecture. Use them as a tool to accelerate learning and reduce risk.
Use a lash-up when it:
-Reduces risk
-Answers unknowns
-Helps firmware and hardware progress together
Avoid it when:
– Hardware-accurate timing, power or physical behaviour matter
– The dev kit will give misleading results
– You haven’t locked down key architectural choices
A well planned devkit prototype keeps your project moving at full speed, while a poorly planned one adds weeks of rework.
We don’t mess about, we just get your job done.