How to Choose a Development Partner for a Connected Product: 10 Questions Before You Sign
Choosing a partner for a connected product is not mainly about comparing hourly rates, headcount, or framework lists. If your product spans hardware, embedded software, mobile or web, cloud services, integrations, security, and AI, the real question is simpler: who can own the seams between those layers?
Before you sign, you should understand how a potential partner makes architecture decisions, handles failures across layers, tests on real hardware, plans updates and recovery, designs security, and leaves you with a product your own team can continue to operate.
Why connected products need a different vendor test
A connected product is rarely “just an app.” A device may collect data, an embedded runtime may preprocess it, a mobile app may configure the device, cloud services may synchronize state, external APIs may extend the workflow, and AI may interpret or act on the result.
That creates a different kind of engineering risk. One layer can look healthy while another is already failing. The app can show the right screen while the device state is stale. The backend can be available while an edge device is offline. An AI feature can look convincing in a demo and still be unusable in the field because the input is poor or there is no safe fallback.
Cybersecurity has the same cross-layer problem. NIST’s April 2026 revision of IR 8259 expands its guidance from the device alone to the full IoT product and explicitly covers both pre-market and post-market activities, including maintenance, support, software updates, and end-of-life. For a buyer, the takeaway is practical: you are choosing a team for a product lifecycle, not just for an initial build.
1. Who owns the whole system, not just each component?
Ask the team to draw the product as one system.
Where is the source of truth for state? Which commands can come from the device, app, or cloud? What happens when two layers disagree? Where does AI run? What happens when it is unavailable?
You are not looking for a prettier architecture diagram. You are looking for clear ownership. If the hardware, app, and cloud teams can each explain their own piece but nobody owns the boundaries between them, integration risk will eventually land on your side of the table.
2. What decisions will be made before development starts?
“Discovery” can mean almost anything, so ask what you will actually have at the end of it.
Will the team define product requirements? System boundaries? Data flows? Integration contracts? Technical risks? Delivery assumptions? Team shape? Scope?
At Allmatics, Product Discovery is used to clarify the business problem, technical feasibility, product requirements, and the engineering plan before full development starts. For a connected product, this is where you want expensive assumptions challenged while they are still relatively cheap to change.
3. What happens when connectivity or dependencies fail?
Do not wait for QA to discover the offline experience.
Ask what the device can still do without the cloud. What will the app show when data is stale? Which operations can be queued? How are retries, duplicate events, and conflicts handled? What happens when a third-party API disappears for an hour?
These are product decisions. Our offline-first architecture guide makes the same point from the mobile side: once several systems participate in one workflow, failure and synchronization boundaries need to be designed deliberately.
4. Who owns the contracts between device, app, cloud, and external systems?
Connected products change over time, and those layers do not always change together.
Ask how APIs, event schemas, firmware versions, and configuration models are versioned. Who approves a breaking change? How is compatibility tested when multiple versions are still active in the field?
This matters even more when several vendors are involved. Multi-vendor delivery can work, but someone still needs technical authority over the interfaces. Otherwise every production issue becomes a meeting about whose component is “working as expected.”
5. How early do you test on real hardware and real operating conditions?
A product that depends on physical hardware should not spend most of its development life inside mocks.
Ask when target hardware enters the test cycle. How does the team reproduce weak connectivity, noisy or missing sensor input, power interruptions, latency, storage limits, and version mismatch? Which of those conditions are tested continuously, not just once before launch?
The point is not to build a dramatic test lab. It is to make sure the engineering process resembles the environment in which the product will actually run.
6. How is security designed across the whole product?
“We follow best practices” is not enough detail.
Ask how device identity is established. Who can change configuration? How is data protected in transit and at rest? How are secrets handled? Which interfaces are exposed? How are software updates authenticated and verified?
NIST’s current IoT manufacturer guidance treats cybersecurity as a product-lifecycle responsibility, including customer communication, maintenance, support, and updates. That makes security ownership a useful vendor-selection question before implementation starts, not a final check after the architecture is already fixed.
7. What is the update and recovery strategy?
The first production release is not the end of development.
Firmware, mobile apps, cloud services, configuration, and AI components may all evolve on different schedules. Ask how the partner versions them, stages rollouts, detects a bad deployment, retries safely, and rolls back when needed.
The important part is not whether a team has “OTA updates” on a capability slide. It is whether they can explain what happens when an update only reaches part of the fleet, a dependency changes halfway through rollout, or a new version has to be reversed.
8. What will we actually be able to see in production?
Imagine a customer says, “the device stopped working.”
What can the support or engineering team see without physically taking the device back? Device health? Software version? Configuration? Recent errors? Connectivity state? Related app or backend events?
For connected products, observability is part of the product support model. Without it, simple failures turn into long investigations and engineering teams end up debugging from screenshots, memory, and guesswork
9. What happens when AI is uncertain, unavailable, or wrong?
If AI is part of the product, ask about its operational behavior, not only the model.
What input quality does it need? What happens below an acceptance threshold? Is there a human review path when the consequence warrants it? Can the feature degrade gracefully if the model or an upstream service is unavailable? Can model placement change later without forcing a redesign of the whole product?
That is the same architectural question we cover in our on-device AI guide: the useful decision is not “AI on device or in the cloud?” in the abstract. It is where each part should run, what data it can access, and how the system behaves when conditions change.
10. How do we keep control of the product and its knowledge?
This one is easy to postpone and painful to discover late.
Before signing, clarify who controls repositories, environments, infrastructure definitions, credentials, architecture records, operational runbooks, and documentation. Ask how knowledge transfer works, how your internal engineers can be onboarded, and what happens if the relationship ends.
A good engineering partner should make the product easier for you to own over time, not create a dependency that becomes harder to unwind every year.
What connected-product delivery looks like in practice
ReadU6 is a useful example of why this kind of ownership matters. The public Allmatics case combines web and mobile software, custom embedded hardware, AI/ML, NLP, IoT, and real-time processing in one aviation communication product. The published delivery phases include Product Discovery, prototype development, system integration and testing, and ongoing deployment and optimization.
The point is not the aviation label. It is the coordination required across hardware, software, AI, and the human interface. Those pieces cannot be treated as separate mini-projects if the final product has to behave like one system.
The ReadU6 case should not be read as evidence of FAA, EASA, or other regulatory approval or certification. We are not making that claim.
How to use these 10 questions with a shortlist
Do not send them as another procurement form.
Give each shortlisted partner one realistic product scenario and talk it through together. Pick something uncomfortable: a device loses connectivity during an update, sensor input becomes unreliable, the app and cloud disagree about state, or an AI feature needs a safe fallback.
Then listen to the questions the team asks you.
A team that can own a connected product should want to understand operating conditions, data authority, lifecycle, deployment constraints, support expectations, and business risk before promising an architecture or estimate.
The decision
You do not need a partner with the longest list of technologies on its website. You need a team that can make the boundaries between those technologies boring: clear ownership, explicit contracts, observable behavior, recoverable updates, and decisions that still hold up after the prototype becomes a real product.
If you are evaluating a connected-product build and want another engineering view before committing to scope or a vendor, Allmatics Product Discovery can help pressure-test the architecture, surface cross-layer risks, and turn the product constraints into a practical delivery plan.