Decision Framework
Build vs Buy IoT:
An Honest Framework
Building a connected elevator product in house is a real option, and for some companies it is the right one. This page sets out what the team costs, what the calendar looks like, which parts you should never outsource, and a checklist you can run with your board in an afternoon.
The Real Question
It Is Not About
Whether You Can
Almost every elevator company that considers building could build. You understand the controllers better than any software vendor does, and the engineering is not exotic. The question is whether you want to run a permanent engineering function next to a service business, and whether the calendar that requires is one you can afford.
Build versus buy decisions go wrong in a predictable way. Someone estimates the cost of a small team for a year, compares it against a vendor quote, and concludes that building is cheaper. The estimate omits redundancy, certification, test rigs, OTA infrastructure, field support, and the months of revenue impact while the product does not exist. Two years later the prototype works, the elevators are not connected, and the two engineers who understood it are being counter-offered by someone else.
The framework below is the one we use with prospects, including the ones who decide to build. If you run it honestly and the answer is build, that is a good outcome. You will at least have scoped it properly.
The Build Path
The Team a Connected
Product Actually Needs
Price these roles at fully loaded cost in your own market, including employer contributions, recruitment fees, equipment and workspace. We deliberately publish no salary figures here because they vary too much by country to be honest. Use your own numbers.
Illustrative, structural count of disciplines.
Electronics hardware engineer
Schematic capture, PCB layout, component selection, power and isolation design, interference and vibration tolerance for a lift panel, design for manufacture.
Needs bench equipment and prototype iterations. One engineer is a single point of failure on a board nobody else understands.
Embedded firmware engineer
Signal acquisition, protocol decoding per controller family, fault register mapping, edge buffering, OTA update client, watchdog and recovery behaviour.
This is the scarcest role in the list, and the hardest to interview for if nobody on your team writes firmware.
Backend and data engineer
Ingestion pipeline, device registry and authentication, time-series storage, alert engine, API layer, tenancy and access control.
Elevator telemetry is bursty and long-lived. The schema decisions made in month two are expensive to change in year two.
Frontend engineer
Elevator dashboard, ticket queue, technician mobile views, maintenance calendar, reporting screens.
Field usability decides adoption. A technician who cannot close a job on a phone in a basement will keep using paper.
DevOps and infrastructure
Environments, deployment, monitoring, backups, certificate and key management, OTA release rollout and rollback.
OTA rollback is the capability nobody builds until a bad firmware release reaches your elevators.
QA and field validation
Test rigs against real controllers, regression on each firmware revision, install validation procedures, defect triage from the field.
Without a controller test rig you are testing in production, inside customer buildings.
Product owner or technical lead
Specification, prioritisation, coordination between disciplines, stakeholder management with service and sales.
Often the founder or the operations director, which means the cost lands on the business twice.
Total Cost of Ownership
Six Costs That Never
Make the Spreadsheet
Salaries are the visible line. These six are the ones that turn a confident eighteen-month plan into a three-year project, and they apply whether you build with employees or with contractors.
The prototype is the cheap part
A capable engineer can get a board reading one controller and posting data to a dashboard in a few weeks. That milestone feels like most of the work and is closer to a tenth of it. The remaining effort is coverage across your other controller families, behaviour when the network drops, behaviour when power cycles mid-write, install repeatability by non-engineers, and diagnosis of the unit that works on the bench and fails on site.
Compliance and certification
A device sold or installed at scale carries obligations depending on your markets: electrical safety, electromagnetic compatibility, radio approval if it uses cellular, and documentation. Testing is scheduled, iterative, and unforgiving of late design changes. Budget the lab time and the redesign cycle it may trigger.
Controller access for development
Firmware for a controller family needs that controller on a bench, or scheduled access to a live one. Procuring panels, building rigs, and getting permission to instrument a customer unit are logistics costs that do not appear on any salary sheet.
Keeping the team staffed
You are not hiring a project team, you are creating a permanent function. Firmware and hardware engineers are scarce and mobile. When the one person who understands the fault register mapping leaves, your elevators keep running and the roadmap stops. Redundancy in each discipline roughly doubles the headcount you first estimated.
Management attention
Running engineering is a different business from running elevator service. It needs different hiring, different review cycles, different tooling and different failure modes. The scarcest resource in most elevator companies is senior attention, and an in-house build consumes a lot of it for years.
The cost of not having it yet
Every month before the product exists is a month of reactive callouts, lost tenders where a connected offer was required, and manual reconciliation between operations and accounts. That figure belongs in the build column. Most build cases leave it out, which is what makes them look cheap.
Bring your build plan and we will stress-test it against the roles, the calendar and the controller coverage you actually need.
Review It With an Engineer →Non-Negotiables
What You Should Keep
In House Regardless
Outsourcing engineering capacity is reasonable. Outsourcing judgement, ownership or customer contact is not. Whichever path you take, these six stay with you.
Domain knowledge
Which controllers behave badly in which buildings, which faults precede a callout, how your technicians actually triage. No partner can supply this and no partner should own it.
Product decisions
What the system must do, what the priorities are, what good looks like. A partner should be arguing about implementation, not deciding scope on your behalf.
The customer relationship
Your customers should experience your product and your service. The engineering partner belongs behind the brand, not in front of it.
The data and the source
Schematics, firmware source, platform code, and the database. Settle ownership in the contract before scoping, not at renewal time.
Enough technical literacy to govern
One person who can read a spec, challenge an estimate and review a design decision. That role pays for itself on the first scoping conversation.
Deployment and field process
Your technicians install and service the units. Owning the install procedure, the commissioning checklist and the first-line diagnosis keeps the feedback loop short.
Risk Profile
Different Paths,
Different Failure Modes
Neither path is safe. They fail differently, and you should choose the failure mode you are better equipped to manage.
| Factor | Buy from RnD Square | Build in-house |
|---|---|---|
| Upfront cost | Scoped project fee | Team salaries from day one |
| Time to first live data | Weeks after controller mapping | Many months |
| Delivery risk | Bounded by scope | Open-ended, absorbed internally |
| Key-person risk | Partner covers the discipline | Roadmap stalls if one leaves |
| Five-year total cost | Project, then support | Permanent payroll |
| Ownership of source and data | Yours by contract | Yours |
| Risk | Build in house | Partner |
|---|---|---|
| Key person leaves | Roadmap stalls, tacit knowledge lost | Partner covers the discipline, you hold the documentation |
| Schedule slips | Absorbed internally, often invisible until late | Contractual milestones make slippage visible early |
| Cost overrun | Open-ended, salaries continue regardless | Bounded by scope, change requests are explicit |
| Wrong technical choice | Discovered in the field, expensive to reverse | Should be caught in review, but only if you govern it |
| Vendor or partner failure | Not applicable | Real risk, mitigated by owning source, schematics and data |
| Scope creep | Very common, no external discipline | Priced and visible, which is uncomfortable and useful |
| Losing domain control | Low | Real if you delegate product decisions, avoidable if you do not |
Key person leaves
Build: Roadmap stalls, tacit knowledge lost
Partner: Partner covers the discipline, you hold the documentation
Schedule slips
Build: Absorbed internally, often invisible until late
Partner: Contractual milestones make slippage visible early
Cost overrun
Build: Open-ended, salaries continue regardless
Partner: Bounded by scope, change requests are explicit
Wrong technical choice
Build: Discovered in the field, expensive to reverse
Partner: Should be caught in review, but only if you govern it
Vendor or partner failure
Build: Not applicable
Partner: Real risk, mitigated by owning source, schematics and data
Scope creep
Build: Very common, no external discipline
Partner: Priced and visible, which is uncomfortable and useful
Losing domain control
Build: Low
Partner: Real if you delegate product decisions, avoidable if you do not
Decision Checklist
Ten Questions,
One Afternoon
Answer these in a room with your operations lead, your finance lead and whoever would sponsor the build. If more than three answers are uncomfortable, partnering is probably the lower-risk path.
- You cannot fund a multi-discipline team for three years without revenue
- Nobody in-house can hire and judge hardware and firmware engineers
- A tender or contract deadline rules out a long build
- Losing two senior engineers would stall the whole roadmap
- The connected product is undifferentiated engineering for you
- You have not written the specification down yet
Is the connected product something we intend to sell, or something we need internally? Selling it strengthens the case for owning the engineering.
Can we fund a multi-disciplinary team for at least three years without the product generating revenue in year one?
Do we have someone who can hire and manage hardware and firmware engineers, and judge their work?
How many distinct controller families must be covered before the system is useful to us? More families means more firmware and a longer build.
What is the deadline that matters? A tender requirement or contract commitment usually rules the build path out on timing alone.
If the two most senior engineers left in the same quarter, what happens to your elevators and the roadmap?
Have we written the specification down? If we cannot specify it for a partner, we cannot brief an internal team either.
Which parts of this are genuinely differentiating for us, and which are undifferentiated engineering anyone competent could deliver?
What does the five-year total cost look like on both paths, using the same benefit assumptions?
What is the exit position on each path? Ownership of source and data should be equivalent either way.
Where We Fit
Your Extended
R&D Team
RnD Square sits between the two paths. We are the engineering function you would otherwise hire, working against your written specification, with the result owned and branded by you. Interface hardware, controller-specific firmware, the cloud pipeline, the operations suite, and the CRM, ERP and accounting layers are delivered by one team, so there is no integration boundary between the device and the invoice.
That model is deliberately different from a subscription product. A fixed product asks you to adopt its process. We build yours. It is also different from a body shop: we take responsibility for the outcome, argue about scope, and tell you when a phase should be cut. Companies that want a supplier to nod at requirements will find us harder work than they expected.
If, after running the checklist, building in house is clearly right for you, say so on the call. We would rather scope a phase one that reduces your risk while you hire than sell you an engagement you will resent in year two.
Frequently Asked Questions
What Boards Ask
Before Deciding
Usually, but not automatically. A partner engagement still needs discovery, controller mapping, hardware iteration and validation, and that takes weeks to months depending on how many controller families are in scope. The difference is that the partner already has the disciplines staffed and the tooling in place, so the calendar is spent on your problem rather than on recruitment and ramp-up. Ask any partner for a delivery order and a first-live-data date before you compare timelines.
Keep Reading
Related Pages
Run the Numbers
With Us.
Bring your controller inventory, the number of elevators and your target date. We will map what a phase one delivery looks like, what it would take to staff the same work internally, and where the honest break-even sits between the two.