You have an idea for a product that senses something, sends it somewhere, and shows it to someone. That’s three disciplines: electronics, cloud software, and an interface. Most people in this position do the reasonable thing and go and get three quotes.
That’s usually where it starts to go wrong. Not because any of the three suppliers is bad, but because the hardest problems in a connected product don’t live inside any one of the three. They live in the seams between them, and a seam that sits between two contracts belongs to nobody.
This guide covers how to think about the system as one thing, what you need to settle before anybody quotes, which decisions get deferred and cost the most when they are, and how to work out whether your product should be contracted as one scope or several.
Treat It as One System, Not Three Projects
A device, the service it reports to, and the material that explains it form one system divided by convention into three. The convention exists because that’s how firms are organized, not because that’s how the product behaves.
Here’s what the division costs you in practice. The device team makes a reasonable decision about payload format to save power. The cloud team makes a reasonable decision about ingestion to keep the API clean. Neither decision is wrong, and together they mean timestamps get assigned at the server, which means samples that arrive late get filed against the wrong hour, which means the dashboard shows a trend that didn’t happen. Nobody caused that. It emerged from the boundary.
We’ve seen the same shape enough times to have a view about it. The seams are where the risk concentrates, and they are the part of the system that is nobody’s deliverable unless somebody makes them so.
Settle These Before Anyone Quotes
Before you talk to a single supplier, get clear on your own goals. A partner can help you refine these, but they can’t invent them, and a quote built on guesses is a quote you’ll be renegotiating in month three.
- What decision does this data support? Not “we want visibility”. What will somebody do differently on a Tuesday morning because of a reading? On a water quality program we worked on, the answer was whether crews leave the dock. That single sentence set the sampling interval, the alert thresholds, and the accuracy requirement for the entire product.
- How accurate does it actually need to be? This is the highest-leverage question in the whole exercise. Laboratory accuracy and trend fidelity are different products at different prices. Specifying research-grade instruments when the operational decision only needs direction and timing can double the cost of every unit for precision nobody uses.
- How often does it need to report? Reporting interval drives the power budget, which drives the battery, which drives the enclosure, which drives the tooling. It is not a preference you adjust later without adjusting everything downstream of it.
- Where does the device physically live? Indoors on mains power is a different product from a mooring in salt water or a pole in a car park. Temperature range, ingress, vibration, and access for service are all cost drivers and all cheap to state now.
- What’s the connectivity, and who pays for it? Cellular means a SIM and a recurring per-device cost that turns a capital purchase into a subscription. Wi-Fi means somebody’s IT department. LoRa or another low-power network means infrastructure you own. Each has a different unit economics profile and each changes the firmware.
- Who reads the output, and on what? An operations manager checking a dashboard at the start of a shift is a different interface from a technician in the field on a phone, and a different one again from a data feed nobody looks at that raises an alert. This is a product decision, not a design detail.
- How many are you making? Volume decides whether the enclosure is printed, machined, or molded, and whether a functional test fixture is worth building. It changes the design, not just the price.
Write the answers down, even roughly. A concise brief is the single most valuable thing you can bring to a supplier conversation, and the reason is simple: it lets a partner quote your product rather than a generic one with contingency stacked on top.
The Interface Decisions That Get Deferred
These are the ones that sit between disciplines, get postponed because they belong to nobody, and cost the most when they surface late.
- Protocol and payload. What the device sends, in what format, and how much air time or bandwidth that costs. A human-readable format is easier to debug and measurably more expensive on a constrained radio link. This decision binds the firmware and the ingestion service together permanently, so it needs to be made by someone looking at both.
- Provisioning. How a device gets its identity and its credentials, and what a non-technical person does when they take one out of a box on site. Provisioning is invisible in a demo, because the demo device was configured by the engineer who built it. It becomes the entire first-impression experience in the field, and retrofitting it is firmware, cloud, and interface work all at once.
- What the device does offline. Networks fail. Gateways go down. A device that only transmits is a device that loses data during exactly the events you built it to observe. Store and forward, with readings written locally and cleared once confirmed, is a decision with implications for flash, power, timestamps, and the ingestion API. Make it at scoping.
- Time. Whether a reading carries its own timestamp or adopts the server’s sounds like an implementation detail and isn’t. It determines whether your historical record is trustworthy after any period of poor connectivity, and fixing it later means a real-time clock, a drift strategy, and a data migration.
- Field update. How firmware gets to deployed devices, whether it can roll back, and who is allowed to push it. A device you can’t update safely is a device whose first field bug becomes a truck roll.
- Calibration and drift. Every sensor drifts. Deciding early that raw values are retained alongside corrected ones means a recalibration can be applied retrospectively across the whole record. A system that discards the raw reading can’t correct its own history.
None of these are exotic. What makes them expensive is that each one touches the device, the service, and the interface at once, so a program that scoped those separately has to reopen three contracts to resolve one question.
One Scope or Several?
There’s no universal answer, but there is a reliable test: put the scope boundary where the risk isn’t.
Contracting separately can work well when the disciplines are genuinely independent. If the device is a well-understood variation on something that exists, the protocol is settled, and the interface is a conventional dashboard over a documented API, three suppliers with a clear contract between them is a perfectly reasonable structure.
Contract it as one scope when the difficulty lives in the seams, which for connected products it usually does. If you can’t yet say what the payload looks like, how devices get provisioned, or what happens during an outage, then those questions are your project’s real risk and they need a single owner. Splitting the scope at that point doesn’t remove the risk, it just guarantees that resolving it requires a three-way meeting and two change orders.
Two practical signals that you want a single team:
- The accuracy claim is contested. If the error budget is a live question, it has to be negotiated across the sensor, the firmware, and the reporting layer at once. That’s one conversation, not three.
- The product is the data, not the device. When the thing you’re selling is an insight rather than a box, the interface is the product and the hardware is a means. Scoping the hardware first and treating the software as a follow-on inverts the priority.
We hold hardware, software, AI, and marketing in-house under one accountable team, one schedule, and one invoice, which is a commercial position but also a technical one: it removes the coordination cost that otherwise sits between three suppliers, and it means the positioning can be written by people who can read the schematic. Where a requirement falls outside what we hold in-house, we say so rather than subcontract it.
Where the Marketing Fits, Earlier Than You Think
The third discipline usually arrives last and shouldn’t. Deciding who reads the output and what claim you’re making about the product is a positioning question, and the answer constrains the engineering.
If the claim is “know before you leave the dock”, that’s an accuracy and latency requirement. If the claim is “audit-grade record”, that’s a data retention and calibration requirement. Settling what you’re going to say about the product early means the system gets built to support the claim, rather than the claim being written afterward around whatever the system happened to do. Our note on briefing an agency on a technical product covers the other half of that conversation.
Start With a Week, Not a Specification
You don’t need a finished specification to begin. You need somebody to turn your answers into a ranked risk list with a cost attached to being wrong about each item, across all three disciplines rather than one.
That’s the smallest engagement we offer: a fixed-fee scoping or review week concluding in a document stating the requirements, the ranked risks, and what each unknown would cost to get wrong. It belongs to you, and it can be executed by any competent team, including one that isn’t us.
Our coastal water quality buoy case study is exactly this kind of product: a solar sensor node, a low-power backhaul with no cellular contract, and a dashboard checked before crews leave the dock, all specified against a single operational decision. If you’re planning the calendar as well as the scope, our guide to how long hardware development takes covers the phases, and our process sets out how the stages are sequenced.