Back to Blog
Business

What to Look for When Hiring an IoT Development Partner: 8 Critical Criteria

Most IoT development agencies can build a prototype. Far fewer can build a product you can certify, manufacture, and maintain in the field for 5 years. Here are the eight criteria that separate capable partners from capable prototypers.

December 5, 2024
11 min read
IoT Development PartnerHiring IoT AgencyIoT OutsourcingHardware Development

What to Look for When Hiring an IoT Development Partner: 8 Critical Criteria

The difference between an IoT development agency that ships production products and one that ships impressive demos is substantial — and not obvious from a website or a proposal. Agencies that are great at prototypes often have no experience with regulatory compliance, production firmware hardening, or the operational realities of supporting a device fleet after launch.

These eight criteria will help you separate the partners from the prototypers.

Criterion 1: Full-Stack IoT Capability (Not Hardware-Only or Software-Only)

An IoT product requires embedded firmware, cloud backend, and usually a mobile or web application. These three domains are deeply interdependent: the firmware's MQTT message format must match what the cloud expects; the mobile app's BLE provisioning flow must match the firmware's BLE GATT implementation; the OTA mechanism must be supported by both the cloud infrastructure and the firmware bootloader.

A hardware-only shop will deliver a working device that integrates poorly with your cloud. A software-only shop will build a great cloud backend that assumes hardware someone else figures out. You need a partner who does all three and has shipped them integrated.

How to verify: Ask for a reference from a client whose product includes custom hardware, firmware, a mobile app, and a cloud backend. Ask that client specifically about integration challenges between the layers.

Criterion 2: Portfolio of Shipped Products, Not Prototypes

Any agency can show you a demo on a dev kit. The relevant question is: how many of your products are in commercial production today, being used by real end customers?

Prototypes and MVPs do not reveal the hard problems: regulatory compliance, thermal performance over 5,000 hours, firmware memory management over months of operation, or the OTA failure recovery path when a device loses power mid-update.

How to verify: Ask for a list of products, the launch dates, the approximate unit volumes shipped, and whether the agency is still supporting them. A shop that launched 10 products but none are in active commercial use is a red flag.

Criterion 3: Security Knowledge That Runs Deeper Than TLS

IoT security is not just "use TLS." It encompasses:

  • Device identity: Certificate-based authentication, not username/password
  • Secure boot: Firmware signed with a key stored in hardware security module
  • Provisioning: How certificates are installed without being exposed
  • Key storage: Are private keys in flash (bad) or in a dedicated secure element (good)?
  • OTA security: Firmware signature verification before applying updates
  • Network policy: Device can publish only to its own topic, not read other devices' data
  • Ask your prospective partner to walk you through their security architecture for a previous IoT product. If the answer involves "we use TLS and an API key," keep looking.

    How to verify: Ask specifically: "How do you handle device provisioning in manufacturing? Where is the private key stored on the device? How do you prevent a compromised device from accessing other devices' data?"

    Criterion 4: OTA and DevOps Capability

    Shipping firmware without an over-the-air update mechanism is irresponsible. Security vulnerabilities will be discovered after launch. Bugs will be found in production. New features will be needed. Without OTA, every fix requires physical access to every device — a cost that grows linearly with fleet size.

    A competent IoT partner builds OTA into the architecture from day one and has a CI/CD pipeline for firmware releases with staged rollouts, rollback capability, and abort criteria if a release is causing device failures.

    How to verify: Ask what happens when 500 devices are in the field and you discover a critical security vulnerability. Walk through the entire process from patch to deployed update. If the answer involves manual steps or does not include staged rollout, be concerned.

    Criterion 5: Communication Style That Matches Your Working Model

    A technical mismatch in communication style will grind a project to a halt. Founders who need weekly progress demos do not work well with agencies that deliver quarterly updates. Founders who prefer asynchronous Slack updates do not work well with agencies that demand daily stand-ups.

    More specifically for IoT: hardware decisions are often irreversible. A wrong connector choice discovered 3 weeks after PCB fabrication cannot be fixed without a new revision. You need a partner who proactively communicates hardware choices before committing to manufacturing, not one who presents finished PCBs.

    How to verify: During the proposal phase, note the quality and frequency of communication. Slow or vague responses during the selling process predict slow or vague responses during delivery.

    Criterion 6: IP Protection — NDA, Work-for-Hire, and Code Ownership

    Never begin technical engagement with an agency without a signed NDA and a clear statement in the contract about IP ownership.

    The contract should specify:

  • Work-for-hire: All work product belongs to the client on payment
  • No portfolio use without consent: The agency cannot reference your product publicly
  • No competing product clause: The agency will not use your architecture or algorithms in a competitor's product for a defined period (typically 12–24 months)
  • Source code delivery: All source code, schematics, and documentation delivered in client-owned repositories
  • A reputable agency will not hesitate to sign reasonable IP protection terms. An agency that resists these clauses or proposes to retain code ownership is not aligned with your interests.

    Criterion 7: Post-Launch Support Commitment

    IoT products do not stop needing development when they launch. They need:

  • Security patch releases as CVEs are published for libraries and RTOS components
  • Compatibility updates as iOS/Android APIs change and break BLE functionality
  • Cloud infrastructure maintenance as AWS deprecates services or APIs
  • Feature additions as you learn what users actually want
  • An agency that treats each engagement as a fixed-scope project with a hard end date will leave you with an orphaned product 18 months after launch. Look for an agency that offers retainer or support arrangements and has existing clients on maintenance contracts.

    How to verify: Ask what percentage of current clients are on ongoing support retainers. A healthy agency typically has 30–50% of revenue from existing clients on maintenance or feature development contracts.

    Criterion 8: Red Flags to Walk Away From

    These are not negotiable:

  • No references from production products: If they cannot connect you with a client whose product is in commercial production, they have not shipped one.
  • Vague architecture answers: "We use standard IoT patterns" is not an answer. Competent IoT engineers can describe their architecture decisions specifically.
  • Lowest price by a large margin: IoT is a skilled, specialised discipline. A quote that is 40% below competitors is either missing scope or using junior engineers. Both outcomes are bad.
  • Refuses work-for-hire IP terms: This is a dealbreaker.
  • No OTA plan at proposal stage: Any agency quoting an IoT product without mentioning OTA updates has not thought through post-launch operations.
  • Hardware-only or software-only team: Integration is where IoT projects fail. You need the layers built by the same team.
  • Evaluating the Shortlist

    Run a structured evaluation: send each shortlisted agency the same brief technical scenario (for example: "a device loses connectivity mid-OTA update — describe your recovery mechanism"). The answers will rapidly reveal who has production experience and who has not.

    ---

    Ready to evaluate whether Code Caracal is the right partner for your IoT product? [Start with a conversation](/contact) — we will answer every question on this list directly and connect you with current clients who can speak to our delivery.

    ⚡
    Written by CodeCaracal Engineering

    We write from production experience — every technique in our articles has been deployed to real clients. No academic theory.

    Let's Build Together

    Got an IoT challenge?
    We've shipped it.

    Whether you need a fleet to track, a factory to monitor, or a farm to automate — our team has done it before and we'd love to build it with you. Typical response time: under 24 hours.

    No upfront commitment99.9% uptime SLANDA on requestFixed-price options