Hardware product development, from requirements to delivery.
Turning an idea into a working device means writing down what it must do, designing it, building it and managing the work, and a company with no engineering team has nobody to own that. We cover requirements, the product development lifecycle and project management, and our own builds span a field trial and v0 designs.
The problem
Hardware projects tend to go wrong when requirements are loose, because every later choice rests on them. A requirements document for a hardware product would typically cover its function, the environment it works in, how it is powered, how it connects and where its data ends up. We would write it with you in plain language so that mechanical, electronics, firmware and cloud work can be traced back to it, and revise it as the design firms up. From there we would plan the development lifecycle around the stage the product has reached, from a first prototype to a pilot and, if the project calls for it, production.
Project management covers the plan, the order in which parts are designed and built, and the coordination between mechanical, electronics, firmware, radio, cloud and web work, with specialists joining as it needs them. We use plain labels for where a design stands, such as schematic complete, in layout, v0 and in trial, and our own builds carry them. Requirements are most useful when they say what the product must not do as well as what it must.
We would record constraints such as size, power source, connectivity and environment next to the functions, and keep a short list of open questions so that nothing is decided by default. The lifecycle then follows from them: what to prove on a bench prototype, what only a pilot on a real site can show, and what has to change before the design is made in numbers.
Where a design is not yet ready for production we would say so. Project management is mostly about order. Parts that are slow to source, boards that take time to be made and software that depends on hardware all have to be sequenced, and we would plan around the longest of them. Decisions about who owns each part of the work, who signs off a change to the requirements and who talks to suppliers are easier to settle at the start than in the middle, so we would raise them with you in the first conversations. A company with no engineering team gains most from having one person who can explain, in plain terms, why each choice was made.
What we'd build
What we would run for a product project
Our own builds sit at different stages, which shows the labels we use. They are not finished products, and no client project documents are shown here.
| Layer | What we'd do | Detail |
|---|---|---|
| Requirements | Product requirements written with you, covering function, setting, power, connectivity and data. | |
| Lifecycle | The path from prototype to pilot to production, planned against the stage the product has actually reached. | Our LoRaWAN node is at field trial, the drone boards at v0 design and the cellular tag at schematic and layout |
| Project management | Planning, sequencing and coordination of the mechanical, electronics, firmware, radio, cloud and web work. |
How working with us goes
- 01 Scope We agree what has to be built, where it lives and where the data goes.
- 02 Prototype Working hardware and firmware on your bench, tested against real conditions.
- 03 Pilot A small batch on real sites, with fixes folded back into the design.
- 04 Production Design for manufacture, a production run, and support once it is in the field.
Related
Technical research ·PCB design ·Embedded firmware development ·Robotics prototyping · All sectors →