From a rough idea to something you can hold, test and show.

Two ways these projects usually start

Some projects arrive as an idea with no hardware behind it. A founder understands the problem, has spoken to the people who would buy the solution, and now needs something real enough to test, to demonstrate and to learn from.

Others arrive from inside an established company. A process costs more than it should, a machine fails without warning, or a product line needs a connected version to stay competitive against newer entrants.

The engineering work is broadly similar. What differs is the constraint. A startup is usually working against a funding round and a demonstration date. An established manufacturer is usually working against an installed base, an existing process and a supply chain that cannot be disrupted while the work happens.

What a first prototype is actually for

A prototype earns its cost by removing uncertainty, not by looking finished. Before anything is built we agree which questions it has to answer. Typically some of these:

• Does the sensing approach work on the real signal, in the real environment, rather than on a bench?
• Can the device run for the required period on the power actually available to it?
• Does the chosen connectivity reach the places the product will be installed?
• Is the mechanical envelope realistic once the electronics, battery and connectors are inside it?
• Will the data collected genuinely support the decision the product promises to inform?

A prototype that answers those questions has succeeded even if it is ugly. One that looks like a finished product but answers none of them has cost you time you will not get back.

How we take an idea apart

The first work is not construction. It is separating what you know from what you are assuming.

• Requirements. What the product must do, for whom, in what conditions, and which of those constraints are genuinely fixed rather than habits.
• Risk ranking. Which unknowns would waste the most money if they turn out badly. These get tested first.
• Feasibility. Whether the physics, the power budget, the component availability and the cost target can coexist. Sometimes the honest answer changes the product.
• Architecture. How the hardware, firmware, connectivity and software divide the work between them, decided before the first board is laid out.

The route from concept to validated prototype

• Discovery and scope. Agree the questions, the deliverables and how progress gets reviewed.
• Architecture and selection. Choose the approach, the key components and the interfaces, with availability checked rather than assumed.
• Build. Electronics, firmware and any supporting software, developed together so integration is not left to the end.
• Bring-up. The first units are powered, debugged and measured. This is where most real-world surprises appear, so it is planned for rather than hoped through.
• Validation. Test against the questions agreed at the start, and record what the results actually showed, including the inconvenient parts.
• Decision point. A documented position from which you can commit to production, change direction, or stop, with evidence behind whichever you choose.

If you are a startup

An early prototype usually has to do more than work. It has to support conversations with investors, with pilot customers and with manufacturers. We keep that in view: a bill of materials that shows whether the unit economics survive contact with reality, a device stable enough to put in front of someone who matters, and documentation that a future team can pick up rather than rewrite.

We will also tell you when a full custom design is premature. Sometimes the fastest honest route to an answer is an off-the-shelf module and two weeks of firmware, with the custom hardware deferred until the concept has earned it.

If you are an existing manufacturer or operator

Work inside a running business has different rules. The prototype usually has to attach to equipment you already own, run alongside a process you cannot stop, and produce data your existing systems can use. Retrofitting onto installed machinery is often the lowest-risk starting point, because it proves the value before anything about the production line changes.

See AI for industrial machinery for how this applies to equipment already on your floor, and industrial product development for taking a proven concept into a deployable product.

What we need from you to start

The problem the product solves and who has it. The conditions it has to survive. Any constraints that are genuinely fixed, such as size, cost target, power source or the equipment it must work with. And the questions you most need answered. Our project brief checklist is a practical way to assemble this before we speak.

What you receive

Working prototype units, the design sources behind them, measurement results against the agreed questions, a bill of materials, and a written account of what was proven, what was not, and what should happen next. Deliverables are confirmed in the scope before work begins.

Talk through your idea

Describe what you are trying to build and the stage you have reached. If the scope is not yet clear, working that out is part of the conversation.