We've been building connected products for over a decade. In that time, we've seen dozens of projects come to us after a traditional outsourcing engagement went sideways. The pattern is always the same: separate vendors for hardware, firmware, and cloud. Specs thrown over the wall. Finger-pointing when integration fails. We built our entire model to fix this.

Where the traditional model breaks

You write a spec. Send it to a vendor. Get a deliverable. This works for isolated work packages — "design a PCB with these components" or "build an API with these endpoints."

It fails when the work packages are interdependent. Which, in connected products, is always.

Real example: a client's firmware team discovered that their chosen accelerometer had a hardware FIFO bug under specific timing conditions. The fix needed a different accelerometer (hardware change), a rewritten data pipeline (firmware change), and a new data format (cloud API change). Three separate vendors. Three separate change requests. Three separate timelines. A $200 component swap turned into a six-week, multi-contract negotiation.

This isn't an edge case. This is Tuesday in connected product development.

What we mean by extended R&D

An extended R&D partner embeds with your team. Same sprint cadence. Same Slack channels. Same design reviews. We're not a vendor you throw specs at — we're the engineering team you'd hire if you could find 8 people with cross-stack connected product experience and had 6 months to onboard them.

The contractual difference matters: instead of paying for deliverables against a spec, you engage a team with shared objectives. Our success metric isn't "did we deliver what was specified." It's "did the product ship successfully." That alignment changes everything — we're motivated to flag problems early, suggest scope changes, and make trade-offs that benefit the product.

Shape to Scale to Sustain

We structure every engagement in three phases.

Shape (weeks 1-8): Concept to validated architecture. Requirements, component selection, critical-path prototyping, system architecture. We go deep on the risky stuff first — the cellular module that needs to work in a basement, the power budget that needs to hit 5 years, the regulatory requirements that might force a board respin. Deliverable: architecture doc, BOM, working proof-of-concept.

Scale (weeks 9-30): Architecture to production-ready product. Full hardware design, firmware, cloud, mobile app, regulatory pre-testing. The team scales to 6-12 engineers. Deliverable: production files, tested firmware, deployed backend.

Sustain (ongoing): Post-launch. OTA updates, manufacturing support, feature development. Team scales down to 2-4 engineers who know the product deeply. Some of our sustain engagements are in their fifth year. That continuity matters — the people who designed the system are the ones maintaining it.

How to pick the right partner

We're biased, but here's what we'd tell you to look for regardless.

Cross-functional teams that have shipped together. Not individuals with the right skills — teams with shared muscle memory. Ask to meet the actual engineers, not just the sales team.

Domain experience. Cellular IoT is different from BLE consumer, which is different from industrial Ethernet. A firm that's great at mobile apps might be terrible at firmware. Ask what products they've taken from prototype to volume production.

Red flags: they only do one discipline (integration will be your problem), they insist on waterfall against a fixed spec (connected products are too interdependent for that), or the team changes between project phases (you lose all the context).

Key Takeaways

• Connected products cross too many disciplines for traditional spec-and-deliver outsourcing
• An extended R&D partner shares your objectives, not just your requirements
• Phase the engagement: Shape to Scale to Sustain. Match team size to product lifecycle stage.
• Look for teams that have shipped together, not just individuals with the right resumes.