A Guide to Embedded Software and Electronics Development Cost

Time to Read 11 min

One of the first questions companies ask when they want to equip products with a customized control system or upgrade their software is: What does the control system development cost? What does the software development cost?

Although this is a very difficult question to answer, I will try my best here to explain some general guidelines on pricing:

Is Development Cost the Most Important Decision Criteria?
How much does an Embedded Control Development Cost? What is the Composition of These Cost?
How can I Save during Product Development? Without paying dearly for it later?
And What About the Hourly Rate?
What does it Mean when Estimates Differ Substantially?
How does one Arrive at a Cost Estimate?

Email me for a Cost Estimate

Is Development Cost the Most Important Decision Criteria?

Product development, like buying a car or better like building a house, is very individual. There are so many options that the price ranges can vary significantly.

A simpler prefabricated house starts at less than 200,000 CHF, quickly you can spend 700,000 CHF for a house if you want more space, better flooring, home automation, wiring, infotainment, thermal insulation, better kitchen appliances, a fireplace, etc.

Why are so many people willing to pay more than the bare minimum for a house or apartment? Because they understand that they will live in the house for a long time and would regret not choosing the right one for years. They want to make sure their home will give them the security, comfort, low maintenance and longevity they want.

The same is true for most embedded developments.

Happy customers setting up a coffee machine

You will produce, sell and service your product, your basis of your commercial success, for many years, every day . So it is critical to use the right options, the right development partner and the right development methodology. This is why most companies elect to go for the project with the partner that will make them happiest over the whole life and service span of the product.

Unfortunately, some companies only focus on the first development cost. They aim to find the cheapest supplier and sacrifice freedom from defects, quality, usability, extensibility, maintainability and delight for their end customer, which inevitably leads to regret. Especially since a developed product cannot simply be traded in like a car if one is dissatisfied and disappointed with it.

And what are Such Options?

Some of the most common options in a development project are:

Operation:
- LED
- Buttons
- Numeric displays
- Graphical user interface (GUI) incl.:
  - Built-in user manual
  - Multi-language support
  - User specific design (layout, colors, graphics...)
  - Touch operation
  - Access control (user, administrator, service technician...)
Actuators:
- Motors
- Valves
Sensors:
- Temperature, pressure, humidity
- Distance, position, acceleration
Interfaces:
- Bluetooth
- WLAN
- NFC
- Mobile/ Cellular
- Ethernet/ LAN
- USB
Functional safety (machine directive...)
IoT (Internet of Things) functions:
- Software updates via network
- Remote maintenance
- Identification
- Preventive maintenance
- Information security
- Access via app on smartphone
Positioning (GPS)
Status logs
Power saving/ battery operation
CE, UL, radio certification

As you can see, there are many options available. That is why we clarify and evaluate these options with our customers in a workshop during the offer phase. In this phase and throughout the entire project, it is important to us that the effects of option decisions, especially on the cost side, are transparent and clear to you.

How much does an Embedded Control Development Cost? What is the Composition of These Cost?

For a complete control development companies spend on average three hundred thousand to two million Swiss francs. This amount is composed of:

~ 10% System design (at the beginning of the project: 2..5%, the rest during the first half of the project)
- Definition of functions
- Definition non-functional requirements: certifications, operability, standards....
- Choice of architecture/ structure of the system and selection of components
~ 10% Hardware development and hardware tests
~ 60% Software development and software tests
~ 10% Verification of prototypes/ system integration and system tests
~ 5% Validation of prototypes/ field tests
~ 5% Production launch incl. production tester

Note that the effort for functional safety increases by factors.

How can I Save during Product Development?

Without Paying Dearly for it Later?

There are two ways for you to save development cost without compromising quality and incurring follow-up costs. On the one hand you can simplify the development, i.e. ask for fewer features and functions, on the other hand you can reduce the number of changes and corrections or at least the decision time for what exactly should be changed and how.

How to Simplify Product Development?

Approaches that require simplification of development are in vogue at the moment, e.g. MVP (Minimum Viable Product). Exploring the market with an MVP and then reacting as quickly as possible ("agile") to customer requests is only at first glance contradictory to clear requirements at the beginning of the project. Because each individual product iteration as a separate development project benefits in terms of speed and effort from clear requirements and few changes.

What Leads to Fewer Changes in the Project?

If a clear requirements specification is created at the beginning during an efficient System Design phase, then the changes can be minimized in the course of the project and so the effort. The implementation and change management for the adaptations that are nevertheless necessary can then be carried out iteratively. If, on the other hand, a purely agile approach is chosen, then not too many decisions are needed at the start of the project, but the effort for the adjustments of the technical solution is larger.

How Rigid is the Requirements Specification?

The requirements specification forms the basis for the development and the "single point of truth" for the goals to be achieved. However, it is not a corset that may not be touched.

Over the duration of the evelopment of a product, change requests always appear: from the market, from the development itself and from other stakeholders. As long as these do not go beyond the scope of the project, they should definitely be incorporated into the requirements specification, i.e. the requirements are adapted.

What is the Role of Product Management?

Both simplification of requirements and minimization of changes are related to a decisive product management, which takes full responsibility for the development budget. I.e. a product management is needed that has a clear idea of the requirements of both the users and the decision makers and which is also ready to delete features with a poor benefit-effort ratio.

