Week 1–2
Discovery
We map the physical process first: what is being measured, how often, over what link, and who acts on it. You leave with an architecture sketch, a risk list and a fixed price for the next phase.
How we work
A pilot in the field before the contract is half spent
Connected products fail in ways a lab never shows you, so we get real hardware onto a real site early and let it argue with our assumptions.
Week 3–6
Prototype
One device, one gateway, one screen, end to end. Ugly on purpose. It exists to prove the radio link, the power budget and the data model before anyone designs an enclosure.
Week 7–14
Pilot fleet
Twenty to fifty units on a real site. We watch the failures that only appear in the field — thermal drift, dead zones, someone unplugging the gateway — and fix them while the fleet is small.
Week 15+
Production
Manufacturing test jigs, provisioning at the factory, staged OTA rollouts, and load testing against a simulated fleet ten times your launch size.
Ongoing
Run or hand over
We either operate the platform on an SLA, or spend a month pairing with your engineers until they are shipping without us. Documentation and runbooks come either way.
In detail
What actually happens, phase by phase
Select a phase to see the activities, what you receive at the end of it, and the one thing we need from you to make it work.
Discovery
Week 1–2
Discovery is deliberately short and deliberately physical. We want to stand where the device will stand, meet the person who installs it, and see what your team does today when something breaks. Most of the expensive mistakes in a connected product are made in this fortnight, by assumption rather than decision.
What we do
- Site visit, or a call with whoever actually goes to site
- Message rate and payload modelling against the real reporting requirement
- Radio and power feasibility on the constraints you actually have
- Threat model covering device identity, update integrity and data access
- Review of any existing system we would be integrating with or replacing
What you receive
- Architecture sketch with the decisions and their reasoning written down
- Risk list ranked by cost of being wrong, not by likelihood
- Fixed price and scope for the prototype phase
- A short list of what we recommend you do not build
What we need from you
- Access to one person who knows the physical process, and an hour with whoever is on call today.
How we behave
Four things we hold to on every engagement
Get hardware onto a real site early
Connected products fail in ways a lab never shows you. The single best predictor of a project going well is how soon a device is somewhere inconvenient and real.
Weekly demo, not a status report
Every week you see the thing working, or you see exactly where it stopped. Written status reports are where problems go to be reworded.
Write down decisions and their reasoning
Six months later, the question is never what was decided; it is why. Every meaningful choice lands in a short architecture decision record in your repository.
Say what we recommend you do not build
Most scope lists contain a feature that will cost three months and be used twice. We will point at it in discovery, and we will be specific about why.
Discovery is two weeks and priced separately
It ends with an architecture sketch, a ranked risk list and a fixed price for the phase after it. If the answer is that you should not build this, we will say so then.