The Four Principles of Building Hardware Fast
Sequence the work so hardware's un-updatable, one-shot nature can't sink you.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 95%
Hardware can't be patched after launch, so the order and discipline of the work matter more than in software. Kalinowski distills decades at Apple and Meta into four moves: lock goals early, build the riskiest part first, over-iterate the parts people touch, and do everything you know you must do immediately. Together they compress schedule risk in a domain where every design loop costs months.
Origin
Caitlin Kalinowski, from her hardware leadership at Apple (MacBook Air/Pro, Mac Pro) and Meta (Rift, Quest). The 'do it now' urgency she credits to Apple colleagues Shelley Goldberg and Kate Bergeron.
Core principles
- 01Every design decision must trace back to why you're building the product and what the end goal is
- 02Hardware is not adaptable to late change the way software is — pre-decide and hold the line
- 03Iteration budget is finite; spend it where failure and user contact are highest
- 04There is never more time than you think in hardware
How to run it
- 1
Define goals (KPIs) early and refuse to move them
Write down the small set of overarching goals — cost, weight, size, resolution, features — before detailed design. Changing a target midway (e.g. a $300 device that must suddenly be $150) burns the early work. Clear priorities also tell you when you're done, which engineers otherwise never feel.
Pro tip Turn trade-offs into explicit ratios (Kalinowski cites Elon Musk assigning a numeric value to a gram of weight vs cost) so day-to-day engineering decisions 'fall out' automatically instead of being re-litigated.
Watch out Vague or shifting goals are the single hardest failure mode — a mid-project KPI change can cost you an entire build cycle of 3-5 months.
- 2
Design the hardest part first
Most people start with what they know how to design. The best architects instead start at the pinch points — where it's unclear the design can even work — and prove those out before finalizing anything around them. Kalinowski's example: routing cables through a laptop hinge; the architect sized the hinge cross-section and cable split first because that was the risk.
Pro tip Ask 'where is this going to fail?' and start the detailed design there, not at the components you already understand.
- 3
Over-iterate the parts users touch most
The surfaces a customer interacts with most — trackpad, then keyboard on a laptop — need far more iteration than everything else. They must feel good, respond properly, and be highly reliable. Components further from the user's hands need proportionally less iteration.
Watch out Getting a high-touch part wrong is disproportionately damaging — Apple's butterfly keyboard is the cautionary case of a most-touched part that failed.
- 4
Do everything you know you need to do right now
Stack the known tasks and clear them immediately, even when the schedule technically allows waiting. In hardware a surprise is always coming in a couple of days, and you'll need that slack to fix it. This 'ruthless efficiency' assumes you never actually have spare time.
Watch out Treating buffer time as free is a trap — in hardware you genuinely don't have more time; the surprise will consume it.
In the wild
To 'democratize VR,' the team committed to a single overriding goal — reduce price — and let it drive a full redesign: removing cameras and components, changing materials and manufacturing processes. Because the goal was unambiguous, every downstream engineering decision followed from it.
→ Became, per Kalinowski, the highest-selling VR headset of all time, with low return rates and arguably a stronger product than before.
On a laptop build, the architect began not with the known display but with the uncertain part: whether the cables would physically fit through the hinge. He analyzed the cross-section and how to split the cables before finalizing the hinge.
→ The riskiest interface was de-risked first, preventing a late-stage failure that would have cascaded into the surrounding design.
Common mistakes
Loosening a KPI mid-development
Changing a core goal (like target cost) halfway through wastes the early time already spent optimizing for the old target, and can cost a whole build cycle.
Starting with the easy, familiar parts
Designing the components you already understand first leaves the true risk unproven; if the hard part fails late, everything built around it has to be reworked.
Is it for you?
Best for
Founders and engineering leads at software-native companies moving into physical hardware for the first time
Not ideal for
Pure software or web products where continuous shipping and post-launch updates make late change cheap
From the transcript
“Having your goals defined early and sticking to them is important.”
“the right approach is to design the hardest parts first”
“the part that your customer touches or interacts with the most needs way more iteration than everything else”
“you can't wait around ever. Like there's never enough time.”
From the episode
Why we’re at the beginning of the AI hardware boom
Caitlin Kalinowski (ex–OpenAI, Meta, Apple)