The Hardware Tax
Building physical products costs roughly 3x what people expect. The gap isn't in the parts — it's in everything that happens after the prototype works.
There’s a number that shows up in almost every hardware project we’ve worked on, and it doesn’t matter much whether the project is a custom IoT device, a CNC-cut product, or a 3D-printed part that needs to go into production. The number is three.
Whatever you think the project will cost, multiply it by three. Not because the original estimate was wrong about the parts, or the fabrication, or the first prototype. Those numbers are usually close. The gap is everything that comes after the prototype works.
The Prototype Is Not the Product
This is the single thing that trips up engineers and makers when they move from personal projects to something that ships to real people. A prototype proves a concept. A product has to work for someone who isn’t you, in conditions you didn’t test, after being assembled by someone who doesn’t know the project history.
The gap between those two things costs money in ways that aren’t obvious until you’re in them.
First, there’s the tolerance stack. A prototype gets assembled by the person who designed it, who can make it work even if the tolerances are slightly off because they know where to push. A product has to assemble correctly every time without that knowledge in the loop. Getting tolerances right for repeatable assembly often means a redesign — sometimes two or three.
Then there’s the firmware story. Every embedded device has a firmware update story whether you planned for it or not. If you didn’t plan for it, someone is going to be physically in front of the device running a script at some point. Planning for it means OTA updates, bootloaders, version management, and a decision about what happens if a bad update bricks a device in the field. None of this was in the prototype.
Then there’s regulatory. If your device has a wireless radio — WiFi, Bluetooth, Zigbee, anything — it needs FCC certification. If it’s going to a commercial customer or a product category that has UL or CE expectations, add those. FCC alone is typically $5,000–$15,000 and 6–12 weeks, and that’s assuming your first submission passes. Second submissions are common.
Then there’s documentation, packaging, return handling, and the QC process that catches the 3% of units that have some defect before they ship. Each of these is a small project in itself.
Why People Miss This
The most common reason hardware projects run over budget isn’t bad estimation — it’s category error. The person scoping the project is thinking about the thing that gets built, when the actual work is the system around the thing.
Software people move into hardware and they underestimate the physical world’s refusal to behave like code. If your function is wrong, you fix it and redeploy. If your part has a tolerance problem, you go back to the manufacturer or the 3D printer or the CNC shop with revised files, wait for another run, and find out if the fix worked.
Makers move into production and they underestimate the gap between “making one” and “making a hundred.” Making one is a craft operation. Making a hundred is a process design problem — and the process has to work even when the person who designed it isn’t watching.
The Three Buckets
If you’re scoping a hardware project and want to avoid the three-times surprise, think in three buckets instead of one.
Bucket one: the thing. Parts, fabrication, assembly, first prototype. This is what most people estimate and usually estimate reasonably.
Bucket two: making it real. Everything that has to happen before you could hand one to a customer and feel good about it. Tolerance refinement, firmware stability, field serviceability, regulatory, basic QC. This is often 50–100% of bucket one and gets skipped in initial estimates.
Bucket three: the system. Packaging, documentation, return handling, manufacturing jigs, supplier relationships, version control for hardware revisions. This is often another 50% of bucket one and almost always skipped.
The three-times rule is a rough approximation of what you get when you add all three buckets together honestly. Projects that come in under it usually do so because they cut something from bucket two or three — which isn’t saving money, it’s deferring it.
What to Do With This
The honest answer is: if the project only makes sense at bucket-one cost, it probably doesn’t make sense yet. That’s not always what people want to hear, but finding it out at the estimate stage is cheaper than finding it out after the prototype.
If the project makes sense at full cost, the most useful thing you can do is name the buckets explicitly and scope each one. The hidden cost of hardware isn’t that the work is expensive — it’s that the work is invisible until you’re doing it. Naming it makes it plannable.
We’ve found that clients who go into hardware with a realistic budget split across all three buckets ship. The ones who think they’re buying a prototype and are surprised by everything after that usually don’t — or they do, but the unit economics never work out because the margin got eaten by the costs they didn’t plan for.
The prototype is the easy part. The product is the work.