Budgeting a desktop AI robot: where the BOM money actually goes

A desktop AI robot’s bill of materials is not one cost — it is five buckets, each scaling with a different feature decision. Projects that budget by feature list end up with a BOM the price point cannot carry; projects that budget by bucket, with the feature list mapped onto it, keep the cost where the buyer’s perceived value actually lives.

Bucket one: the display assembly

For any robot with a screen face, the display is usually the largest single bucket: panel, the driver electronics behind it, touch if the interaction wants it, and the optical work that makes a panel readable at robot viewing distances. This bucket scales with size and resolution faster than any other — one screen-size step can move the whole BOM a visible amount. That is why screen size is the first conversation in a screen-face project, and the expression ambitions get sized to the panel, not the other way round.

Bucket two: compute

Compute cost follows the conversation architecture. A toy whose conversation runs in the cloud needs just enough silicon to handle sensing, expressions and connectivity; a toy running models on-device pays for memory and processing power up front. The waste pattern here is the oversized compute bought “to be safe” that scripted behaviour never exercises. Compute should be sized by the behaviour spec, with headroom stated as a percentage, not a guess.

Bucket three: voice

The voice bucket covers microphones — one or an array, depending on far-field ambitions — the speaker and its acoustic cavity, and the audio codec path. Acoustic design is the hidden half: a good speaker in a bad cavity sounds cheap, and the cavity is mechanical design, not a part number. Far-field voice arrays move this bucket up noticeably; button-triggered voice keeps it small. The wake decision from the interaction design lands here as hardware.

Bucket four: motion

Every motion axis adds a servo, a driver channel, mechanical work and battery load. This is the bucket where feature creep lives, because each axis sounds small alone. The discipline is behavioural: an axis earns its cost only if the behaviour model drives it often enough for users to notice. One well-used head axis outperforms three novelty axes in perceived life per dollar.

Bucket five: power

Battery capacity, charging hardware and the power management between them. This bucket is determined less by capacity than by behaviour — the sleep design decides whether a modest cell delivers all-day presence. Money spent on power architecture usually saves money in the cell, and weight saved here is weight available for fill and fabric elsewhere.

Keeping the five honest

The BOM exercise that works: map every feature onto its bucket, price the buckets, then walk the feature list asking which ones the buyer would notice missing. Features that no buyer would notice are BOM weight — and cutting them funds the ones that sell. We run this exercise with clients before any quotation, because the feature list should follow the price point, not the reverse.

We build desktop AI robots with the BOM mapped this way from the first cost pass. The OEM/ODM page describes how we work, or write to us with the feature list you have in mind and we will map it to the five buckets.