Cost optimization in electronics design often happens at the end of a project. By the time a schematic is finished and reviewed, most architectural decisions are already locked in, and reducing cost can be very hard if you don’t have the flexibility to rethink architectural design, compromises, or uncomfortable trade-offs.
In this article, I want to walk through a small example that shows how the CELUS Design Platform can be used early in the design process to help control BOM cost, without turning the workflow upside down.
Starting from Design Intent, Not Components
The project I used as a test case was a small wireless IoT weather station. It’s a familiar design: a few environmental sensors, a microcontroller, wireless connectivity, power management, and some supporting circuitry. Nothing exotic, which makes it ideal for demonstrating a typical workflow.
Instead of starting with specific parts, I began by describing the system at a functional level. The goal was a battery-powered, wireless device that periodically measures environmental data and transmits it. In the CELUS Design Platform, this is captured using a block diagram that represents design intent rather than implementation details.
Once the architecture was defined, I ran the first resolution. The platform identified suitable CUBOs for each functional block and generated a complete system design, including schematics and a bill of materials. From a technical perspective, the design was perfectly valid and ready to be taken further.
However, looking at the BOM revealed two issues that are very common in early-stage designs. First, the total cost was relatively high, around $75 for a device of this class. Second, a few components were already obsolete or close to end-of-life. Neither of these problems was surprising, but they clearly needed to be addressed before the design could be considered realistic for production.
Identifying Cost Drivers at the Functional Level
Instead of immediately digging into the BOM line by line, I took a step back and looked at the design at the same functional level at which it was created. One advantage of working with CUBOs is that cost and component choices are already associated with specific blocks in the system.
It quickly became clear which parts of the design were responsible for most of the cost. In this case, a large MCU, a wireless solution that was more powerful than necessary and a battery-management block optimized for performance rather than price stood out. Because these decisions were encapsulated in CUBOs, there was no need to redesign circuits or manually evaluate dozens of alternative components.
I simply chose different CUBOs for the affected blocks, which still met the system requirements but were better aligned with cost and availability constraints. For example, instead of using a CUBO built around the SI7021-A20-GM1R part, which was marked as obsolete, I switched to a different one, based on the PCT2075DP sensor from NXP, which is actively in production and much more affordable than the original one.
The rest of the design remained unchanged. After locking these options with stricter constraints in place and re-running the resolution, the platform automatically updated the schematics and BOM while ensuring that all interfaces remained compatible.
This step alone significantly reduced the overall cost and removed the obsolete components from the design, without introducing new risks or inconsistencies.
Fine-Tuning the BOM for Real-World Constraints
At this point, the design was already much closer to something that could be used in a real project. Still, most engineers don’t design in isolation. There are usually preferred suppliers, approved components, or parts already available in-house that should be considered.
The CELUS Design Platform allows for this kind of fine-tuning at the BOM level. I adjusted selected components to better match parts that were already available, replaced some passives with equivalent in-house options, and made small optimizations that don’t change the architecture but add up in terms of cost.
This stage felt very familiar: it was less about automation and more about engineering judgment. The difference was that the platform handled consistency and validation in the background, so these adjustments didn’t create downstream problems.
After this final optimization step, the total BOM cost was reduced to around $39 USD, roughly half of the initial version, while maintaining the same functionality and design intent.
From Optimized Architecture to Final Design
With the architecture and BOM aligned with both technical and commercial requirements, the remaining steps were straightforward. The schematics and bill of materials could be exported and taken into the usual CAD and review workflows to finalize the design.
What this example shows is shift in when cost optimization happens. By working at the architectural and functional level early on, it becomes possible to explore alternatives and reduce cost before the design is locked in.
For engineers who regularly face pressure to optimize BOM cost, manage component availability, and still move fast, this approach can save time and reduce rework. The CELUS Design Platform doesn’t replace engineering decisions. It simply makes them easier to evaluate, adjust, and validate while it still matters.
