How to organise a modern firmware project

What the modern organization of a firmware project teaches us

The DesignNews article on organizing a modern firmware project highlights a reality that many development teams have a hard time learning: firmware is not just code that «runs on hardware». It is the functional nervous system of a product, the point where embedded software, hardware constraints, end-user experience, security, production, and long-term support meet. For an e-commerce owner selling connected devices, smart products, POS peripherals, warehouse systems, lockers, logistics sensors or any product connected to an app or cloud service, firmware quality directly impacts returns, reviews, support costs, brand credibility and repeat sales. See also: Digital Marketing & SEO, e-shop construction.

The basic idea is simple but often neglected: a modern firmware project needs a structure that allows people, tools and processes to work together without friction. While the product is in the prototype stage, a rough folder layout may seem sufficient. But when you add a second board, a new microcontroller, OTA updates, secure boot, production testing, different SKUs, regulatory requirements and customer support logs, the lack of organization becomes expensive. Firmware development should be treated as a full lifecycle software product, not as a technical detail to be «taken care of later».

This need is even more acute because the market for connected devices is growing. According to IoT Analytics, global connected IoT devices were estimated at 16.6 billion in 2023, projected at 18.8 billion in 2024 and expected to reach approximately 40 billion by 2030. For e-commerce businesses, this means more products with embedded software, more usage data, but also more exposure to bugs, vulnerabilities and field failures. As shown in the graph below, the growth curve of IoT devices justifies why firmware organization should be a strategic decision and not an internal affair of the technical team.

Why it concerns e-commerce owners and not just embedded engineers

What changes in practice on the issue: How to organize a modern firmware project

An e-commerce owner usually thinks in terms of acquisition cost, conversion rate, fulfillment, reviews, margin and lifetime value. But when the product includes IoT firmware or any kind of embedded systems, the technical debt is quickly transferred to commercial costs. An inconsistent firmware architecture can create failures after an update, products that don't activate properly, increased tickets, poor unboxing experience, mobile app or cloud connectivity issues, and difficulty diagnosing when the customer requests a replacement. The result is not just a technical bug. It's reduced trust, negative reviews, lower repeat purchase and higher support costs.

The modern organization of a firmware project acts as business continuity insurance. It allows the team to know which version is installed on which product, replicate a build months later, fix problems without breaking existing functionality, apply unit testing firmware where possible, and isolate the hardware abstraction layer from the business logic. Simply put, it reduces the risk of the product depending on a single developer or a folder with vague names like final_final_v3.

The business risk is amplified by the cost of a data breach. According to IBM, the global average cost of a data breach increased from $3.86 million in 2020 to $4.88 million in 2024. While this amount is not exclusive to firmware, it is critical for connected products that collect data, communicate with cloud APIs or support remote updates. A properly organized firmware project facilitates secure boot, firmware version control, vulnerability patching, audit trails and faster response when a security issue is detected.

The structure of a modern firmware project

Good structure starts with the separation of responsibilities. The application layer should not be confused with device drivers, the board support package should not contain business logic, and the build system should not depend on manual settings on a developer's computer. In a mature firmware project, the code is organized so that the team can change microcontrollers, add RTOS, replace a sensor, create variants for a different market, or enable OTA updates without rewriting the product core.

A practical principle is to think of firmware architecture in layers. At the lowest layer are the device drivers and the hardware abstraction layer, i.e. the code that talks directly to GPIO, SPI, I2C, UART, flash memory, sensors, radio modules and power management. Above this may be middleware, such as communication stacks, file systems, crypto libraries or RTOS services. Even higher up is the application layer, where the behaviour of the product is expressed: when an LED is lit, when an event is sent, how the device handles an error, how a firmware update is performed and how user data is protected.

For companies that outsource development, this structure is also a control tool. You can ask for deliverables that are not just «the code», but an organized repository with documentation, automated build, test plan, release notes, binary artifacts, configuration files and a clear branching model. This reduces the risk of vendor lock-in and you can change teams, audit or continue development without starting from scratch.

Proposed folder hierarchy for scalable deployment

A clear folder hierarchy helps ensure that each file has an obvious location and purpose. For example, an apps folder might contain different applications or product variants, the boards folder might describe boards and pin mappings, the drivers folder might host low-level device drivers, the hal folder might contain the hardware abstraction layer, the middleware folder might contain RTOS, communication stacks and libraries, the services folder organizing functions such as logging, configuration, telemetry and OTA updates, the tests folder containing unit and integration tests, the tools folder containing scripts for flashing, provisioning and manufacturing, and the docs folder containing architecture, release process, coding standards and production guidelines.

