Developing flushing electronics in-house or sourcing them
A manufacturer adding scheduled flushing or electronic control to a sanitary or safety product has to decide whether to develop the electronics or source them. Cost is one criterion. The others are control, dependency, timing, lifecycle responsibility, and what evidence each route can produce, and they are worth judging separately rather than folding into a single number.
In this section
The six criteria
Both routes can be judged against the same questions. Doing so is more useful than listing the drawbacks of one and the questions to ask about the other.
| Dimension | Developing in-house | Sourcing |
|---|---|---|
| Control | The behaviour, the roadmap, and the design documentation belong to the manufacturer, though changes still compete for priority against everything else the engineering team is doing. | Specifying behaviour and agreeing changes with a supplier under change control, within that supplier's capacity and release schedule. |
| Dependency | Depends on retaining the people and the knowledge. Documentation gaps and staff turnover are the risks, particularly for firmware written years earlier. | Depends on the supplier's continued involvement, which is why it matters who writes the firmware and whether that team is reachable. |
| Cost scope | Development, testing and approvals, production test, obsolescence redesigns, firmware revisions, support, and the opportunity cost of engineers not working on the core product. | Unit price plus integration effort, customisation, tooling or setup, and whatever premium the dependency justifies. |
| Timing | A team that already has the disciplines in place may beat a procurement cycle. | Can be faster to a shippable product where an existing platform suits the requirement. Integration, customisation, and a supplier's release queue all take time. |
| Lifecycle responsibility | Obsolescence, firmware revisions for later runs, diagnostics in year six, and documentation for technicians sit with the manufacturer. | Depends on the arrangement, which is worth settling explicitly rather than assuming. |
| Evidence before you commit | The team's track record on comparable work. | Products already installed and running in a similar application, production test coverage, and traceability. |
Both routes have a queue; they differ in who administers it. Both carry a dependency; they differ in its shape. Either can have the lower total cost, depending on the assumptions used.
Volume changes the economics on both sides, since a supplier amortises its platform across its customers while a manufacturer amortises an internal team across its own units.
What the electronics work contains
The work below exists whichever route is taken. What differs is who carries it, how visible it is to the manufacturer, and how it is paid for.
Sensing, control, valve drive sized to the coils the product will use, power conditioning, protection, and a board that fits inside a fixture designed by someone else.
Activation modes, flush cycles, timers, lockouts, failsafes, parameter storage, and the behaviour in states that are not in the feature list.
Where any variant runs on a battery, a discipline rather than an optimisation pass. Standby current, pulse energy, sleep and wake behaviour, service life calculated from measured currents and validated by testing.
An actuation surface that keeps working when wet and when operated with gloves, over years of exposure to cleaning chemicals, in a housing that keeps water out at the pressures the environment applies.
Electromagnetic compatibility, electrical safety, and, for wetted components, the material approvals that apply in each target market. Technical risk as well as calendar time.
Test fixtures, functional test at end of line, calibration where needed, firmware loading, traceability, and first-run yield.
Documentation belongs alongside these: installation, configuration, service, and the parameter reference a technician will need years later. So does everything after launch, meaning obsolescence and the redesigns it forces, firmware revisions for later production, field diagnostics, warranty analysis, and support while the product is still being installed.
The disciplines involved are embedded hardware design, firmware, low-power specialisation, mechanical and sealing design, EMC and compliance, production engineering, and technical ownership of the product over its life. Some are part-time roles, and many manufacturers cover them with shared internal teams, contractors, and external test laboratories rather than new permanent hires.
Where each route tends to fit
Manufacturers whose control behaviour is a genuine differentiator, who have volume enough to amortise a team, who already develop electronics for other lines, or who have regulatory or contractual reasons to hold the complete design and its documentation.
Manufacturers for whom the electronics enable the product rather than define it, who are working to a date set by a tender or a regulatory change, who have moderate volumes spread across many variants, or who would otherwise be building a capability the rest of the business has no other use for.
Neither list is a verdict. A manufacturer can match several points on both.
The middle ground
The choice is rarely binary in practice. One available middle-ground arrangement is a platform with custom firmware: the manufacturer describes the behaviour it needs and the supplier implements it on hardware that already exists. How much of the differentiation this preserves depends on how much of it lives in the firmware rather than in the hardware, which is worth establishing before the arrangement is agreed rather than after.
Two other arrangements are available. Joint development places the manufacturer’s engineers alongside the supplier’s, which can transfer knowledge but needs both sides to agree in advance who decides what. And a manufacturer can source a first generation while building internal capability for a second, which works where it is stated at the outset and priced accordingly rather than discovered later by the supplier.
What to ask a supplier
These questions apply to any supplier in this category, including RNC. They are worth asking early, because the answers are difficult to change once a design is committed, and because they distinguish suppliers that look similar on a datasheet.
- Who writes the firmware, and can our engineers speak to them directly rather than through an account manager?
- Where is the product manufactured, and what does end-of-line test cover?
- How deeply can the behaviour be changed for our product, and what is the process for agreeing a change?
- What is the standby current, at what duty was it measured, and how was the service life figure derived?
- What traceability do we receive per unit?
- Which approvals do you hold, which do we hold, and who acts when a market adds a requirement?
- What are real lead times and minimum quantities at the volumes we actually expect?
- Who do our engineers contact when something behaves unexpectedly years after launch, and how quickly?
- What is already installed and running in an application close to ours?
For the operator on the other side
A facility or estates buyer inherits this decision without taking part in it.
The equivalent due diligence is short: who supports the product in five years, whether parameters and firmware versions can be read back from installed devices, and whether spares and replacements will match what is already fitted.
Those are reasonable questions to put to a manufacturer at specification stage, and the answers are worth recording.
Working this into a product?
Tell us the application, the environment, and the power budget. We will come back with a configuration.
Request configured samplesNeed the control electronics behind it?
Programmable switching, sensing, and firmware, developed and manufactured in-house.
Discuss your product development