Firmware is software that lives inside an electronic component — usually a microcontroller — and tells the hardware what to do. If the hardware is your product's body, the firmware is its nervous system: it reads the sensors, drives the motors and LEDs, manages the battery, and talks to the outside world. Nearly every founder entering the world of electronic products meets the term early, usually when an engineer explains that the product needs "firmware development" — with a budget line to match. This guide explains, without assuming any technical background, what firmware actually does, who writes it, and what you should ask before your project starts.
Firmware in Plain Words
The key difference from "regular" software is that firmware is flashed onto the product itself and runs there permanently. The user never installs it and is usually unaware it exists. Every modern electronic product has firmware: a smartwatch, a coffee maker, a drone, a thermostat.
A simple example: when you press the button on a smart kettle, the firmware detects the press, reads the water temperature from a sensor, switches on the heating element, turns it off at the right moment, and sends a status update to the phone app. All of that happens in fractions of a second, over and over, without anyone noticing — and that's exactly the mark of good firmware: it's invisible to the user.
Firmware vs Software vs App: The Three Layers
The most common point of confusion is between the three software layers of a connected product:
- Firmware — runs on the microcontroller inside the product, controlling the hardware in real time.
- Mobile app — runs on the user's phone and serves as the control and display interface, often over Bluetooth; see our guide to BLE app development cost.
- Cloud software — runs on a remote server, storing data and syncing between devices.
Getting the three layers to talk to each other smoothly is one of the central challenges of any connected-product project, and a major driver of IoT product development cost.
Who Writes Firmware — and How
Firmware development is a discipline of its own, sitting at the seam between software and electronics. An embedded engineer needs to understand both code and hardware: they write in languages like C or C++, work directly against the circuit schematics, and deal with constraints that don't exist in ordinary software — kilobytes of memory instead of gigabytes, minimal power consumption, and hard real-time requirements. The process starts before the first line of code, at the stage of choosing the microcontroller, which determines what capabilities the product can have and at what cost. Firmware then evolves alongside the hardware: an early version runs on a development board, later versions run on the real prototype, and it matures through the EVT, DVT, and PVT build stages on the way to production. For budget ranges, see our breakdown of firmware development cost.
Firmware Updates: Why You Must Plan Ahead
Shipping is not the end of the story. Bugs surface, security vulnerabilities get patched, and new features get added — all of which require updating the firmware on devices already in customers' hands. Connected products handle this with over-the-air (OTA) updates, a capability you must plan for at the specification stage, because it affects component selection, memory sizing, and the structure of the firmware itself. Security deserves the same early attention: unprotected firmware is an open door for attackers, and for wireless products it intersects with regulatory testing as well.
What a Founder Should Know Before Starting
You don't need to write code, but walk into meetings with a basic understanding and a few prepared questions:
- Who actually writes the firmware, and what's their track record with similar products?
- Do the source code and full documentation belong to you at the end of the project?
- How is the firmware tested — and what happens when a bug shows up in a customer's device in the field?
- Does the product support OTA updates, and what does that require from the hardware?
Beyond that, insist that the answer to "what is the firmware responsible for in this product" appears in the specification document: which functions it covers, how it updates, and which edge cases it handles. At Projects House, firmware is developed as an integral part of the product — the same team that designs the electronics writes the code that runs on it. More guides live in our embedded software hub.
Have an idea for a smart product and want the software side explained in plain language? Contact Projects House and we'll walk you through what your product needs — no jargon required.