This logic is more important than the names of the envelopes themselves. The point is not to turn the repository into a file repository, but into a collaborative operating system. Every new developer needs to be able to quickly understand where a new function is entered, where a test is written, how a board configuration is changed, and how a production build is created. In embedded systems, where debugging time is often consumed by hardware and software interactions, a clean structure reduces uncertainty and makes problems more reproducible.

Step-by-Step guide to setting up a firmware project

Step 1: Define the product scope before defining folders. List which products, boards, markets and versions need to be supported. A smart home product with one board has different needs than an industrial sensor with three SKUs, different modems, and country-specific certifications. The organization needs to anticipate the actual commercial path of the product.

Step 2: Draw the layers of the architecture. Separate application logic, hardware abstraction layer, device drivers, middleware and platform-specific code. If you are using embedded C or C++, avoid passing hardware dependencies everywhere in the application. This makes testing more difficult and increases the cost of changing hardware. If RTOS is present, decide which modules are allowed to know tasks, queues, timers and synchronization primitives.

Step 3: Select a build system that supports reproducibility. Whether you use CMake, Make, Bazel, vendor IDE or other build system, the goal is for the same commit to produce the same binary in a predictable way. Capture toolchain versions, compiler flags, linker scripts, memory maps and dependencies. For e-commerce products that are already in customers, the ability to replicate an old version is critical when you need to fix a bug that only occurs in a specific batch.

Step 4: Integrate CI/CD firmware as much as the environment allows. Not every test needs to run on real hardware, but every pull request can do compile, static analysis, linting, and unit tests for modules that are hardware-uncoupled. In more mature teams, hardware-in-the-loop rigs can run basic regression tests on real boards. This reduces the likelihood of sending an OTA update that solves one problem and creates two new ones.

Step 5: Establish a publishing policy. Each release should have semantic or at least consistent versioning, changelog, known changes, binary hash, supported hardware revisions, and rollback instructions. For products with OTA updates, the policy should include phased rollout, health checks, fallback partition or recovery mode. Firmware is a live product, not a file delivered once at the factory.

Step 6: Build in security from the beginning. Secure boot, signed firmware images, private key protection, dependency scanning, secure credential storage and a clear process for security patches are not luxuries. Especially when the product is connected to a customer account, app or cloud, the security model must be documented and tested. Security added at the end usually costs more and covers less.

Step 7: Make the documentation part of the repository. Docs shouldn't just live in presentations or chat messages. A good firmware project includes architecture decision records, onboarding guide, coding guidelines, release checklist, manufacturing guide, flashing instructions and troubleshooting guide for support teams. This gives customer support, production, QA and management a common view of the product.

Measurements, quality and governance

Organisation does not end with the creation of files. Governance is needed: who approves changes, what tests are required before release, how third-party libraries are evaluated, who monitors vulnerabilities and how incident response is handled. Firmware development often relies on open-source components, vendor SDKs and external libraries. This speeds up development, but also introduces risks that need to be controlled with Software Bill of Materials, license review and vulnerability monitoring.

The Synopsys OSSRA 2024 data shows why this matters: 96% of the audited codebases contained open source, 84% contained at least one known vulnerability, 74% had high-risk vulnerabilities, and 53% had license conflicts. For firmware groups, these percentages translate into a practical need for inventory dependencies, update policy and clear ownership of each component. The graph below shows the scale of open-source risks that need to be considered in any modern embedded software project.

To make good use of this insight, set specific quality KPIs. Track build success rate, number of failed regression tests per release, time from bug report to fix, percentage of devices successfully upgraded, number of crash or fault events per thousand devices, firmware unit testing coverage on critical modules, and age of open vulnerabilities. These metrics connect the technical world to business outcomes. If, for example, a new release reduces activation support tickets by 30%, this is immediate commercial value. If a bad OTA update increases returns, the lack of process becomes a measurable loss.

E-commerce owners don't need to become embedded engineers, but they do need to know what to ask for. Ask your team or vendor to present repository structure, release process, test strategy, security model, OTA rollback plan and production documentation. Ask if the firmware can be built in a clean environment, if each binary is associated with a specific commit, if there is SBOM, if private keys are protected, and if device diagnostics can be done in the field without going directly back to service. These questions are not micromanagement. They are due diligence for products sold to real customers.

The most important conclusion is that a modern firmware project should be organized based on the long-term operation of the product. The right structure allows for faster development, fewer errors, safer updates and better collaboration between development, QA, production, support and business. For an e-commerce business, this means fewer returns, better reviews, a more reliable brand and the ability to expand the connected product range without multiplying technical risk. Firmware may be invisible to the customer, but its quality can be seen in every purchase, every activation, every update and every user experience.

Sources

Frequently Asked Questions