Building an embedded product is exciting. Getting it to work in the lab, even more so. But the real challenge starts when you move beyond prototypes and begin scaling.
This is the phase where things quietly start to break.
Not because the product is poorly built, but because scaling exposes realities that prototypes simply don’t face. What worked perfectly for 10 units may completely fail at 1,000. Or 10,000.
In our work at ADUK GmbH, we often see the same pattern: the issues that appear during scaling are rarely random. They are predictable, and more importantly, avoidable, if you know where to look.
Let’s explore what usually breaks first, and why.
1. Hardware Assumptions Don’t Survive Scale
In early development, hardware decisions are often made for speed and convenience. Engineers choose components that are available, easy to integrate, or already familiar.
At small volumes, this works. At scale, it doesn’t.
Suddenly, components go out of stock. Lead times stretch from weeks to months. Costs fluctuate. Suppliers change specifications without notice. What seemed like a stable design becomes fragile.
Another common issue is tolerance stacking. Small variations in components, insignificant in prototypes, can accumulate and cause failures in mass production.
The root problem is simple: prototypes are built for functionality, not for manufacturability.
Scaling forces you to answer questions like:
- Can this design be produced consistently?
- Are the components reliable across batches?
- Is there a second source for critical parts?
Ignoring these questions early often leads to expensive redesigns later.
2. Firmware Becomes a Bottleneck
Firmware that works is not the same as firmware that scales.
In early stages, code is often written quickly, with a focus on making things function. Edge cases are overlooked. Logging is minimal. Error handling is basic.
Then the product scales.
Devices behave differently in the field. Unexpected inputs appear. Network conditions vary. Suddenly, small inefficiencies turn into large operational problems.
A common symptom is update failure. Over-the-air updates that worked fine in testing start failing across thousands of devices. Without robust rollback mechanisms, this becomes risky very quickly.
Another issue is observability. Without proper logging and telemetry, diagnosing problems in deployed devices becomes guesswork.
Scaling requires a shift in mindset:
- Firmware must be resilient, not just functional
- Updates must be safe, not just possible
- Debugging must be remote, not just local
This is where many teams realise that firmware is not just a technical layer, but a core part of the product experience.
3. Connectivity Gets Unpredictable
In controlled environments, connectivity seems stable. Devices connect, send data, receive commands.
In the real world, things are different.
Wi-Fi networks vary in quality. Cellular coverage fluctuates. Routers behave unpredictably. Users change settings without understanding the consequences.
What worked in the office fails in the field.
Typical issues include:
- Devices dropping offline intermittently
- High latency or packet loss
- Failed device onboarding
- Increased power consumption due to reconnection attempts
These problems are not always easy to reproduce, which makes them even harder to fix.
Scaling highlights a key truth: connectivity is not a given, it is a variable.
Designing for unreliable networks, including retry logic, fallback mechanisms, and offline modes, becomes essential.
4. Manufacturing Reveals Hidden Weaknesses
Prototypes are often hand-assembled or built in small batches with extra care.
Mass production is different.
Processes are optimised for speed and cost. Variability increases. Small design flaws become large-scale defects.
Common issues include:
- Assembly errors due to unclear design tolerances
- Components that are difficult to solder or align
- Inconsistent quality across production batches
- High failure rates during testing
Another overlooked factor is testability. If a product is not designed for efficient testing, production slows down significantly.
At scale, manufacturing is not just about building, it is about building reliably and repeatedly.
Teams that involve manufacturing considerations early tend to avoid painful surprises later.
5. Supply Chain Becomes a Strategic Risk
At small volumes, sourcing components is relatively straightforward.
At scale, it becomes a strategic challenge.
You are no longer buying parts, you are managing a supply chain.
Risks include:
- Single-source dependencies
- Sudden price increases
- Logistics delays
- Geopolitical disruptions
A single missing component can stop production entirely.
This is why scalable products are designed with flexibility in mind. Alternative components, multiple suppliers, and long-term availability planning are not optional, they are necessary.
6. Data and Backend Systems Struggle to Keep Up
As the number of devices grows, so does the amount of data.
What worked for a small number of devices may not scale efficiently.
Typical problems include:
- Backend systems that cannot handle increased load
- Inefficient data processing pipelines
- High infrastructure costs
- Delayed or lost data
Another critical issue is security. More devices mean a larger attack surface. Weaknesses that were insignificant at small scale become serious risks.
Scaling requires robust backend architecture, efficient data handling, and strong security practices from the start.
7. Support and Operations Get Overwhelmed
When a product reaches real users, support becomes a critical function.
At scale, even small issues can generate a large volume of support requests.
Without proper tools and processes, teams quickly become overwhelmed.
Common challenges:
- Lack of visibility into device status
- Slow issue resolution
- Inconsistent user experience
- High operational costs
This is where the connection between engineering and operations becomes clear. A well-designed product reduces support load. A poorly designed one increases it.
Why These Things Break First
All these issues share a common theme.
They are not caused by mistakes, but by assumptions.
Assumptions that:
- What works at small scale will work at large scale
- Stability in testing reflects stability in the real world
- Early decisions can be adjusted later without consequences
Scaling removes these assumptions and replaces them with reality.
How to Avoid These Pitfalls
The good news is that most of these problems can be anticipated.
Some practical principles:
- Design for manufacturability from day one
- Choose components with long-term availability in mind
- Build firmware with resilience and observability
- Plan for unreliable connectivity
- Think about testing as part of the design, not an afterthought
- Treat the supply chain as a core part of the product
- Invest in backend scalability early
At ADUK GmbH, we often support teams exactly at this transition point, where prototypes need to become real, scalable products. The earlier these challenges are addressed, the smoother the scaling process becomes.
Final Thoughts
Scaling is not just a technical step. It is a transformation. It forces products to move from controlled environments into unpredictable reality.
What breaks first is not random. It is simply what was not designed for scale.
Understanding this early can save months of delays, significant costs, and a lot of frustration. And more importantly, it can turn scaling from a risky phase into a competitive advantage.
