Hardware Product Development for Startups

Where spec-it-all-upfront goes wrong

The failure modes repeat, and none of them comes from a lack of effort.

• Requirements written before anyone has measured the hard part, so the specification is precise about everything except what decides whether the product works
• A custom board designed in the first month around a sensor, radio or motor that nobody has yet proven on a bench
• One large number for the whole product, which a startup can rarely fund and nobody can honestly estimate before the architecture is settled
• Every feature carried into the first prototype, so it arrives late because it is trying to be the last one

The staged path

Each stage retires one named risk and ends in something you can hold, test or put in front of an investor. You decide whether to fund the next stage with that result on the table, so no single decision has to carry the whole program.

• Study it — a two-week Architecture & Roadmap Study that settles the expensive forks and names the parts carrying real risk before a build budget is committed
• Build the smallest thing that runs — the core function only, usually on development kits and off-the-shelf modules, to answer one question: can this be built?
• Grow it — move the proven core onto custom electronics and production-intent firmware, add the features that matter and harden it against real use, to answer: is it worth having, and can people use it?
• Cost-reduce it — design for manufacture, design to cost and the path to volume through EVT, DVT and PVT builds, to answer: can it be built repeatably, at a price that works?

What a startup should spend first

A startup's first engineering dollars should buy information, not inventory. At Kyros the first paid engagement is the Architecture & Roadmap Study: two weeks, $5,000 fixed, one invoice, one NDA. It starts from whatever you already have — development kits, modules, an early prototype, a list of requirements — and hands back, in writing, a rough architecture, the parts carrying real risk, the decisions and forks where the roadmap can go two different ways, the tradeoffs behind each, and the development effort to get through them. It opens with a one-page decision summary written to be forwarded to whoever approves the next step, with that step already scoped as a price range. A concept with many open decisions gets a second study, not a bigger price, and you keep the document whether or not you build with us.

Prove it on a dev kit before paying for a custom board

A custom PCB is the most expensive way to find out that a sensor is too noisy, a radio link too short or a motor too weak. Development kits, evaluation boards and off-the-shelf modules let the hard question be answered on a bench in weeks, with firmware that carries forward and a parts list that teaches you what the real one will cost. The proof of concept is deliberately unglamorous — no enclosure, often tethered to a laptop, no production concerns — because its only job is to retire the one technical risk your investors or board most doubt. The custom board comes after, designed against measurements instead of assumptions.

• A numeric pass target written down before the build, and treated as a target until it has been measured
• Written non-goals — what this prototype will deliberately not do — so the proof stays small enough to finish
• Firmware structured to move from the development kit to the custom board, so the proof is not thrown away
• A go, refine or redirect decision at the end, made with data, photos and known limitations in hand

Growing it, then cost-reducing it

Once the core is proven, the product grows in bounded steps — one board, one firmware deliverable, one subsystem brought up on hardware — each quoted phase by phase and billed against milestones. This is where the custom electronics, the firmware architecture and the mechanical integration get built for real, by the team that ran the proof. Cost reduction is designed in rather than negotiated later. Roughly 80% of a product's unit cost is locked in at design, so part choices, board count, assembly steps and test time are settled at the engineering desk, and the path to volume runs through engineering, design and production validation builds before anything is committed to tooling.

You own the product-specific work

On payment, the startup owns the product-specific work outright: schematic and PCB project files, gerbers, bills of materials, firmware and software source, mechanical CAD, drawings, test records and the prototypes themselves. Kyros keeps only its pre-existing tools, libraries and general know-how. Design files are never held back to keep a client dependent. If you later finish the product with another team or bring engineering in-house, everything they need to continue is already yours.

When the budget is smaller than the build

A startup's budget is a design input, not an obstacle to work around. When the money available is smaller than the build, the honest answer is a smaller first stage, not the same plan done thinner. We size the first stage to fit the money you have, prove the riskiest part on a development kit before committing to custom hardware, and show what each later stage would add, so every dollar buys a decision rather than a partial product.