The Physical Product: What Appears When Your Idea Gets a Body

What this is. Opinion + Experience + Fact (45% opinion · 25% experience · 30% fact). Written in collaboration with AI — I discuss, I do not outsource.

AI Builder, the chapter where ideas become objects. AI has made software feel almost free to produce — but the moment your product grows a body, a layer of the real world reappears that no prompt can wish away. This is what a builder needs to be aware of the instant a product becomes physical: mechanical, materials, electronics, and power. Awareness, not mastery — plus a reusable prompt to make AI help instead of hallucinate.

There's a quiet assumption underneath the "anyone can build now" excitement: that building is mostly software, and software is what AI is best at. For a pure app, that's close to true. But most real products — the interesting ones, the ones that touch the world — have a body. And a body changes everything, because physical reality doesn't care how elegant your code is. Software can ignore friction. Physical products cannot.

This chapter of the series is about what appears the moment your product is physical, and how to stay useful there as a broad, AI-fluent builder rather than a specialist — one domain in the wider builder stack this series maps. You don't need to become a mechanical engineer. You need enough awareness to ask the right question, give AI the real constraints, and catch an answer that's confidently, physically wrong.

---

1. The body has rules software never had

Shape, force, motion, tolerance. A part that snaps together perfectly in CAD can still bind, rattle, or crack in a real hand, because the physical version has manufacturing tolerances, real materials, and real loads the model idealised away. Heat and vibration are the same: they don't read your datasheet or your spec — they act on whatever you actually built, in whatever environment it actually ships into.

The important part for a builder is the ordering. These constraints exist before a single line of code runs, and they don't negotiate. You can refactor software forever; you cannot refactor the laws of heat transfer, or the fact that the enclosure has to be moulded, or that the button will be pressed a hundred thousand times. The physical layer sets the boundary conditions everything else lives inside.

▸ First principle. Physical reality sets the constraints before software gets a vote.

2. Materials and power are design decisions, not details

Two choices quietly decide most of a physical product, and both get treated as afterthoughts far too often. The material determines cost, weight, feel, how it conducts or holds heat, how it wears, and how it ages in sun or humidity — choose it late and you're not tweaking, you're redesigning. And power is a hard budget: every feature you add draws from a battery or a supply with a real ceiling, and "add another sensor" can quietly halve your battery life.

This is why "it works on the bench" is such a dangerous phrase. On the bench, the device is usually plugged in and at room temperature. The field is neither. A builder who is aware of materials and power early asks the questions that keep a product from being beautiful and unshippable — and asks them while they're still cheap to answer.

▸ First principle. Material and power aren't finishing touches; they shape the product from the first sketch.

3. Awareness, not mastery — and where AI helps or hurts

Here's the freeing part and the trap, together. You do not have to master mechanical engineering or power electronics to build a physical product as a broad builder. You have to be aware enough to ask the right questions, recognise the trade-offs, and know when to bring in a specialist. That's a much lower bar than mastery — and a much higher one than "AI will handle it."

Because the physical layer is exactly where AI is most confidently wrong. It will happily propose an enclosure that can't be moulded, a battery that can't fit, or a mechanism that ignores tolerance stack-up — fluent, plausible, and unbuildable — if you don't hand it the real constraints. The research on AI at work is consistent: it raises the floor most for non-experts and is brilliant inside its frontier and unreliable just outside it. In the physical world, "just outside its frontier" is where products get built. So the builder's job is to bring the constraints; give AI the material, the tolerance, the thermal and vibration environment, the manufacturing process, and the serviceability requirement, and it becomes a genuinely useful design partner. Withhold them, and it invents them for you.

▸ First principle. In the physical layer, AI amplifies whoever brought the constraints — bring them, or it invents them for you.

4. The cheat-sheet + a prompt that keeps AI honest

The four domains above are the awareness map: when your product gets a body, walk them before you commit. And here is a reusable prompt that forces you to supply the real constraints and forces the model to surface its own uncertainty — the same "give context, then verify" pattern this series keeps returning to. Fill the brackets and read the CHECK section as carefully as the design.

You are helping me think through the [mechanical / enclosure / power] design
of [product], for a builder who is not a specialist.

Constraints you MUST respect (do not assume defaults):
- Environment: [temp range, humidity, IP rating, indoor/outdoor, drop/vibration]
- Mechanical: [size and weight limits, forces/loads, motion, cycles]
- Material: [required properties - strength, thermal, food-safe, UV - and cost target]
- Power: [source, energy budget per day, battery size/chemistry, duty cycle]
- Manufacturing: [volume, process (injection mould / CNC / sheet metal), DFM limits]
- Serviceability: [must it open? replaceable parts? field repair?]

First, propose a design that satisfies ALL of the above.

Then, in a section titled CHECK:
1. List every assumption you made that I did not give you.
2. Name the single constraint most likely to fail in the real world, and why.
3. Name what a mechanical or manufacturing engineer should review
   before we commit tooling.

Research keywords (for going deeper on any domain): mechanism, force, torque, tolerance stack-up, material selection, enclosure, thermal management, vibration, IP rating, PCB layout, EMC/EMI, signal integrity, energy budget, battery chemistry, duty cycle, DFM, serviceability.

▸ First principle. Give AI the constraints and make it show its assumptions, and it designs with you instead of guessing for you.

---

Once the product has a body, it needs senses and muscles — sensors, actuators, and the firmware that makes them act. That's the next chapter.

Sources

On how AI changes who can build: it raises the floor most for non-experts (Brynjolfsson, Li & Raymond, "Generative AI at Work," NBER) and is a "jagged frontier" — strong inside its competence, unreliable just outside it (Dell'Acqua, Mollick et al., "Navigating the Jagged Technological Frontier," HBS/BCG). The physical-layer domains and constraints described here are standard product-engineering practice; this piece is a labeled opinion carrying no invented statistics.

FAQ

Do I need to be a mechanical or electrical engineer to build a physical product?
No — you need awareness, not mastery. Enough to ask the right questions, understand the trade-offs across mechanical, materials, electronics, and power, give AI or a specialist the real constraints, and recognise a wrong answer. Deep specialism you can bring in; awareness you cannot outsource.

Why can't AI just design the physical product for me?
Because the physical layer is where AI is most confidently wrong. It will propose designs that can't be manufactured, powered, or assembled if you don't give it the real constraints — material, tolerance, thermal and vibration environment, manufacturing process, serviceability. Supply those, and it becomes a strong design partner; withhold them, and it invents them.

What are the main things that appear when a product becomes physical?
Four domains: Mechanical (shape, force, tolerance, vibration, thermal, enclosure, serviceability), Materials (strength, cost, feel, thermal behaviour, aging, manufacturability), Electronics (PCB, components, EMC, signal integrity), and Power (source, energy budget, battery, duty cycle). Each sets constraints before software matters.

Why is "it works on the bench" risky for a physical product?
Because on the bench a device is usually plugged in and at room temperature, while the field is neither. Power budgets and thermal behaviour that look fine on the bench often break in real conditions, so materials and power need to be design decisions from the first sketch, not afterthoughts.

AI Builder — a labeled opinion, grounded where it makes factual claims. The short version lives on my LinkedIn; the whole series compiles into the AI Builder Handbook on my profile. — Ritesh | ritzylab.com