Most technology partnerships are judged on the wrong evidence. A client compares proposals, day rates, and portfolio screenshots — none of which predict whether a complex product will actually ship. The information that does predict it is generated before any contract exists, during the conversations about scope.
How a prospective partner behaves when a requirement is ambiguous, when they disagree with you, and when they are asked for a number they cannot yet know tells you more than any case study. This article is about what to look for in that period, and what to show if you are on the other side of the table.
Why Proposals Are Weak Evidence
A written proposal rewards whoever is most confident, not whoever understands the problem best. That produces a predictable pattern in hardware and IoT projects especially.
- The cheapest quote usually understood the least. A low number often means certification, environmental testing, fleet operations, and support were not costed because they were not considered.
- Confidence is easy to fake and hard to verify. Nobody can accurately quote a connected product before the sensing approach is validated, so a precise figure early is a signal about sales, not engineering.
- Portfolios show outcomes, not conduct. They do not reveal how the team behaved when a sensor did not work or when the schedule slipped.
The useful question is not “what will this cost?” but “what would change this estimate, and how will we find out?”
What to Look For Before Signing
They ask about the decision, not the device
A partner who starts with “who acts on this data, and what will they do differently?” is building the right thing. One who starts with a component list is building what you asked for, which is not the same.
They name the unknowns out loud
Strong teams say plainly which parts are uncertain — whether the signal is detectable, whether the radio reaches, whether battery life is achievable — and propose a short piece of work to resolve them before committing to a full estimate.
Being told “we do not know yet, and here is how we would find out in three weeks” is a better sign than a confident fixed price.
They raise the invisible scope
Certification, provisioning, OTA updates, fleet monitoring, support and returns are where IoT budgets break. A partner who brings these up unprompted has shipped products; one who does not, probably has not.
They disagree with you during the sales process
This is the most useful signal available. If a partner pushes back on an assumption before they have your money, they will push back when it matters. Total agreement during pre-sales usually becomes change requests later.
They explain how they work, not just what they build
How often you will see working output, how decisions get recorded, what happens when something slips, who you talk to when there is a problem. Process questions predict the experience far better than technology questions.
They are clear about what you own
Source code, schematics, firmware, design files, and cloud accounts. A partner comfortable with you owning everything and being able to leave is a partner confident you will not want to.
Signals That Predict Trouble
How to Structure the Start
These expectations line up with the realities of connected products: the parts that cost the most are the ones nobody demos, as set out in what an IoT product really includes.
Frequently Asked Questions
Conclusion
The evidence that predicts a successful technology partnership is produced before any contract is signed — in whether the partner asks about decisions rather than devices, names what they do not know, raises the scope nobody demos, and is willing to disagree.
Start with a small paid piece of work, define success as a number, write down the assumptions, settle ownership early, and agree who maintains the product after launch. Partnerships built that way survive the problems that every serious project eventually produces.