Summarized...

Clear requirements and constraints, few changes, short decision time for changes: this is a short list, which also seems easy to implement... In practice, however, the decisions and tasks are quite extensive. For efficient product development, therefore, the product management role requires not too scarce technical and leadership competence, sufficient decision-making margin and enough allocated time for the project.

And What About the Hourly Rate?

In principle, only the total cost over the life of the product should be a factor in product development decisions. It is just that our experience shows that the hourly rate is always an issue.

Our view on pricing is this: We charge the same rates for project managers and engineers, for all experience levels, and for all functions, so we can put the work into your project and not into complicated billing schemes. We do this because:

our novices and beginners only charge 60 and 80% of their hours on client projects, respectively, which is equivalent to a reduction of their hourly rate
most architects and project managers also do developer work, which we do not want to overcharge you for

The size of the order determines the rate, as large projects result in denser planning and therefore a higher overall capacity utilization.

Our Costs are Determined by the Following Factors

Labor costs of the engineers, who are all permanently employed in Switzerland
- already a simple full cost calculation here yields interesting results
- note that we only employ engineers
Education, i.e. all our engineers are university graduates
Staff training, because your project deserves up-to-date technologies and working methods
- we invest 5% and more of the working time in continuing education
Professional experience of our engineers, so you get real experts
- 18 years on average for all engineers
Company loyalty of our engineers, so that you still have your contact persons in the project after ten years
- on average 11 years
Processes, i.e. our quality management system, so that you get the optimum quality throughout the entire development process
- in the last decade we have invested almost two million francs in it
And last but not least through the utilization, which is not always 100%
- what is your overall degree of capacity utilization?

In the product development sector in Switzerland you can see, especially in the hardware sector also 25% lower rates than Solcept, in software, functional safety and especially project management and for architects also 25 to 40% higher rates.

And, while hourly rates are easy to compare, a low hourly rate in development is not always a good indicator of total cost of ownership (TCO) over the life of the product.

What does it Mean when Estimates Differ Substantially?

It often happens that different estimates turn out to be diverging significantly. This can happen for various reasons.

The task was Not Understood (the Same)

This is the most common reason, the project and its requirements have not been fully understood, or certain factors have been forgotten, for example:

Certification effort (CE, UL, EMC, Machinery Directive, functional safety...) incl. related documentation and third party costs
Product quality (robustness/stability), i.e. error handling is omitted or is minimal and only the standard case is implemented: so user input errors, errors in connected systems, assembly errors, aging, component tolerances, etc. lead to "unexpected behavior" and thus to additional costs as modification and service costs or even worse as warranty claims
Integration into the device to be controlled, i.e. the cost of debugging the entire system together (no specification is so clear and unambiguous that integration runs smoothly)
Quality assurance of the hardware and especially the software through meaningful, risk-based testing (automated if possible) and review of critical designs
Documentation and design to a reasonable extent that allows maintenance and extension of the product without great cost throughout its life

Bad Choice of Estimation Method

Sometimes it can also be because no structured estimation method was used. Always ask to see the estimation method and its detailed results so that you can judge the quality of the estimate!

The Charging Models are Different

On the one hand, a cost estimate can start from the minimum project scope and unclear requirements and then be done on a time and effort/ iterative/ agile basis. This can lead to surprises and renegotiation if it turns out that there were misunderstandings about the goals between developer and the other stakeholders.

On the other hand, all stakeholders can be clear about the requirements that the project can be done at a fixed price. As long as there are no new requirements, this will not lead to any surprises.

An example from real life shows that agile near-shoring can be more expensive than fixed price in Switzerland.

There are Other Underlying Business Models

On the one hand there is lock-in (cost trap/dependence), where a "political" price is offered below the real cost of development. The profit is more or less hidden afterwards by increased margins for the production of the electronics or for technical changes to software and hardware. The customer remains dependent on the supplier, since he gets only the finished product or the compiled binary code for his price.

If a control system has manufacturing cost incl. manufacturing margin of 100 CHF and a hidden margin of 20% is added, then the hidden margin can already amount to 200,000 CHF for a moderate annual number of 1000 units, over the lifetime of the product of ten years. This hidden margin can be half of the development costs of 400'000 CHF, with only 2000 units per year it would already reach the entire development cost.

The other model is the open business model, in which the customer gets all the intellectual property and in which the costs for development are shown transparently. This reduces lifetime costs, as no hidden margins can be forked out. This is because the customer can use the source codes, schematics and layout documents plus associated documentation to produce, operate and further develop the product themselves or with any partner.

How does one Arrive at a Cost Estimate?

Rarely a project is already so clear from the documentation that the estimation can just start. Therefore, a workshop with all stakeholders (product management, industrial design, mechanical development, marketing, service) is held first to discuss all the factors that determine the price.

This workshop is summarized in a document, the common understanding of the project, in which the project is described in the words of the software and hardware developers. This goes through a review with the stakeholders and is then adjusted if there were any misunderstandings.

Only then an estimate is created and documented. The customer receives this detailed documentation of the estimate (typically several dozen points), which is optimized in another workshop with all stakeholders. Then a commercial offer for the desired project scope is created.