Key takeaways
- Every engagement reduces to four separate choices: build or buy, how many vendors, where the team sits, and how the work is priced.
- The more specialised and non-reusable the knowledge, the stronger the case for keeping it in house.
- The right pricing model tracks how well-defined the work is, not how much you would prefer to pay.
- The model should change between NPD and NPI, because requirements are still shifting in the first and largely fixed in the second.
Product development engagement models are the different ways a hardware team can structure a paid relationship with an outside development partner: what gets built in-house versus contracted out, how many vendors are involved, where they are located, and how the invoice is calculated. Most disputes between founders and development partners trace back to picking the wrong model for the stage of the project, not to a bad partner.
This piece covers the four decisions that actually define an engagement, the four common ways hardware development gets priced, and how the right model shifts as a project moves from an undefined idea toward a manufacturable design. It assumes you have already worked through how to choose a hardware product development partner and are now deciding how to structure the deal with the partner you’ve picked.
Four decisions that define the engagement
Every hardware engagement, however it is described in a proposal, reduces to four separate choices. Conflating them is where founders get into trouble: agreeing to a pricing structure before deciding who is doing the work, or picking a vendor before deciding how much of the work is even worth outsourcing.
- Build or buy. Does this capability belong inside your company long-term, or is it a one-time need better served by an outside team?
- How many parties. One person, one firm covering the whole scope, or several specialists coordinated across contracts?
- Where the team sits. Domestic, nearshore, or offshore, and what that means for time zones, communication, and IP exposure.
- How the work is priced. Fixed-price, time and materials, retainer, or some combination.
The rest of this guide takes each decision in order.
Decision 1: Build the capability or buy it
The classic framework for this choice comes from transaction cost economics: the more specialized and non-reusable the knowledge involved, the stronger the case for building it internally rather than buying it on the open market. A one-off enclosure redesign rarely justifies a full-time mechanical engineer on payroll. A product line needing continuous firmware updates for years has a much stronger case for hiring in-house.
A second, older framework from management strategy makes a related point: companies do best when they identify their actual core competency and outsource what falls outside it. For most hardware startups, the core competency is the product concept and the customer relationship, not PCB layout or injection-mold tooling design, which is why those functions get contracted out even by well-funded teams, often to a firm that offers OEM services covering the engineering work end to end.
| Signal | Leans toward build (in-house) | Leans toward buy (outsource) |
|---|---|---|
| How specialized is the skill | Broadly reusable across future products | Narrow, one-time, or rarely needed |
| How well-defined is the work | Requires constant on-the-fly redirection | Can be captured in a written scope |
| How often you’ll need it | Continuous, ongoing need | One project, unlikely to repeat |
Decision 2: One person, one firm, or several vendors
A single statement of work with one vendor is the easiest structure to manage: one point of accountability, one set of deliverables, one acceptance process. Splitting a hardware build across a freelance industrial designer, a separate PCB house, and an independent firmware contractor can lower cost on paper, but every seam between them becomes a place where a defect can be blamed on someone else’s part of the system.
A statement of work is the document that governs any of these arrangements, whether there is one vendor or five. At minimum it should define the scope, the deliverables and their acceptance criteria, the timeline, and the payment schedule tied to it. When multiple vendors are involved, each needs its own SOW, and something (a lead engineer, a program manager, or the founder personally) has to own the integration between them, since no individual vendor is contractually responsible for whether the pieces fit together.
- One firm, full scope: simplest to manage, single point of accountability, typically the right default for a first hardware product.
- Multiple specialists, coordinated by you: can access deeper expertise per discipline, but you (or someone you hire) becomes the integrator.
- One firm with subcontractors it manages: you get single-vendor accountability while the firm sources specialist help behind the scenes.
Which category a vendor falls into is also tied up with what kind of company it is. An engagement with an OEM-style partner reads differently on paper than one with an ODM or a contract manufacturer, because the starting point for the design itself is different in each. See OEM vs ODM vs EMS for how that choice affects the deal you’re structuring.
Decision 3: Where the team sits
Domestic, nearshore, and offshore development each trade off differently on time zone overlap, communication friction, and cost. None of that is unique to hardware. What is worth flagging for physical products specifically is that crossing borders also raises questions about protecting trade secrets and where you may eventually need patent protection, since a design shared with a team abroad is exposed to that country’s legal environment. The World Intellectual Property Organization and the USPTO both publish guidance on these questions, and it’s worth an attorney’s input before sharing unpublished designs outside the country where you plan to file first.
None of this makes offshore or nearshore development unsafe. It means the contract should say explicitly who owns the resulting designs, what happens to source files and CAD models when the engagement ends, and whether the vendor may reuse anything it develops for you on a competitor’s product.
Decision 4: How the work is priced
Once you know who is doing the work, the last decision is how the invoice gets calculated. A handful of structures cover almost every hardware engagement, sometimes combined within a single contract.
Fixed-price, time and materials, and hybrids
A fixed-price arrangement sets one price for a defined scope of work regardless of how many hours it actually takes the vendor to deliver it. It only works when the scope is specific enough to price accurately in advance, which is why it suits well-defined stages of a project (a known board layout, a specified enclosure) far better than open-ended exploration.
A time-and-materials arrangement bills for actual hours worked at an agreed rate, plus materials. It is used when the scope cannot yet be pinned down precisely, and it shifts more schedule and cost risk onto you as the client, which is also why it needs more of your own oversight. The U.S. Government Accountability Office, reviewing federal use of this contract type, found that time-and-materials arrangements give the contractor little built-in incentive to work efficiently, since more hours billed simply means more revenue. The same incentive problem applies to a commercial hardware engagement, so an actively managed T&M contract needs milestones, not just a monthly invoice.
| Model | Best suited to | Who carries the risk |
|---|---|---|
| Fixed-price | Scope is specific and unlikely to change | Vendor absorbs cost overruns |
| Time and materials | Scope is still being discovered | Client absorbs schedule and cost risk |
| Hybrid (split by phase) | Part of the project is defined, part isn’t | Shared, split along the same line as the scope |
A hybrid structure, pricing the well-defined parts of a project fixed and the exploratory parts as time and materials, is common in commercial contracting and is common enough that federal acquisition rules formally allow splitting a single contract this way rather than forcing the whole scope into one pricing type. It suits hardware well, since the same project often contains both kinds of work at once: a known enclosure redesign priced fixed, alongside firmware whose scope is still evolving priced as T&M.
A fourth structure, a retainer, is a recurring payment that reserves a vendor’s capacity and availability over a period of time, rather than pricing a specific, bounded scope of work. It suits an ongoing relationship, such as continued firmware support after launch, better than it suits a one-time development project.
NRE versus what each unit costs later
Non-recurring engineering (NRE) is the one-time cost of researching, designing, and testing a product before production, covering the engineering work and, depending on the project, tooling and pre-production validation too. Once the design is finished, NRE doesn’t increase no matter how many units you build; unit cost is the separate, ongoing cost of producing, storing, and selling each individual unit, including both its fixed and variable costs.
Confusing the two causes surprises later. A quote covering NRE only won’t include what each unit costs at volume, and a per-unit price with no NRE broken out makes it hard to tell what you’re actually paying for design work versus manufacturing. For a full breakdown, see how much it costs to develop a hardware product.
Matching the model to the risk in your project
The right pricing model tracks how well-defined the work is, not how much you’d prefer to pay.
High uncertainty projects
Early concept work, first-of-a-kind mechanisms, and anything where the team is still discovering the problem rather than executing a known solution should begin with technical feasibility, which defines the requirements before a fixed cost is quoted for the agreed development scope. Forcing a fixed price onto undefined work doesn’t remove the uncertainty. It just moves that cost into the vendor’s quote as padding, or into change orders once the real scope becomes clear.
Well defined projects
Once a design has cleared engineering validation and the remaining work is a known board respin, a specified enclosure, or a documented software feature, fixed-price is usually the better fit for both sides: it is easier to budget, and the vendor has enough certainty about scope to price it without a large risk premium built in.
How engagement models change between NPD and NPI
New product development (NPD) is the earlier, higher-uncertainty phase: concept, design, and engineering validation, where requirements still shift as the team learns what works. New product introduction (NPI) is the later phase: taking a finished design through manufacturing readiness and into production ramp, where the deliverables are far more defined. See NPD vs NPI for the full distinction between the two phases.
Because NPD work is less defined, it should begin with technical feasibility, which defines the requirements before a fixed cost is quoted for the agreed development scope. NPI work starts from a design that already exists, so its deliverables (a validated BOM, a qualified supplier, a production-ready tooling package) are specific enough that fixed-price or a tightly scoped SOW usually works. A single engagement spanning both phases often ends up as a hybrid for this reason: T&M or milestones through NPD, converting to fixed-price once the design is frozen and NPI begins. Milestone dates in that kind of contract should be sanity-checked against a realistic overall schedule; see how long it takes to develop a hardware product for what a typical calendar actually looks like stage by stage.
Terms worth negotiating before signature
None of this is legal advice, and a contract that governs real money and real IP should go through an attorney before you sign it. What follows are the questions worth having answered before that conversation, not the language to put in the contract.
- Is the scope defined enough for fixed-price, or is time and materials the more honest structure for where the project actually is?
- What are the acceptance criteria for each deliverable, and who decides whether a milestone has actually been met?
- Who owns the design files, CAD models, and source code once the engagement ends, and can the vendor reuse any of it elsewhere?
- Does the vendor subcontract any of the work, and if so, who is accountable if a subcontractor’s piece fails?
- What happens if the timeline extends, particularly on a fixed-price contract where the vendor absorbed the original cost estimate?
A written statement of work that answers these questions before work starts is worth more than a strong relationship with the vendor’s sales team. It is also the document you will actually reference if something goes wrong six months in. Before you get to negotiating terms at all, it’s worth confirming the vendor is who they claim to be; see how to vet a hardware development company for the checks to run before signing anything.
Frequently asked questions
What is the difference between NRE and unit cost?
NRE is the one-time cost of designing and testing a product; it does not change no matter how many units you build. Unit cost is the ongoing cost of producing each individual unit at volume. A quote should separate the two clearly.
Is fixed-price or time and materials better for a hardware project?
Neither is universally better. Fixed-price fits work that is specific enough to estimate accurately in advance. Time and materials fits work whose scope is still being discovered, with the tradeoff that it shifts more schedule and cost risk onto the client.
Can one engagement use more than one pricing model?
Yes. Splitting a project so that well-defined parts are priced fixed and exploratory parts are priced time and materials is a common way to structure a hybrid engagement rather than forcing the whole project into one model.
Should I hire one firm or several specialists?
One firm with a single scope of work is simpler to manage and gives you one point of accountability. Multiple specialists can offer deeper expertise per discipline, but someone (you, or a program manager) has to own the integration between them.
Does an offshore engagement change what should be in the contract?
It adds questions worth resolving explicitly: who owns the resulting designs, what happens to source files at the end of the engagement, and whether the vendor can reuse anything it develops for you elsewhere. These are worth discussing with an attorney familiar with IP protection across borders.
How does the engagement model change between NPD and NPI?
NPD work is less defined, so it should begin with technical feasibility, which defines the requirements before a fixed cost is quoted for the agreed development scope. NPI work starts from a finished design, so its deliverables are specific enough to support fixed-price or a tightly scoped statement of work.
Where Inventornest fits
Inventornest works as a single point of accountability across the engagement, rather than leaving you to coordinate separate vendors for industrial design, electronics, and manufacturing handoff. We begin with technical feasibility, define the requirements and then quote a fixed cost for the agreed development scope. Our proposals specify deliverables, exclusions, timelines and payment milestones. If you want to talk through which structure fits your specific project, book a consultation.
