Summary: Most embedded teams start with the same reference designs, SDKs and hardware platforms, which is why many products end up looking similar. The biggest competitive advantages are rarely in the processor or SDK. They are usually in the system architecture.
Why so many products look alike
Reference designs, SDKs and common hardware platforms help teams get to market faster. Because so many teams start from the same building blocks, many products end up looking surprisingly similar.
What reference designs give you, and what they don’t
A reference design is a silicon vendor’s or module maker’s proof that a chip works: a schematic, a layout, a board support package and example software. It is valuable. It removes a large amount of early risk, shortens bring-up and gives you a known-good starting point for power, memory and high-speed signals.
What it does not give you is your product. It is built to show the chip’s features in general, not to meet your cost target, your enclosure, your certification plan, your field conditions or your update strategy. Everything that makes your product different has to be designed on top of it.
| Reference design | Your system architecture | |
|---|---|---|
| Purpose | Prove the chip works | Meet your product’s requirements |
| Speed to first prototype | Fast | Builds on the reference design |
| Differentiation | The same for every customer of the chip | Where your product becomes different |
| Cost and BOM | General purpose, often more than you need | Optimised for your volume and features |
| Communication and orchestration | Generic examples | Designed for your devices and data |
| Lifecycle and updates | Out of scope | Planned from the start |
The LaMetric SKY example
On LaMetric SKY, we needed to synchronise graphics across 16 intelligent tiles, each with 64 individual zones, at video-like refresh rates, while also updating individual tiles over the same RS-485 bus.
Standard protocols weren’t designed for this. For a system with over 1,000 lighting zones and real-time graphical updates, protocol overhead becomes the bottleneck.
Instead of accepting those limits, we developed a custom high-throughput RS-485 protocol optimised for streaming graphical data, synchronisation, device addressing, reliability and software updates across distributed embedded nodes.
The lesson: asymmetric advantage
The lesson wasn’t about RS-485. It was about asymmetric advantage. Reference designs help you get to market faster, but differentiation often comes from the architecture layers above:
- Communication stacks.
- Distributed systems.
- Device orchestration.
- Software lifecycle management.
- Balancing BOM cost, hardware complexity and certification requirements.
- Sharing a single RF module between multiple processing units instead of duplicating connectivity hardware.
- User experience.
The most valuable engineering decisions are often invisible to the end user.
Questions that reveal architecture opportunities
- Where does a standard protocol or component limit what the product can do?
- Which parts of the system are duplicated and could be shared?
- What happens to cost, power and certification if a function moves between hardware and software?
- How will every part of the system be updated in the field, years after launch?
- What will users notice, and what can stay invisible but make the product better?
Common mistakes
- Shipping the reference design with minimal changes, and inheriting its cost and its limits.
- Treating communication between components as a detail instead of a design decision.
- Planning updates for the main processor only, and forgetting the other processors in the system.
- Building custom solutions where a standard one would do. Custom work pays off only where it creates a real advantage.
Where the advantage hides
Over the years of building our own products and helping OEMs develop connected devices, we’ve learned that the biggest competitive advantages are rarely found in the processor, SDK or reference design. They are usually hidden in the system architecture. Finding them takes more than strong engineering: it helps to have people with a product builder and inventor mindset on your team, or to partner with those who do.
How architecture shows up in cost
Architecture decisions often decide the bill of materials more than component choices do. Sharing one radio module between processors, moving a function from a dedicated chip into software, or choosing a bus that needs fewer connectors can each remove parts from every unit. The same is true in the other direction: an architecture that duplicates functions or needs extra processors carries that cost for the whole life of the product.
Certification follows architecture too. The number of radios, where they sit and how they are shared affect the certification work for each market. Thinking about this at the architecture stage avoids repeating tests later.
Planning for the product’s whole life
A reference design is usually built for the first version of a product. A product architecture has to support the versions that follow: new features, new hardware revisions and years of software updates. Plan which parts of the system can be updated in the field, how distributed components are kept on compatible software versions, and how the system recovers when an update fails on one part of it. These decisions are hard to add later and easy to plan early.
FAQ
Should we avoid reference designs?
No. Start from them. They save time and reduce risk. The point is to treat them as a starting point, not as the architecture.
When is a custom protocol worth it?
When a standard one cannot meet a requirement that matters to the product, such as throughput, latency or synchronisation, and the advantage justifies the effort to build and maintain it.
When should an architecture review happen?
Before the platform and the main interfaces are frozen. Changes are cheapest on paper.
How do we know where our advantage is?
Look at what customers value and what competitors find hard to copy. That is usually a combination of user experience, reliability, cost and how well the product keeps improving after launch. Architecture decisions that support those are the ones worth investing in.
Does a custom architecture slow down the first release?
It can, if everything is custom. Keep standard components where they work, and focus custom effort on the few places where it changes the product. That keeps the first release on schedule and builds the advantage where it matters.
Who should own the system architecture?
One person or a small group should be responsible for the whole system across hardware, firmware, cloud and manufacturing. When each team optimises its own part in isolation, the system drifts, and the advantages that come from looking at the whole product are lost. Many companies do not have a full-time system architect, which is why a part-time architect can be a practical option.
How we help
We bring that product builder mindset to client architectures, from communication stacks to BOM and certification trade-offs. See our embedded product architecture review and fractional system architect services. If you want a second look at your system architecture, talk to an engineer.
