From idea to prototype: what happens in the first month

You have an idea for a connected product: a device, an app, or both. Before committing to full development, the most valuable thing you can do is build something real and test it. Here's what typically happens in the first month of a new product with us.

A prototype isn't a small version of the finished product. It's an experiment designed to answer the questions that would be expensive to get wrong later: Will the sensor be accurate enough? Will the radio reach? Will people actually use the app? Four weeks is usually enough to answer the biggest of them.

Week 1: understand the problem

We start by talking, not building. The goal is to understand the problem well enough to know what the prototype must prove.

The questions we ask include:

• Who is it for? Who installs it, who uses it every day, and who pays for it? These are often different people.
• What happens today? How is the job done now, and what does it cost in time, money or mistakes?
• Where will it live? Indoors or outdoors, mains or battery, near Wi-Fi or kilometres from anything? We visit the site when we can.
• What must it measure or control? And how accurately? "Roughly right every 15 minutes" and "exact every second" lead to very different designs.
• What does success look like? A number we can test against, such as "saves 20% of water" or "alerts within one minute".

By the end of the week we agree on a short list of the riskiest assumptions. Those are what the prototype will test.

Week 2: design the system and choose parts

Next we sketch the whole system on one page: the device, how it connects, where data goes and what the user sees. Then we choose parts.

• Off-the-shelf first. For a prototype we use development boards and ready-made sensor modules wherever possible. Designing a custom circuit board comes later, once we know what works.
• Connectivity. We choose between Wi-Fi, 4G and LoRa based on range, data and power, and test signal strength on site if it's uncertain.
• Power. We estimate the energy budget early, because it affects the choice of processor, radio and battery.
• Software. We decide what runs on the device, what runs in the cloud, and what the first version of the app or dashboard needs to show.

Parts are ordered at the start of the week so they arrive in time to build.

Week 3: build the proof of concept

This is the busiest week. Hardware, firmware and software are built side by side by one team, so problems between them are found and fixed quickly.

• Hardware: sensors and boards wired together, often in a simple enclosure so it can survive a real test.
• Firmware: code to read sensors, handle sleep and power, and send data reliably.
• Back end: a place for data to arrive and be stored, with simple rules for alerts or automatic actions.
• Front end: a basic web dashboard or mobile screen that shows live readings and lets you control the device.

We share a short demo with you during the week. Seeing it working, even roughly, often brings new ideas and better questions.

Week 4: test in the real world

A prototype that only works on a desk hasn't proved much. In the last week we put it where it will actually be used, for as long as the schedule allows.

• We check accuracy against a trusted reference instrument.
• We measure signal strength and how many messages actually arrive.
• We measure real power consumption and estimate battery life.
• We watch real users try the app and note where they hesitate.

Then we sit down together and review the results against the success measures from week one.

What you have at the end

• A working prototype you can see, hold and demonstrate to colleagues or investors.
• Test results showing what worked, what didn't and why.
• A recommended design for the production version, including changes the testing revealed.
• A plan and estimate for the next stage, from field pilot to production, built on evidence rather than guesses.

Every project is different

This four-week shape is a typical starting point, not a fixed rule. Pure software products often move faster. Products needing special sensors with long delivery times, certification or tests that depend on a growing season need more time. We'll agree the plan with you at the start.

How to prepare

You'll get the most from the first month if you can bring:

1. A clear description of the problem and who has it.
2. Access to the site, or photos and measurements if a visit isn't possible.
3. One or two real users who can try the prototype and give honest feedback.
4. Any existing systems the product needs to connect to, such as ERP, accounting or customer apps.
5. Your budget range and timeline, so we design a prototype that leads somewhere realistic.