Your device works. Now it needs a product around it.
Software for hardware and connected products: device onboarding, companion apps and operator interfaces, cloud integration and the diagnostics a pilot team actually reads.
This is for you if
- You have working hardware, a prototype, or a hardware partner, and nothing around it yet.
- A customer pilot is scheduled and the onboarding experience does not exist.
- Your device produces data nobody can act on without an engineer in the room.
- An existing physical product needs a companion app or an operator interface.
And it is not, if
We do not do custom firmware, PCB layout, mechanical design or manufacturing. If your project needs them they are scoped separately with a specialist, agreed with you before anything is signed. We have no standing partner network and will not pretend otherwise.
Two situations we see
Neither of these is a case study. They are the two shapes this work usually arrives in.
A startup preparing a device pilot
The hardware does what it should on a bench. What is missing is everything a customer touches: getting the unit paired and provisioned, an app that makes the readings mean something, and a way for you to see what happened when a unit goes quiet in week three.
An enterprise connecting an existing product
The product already ships and already sells. Now it needs a companion app, an operator interface, or a path into the systems your business already runs on, without disturbing the manufacturing and firmware you are not about to change.
AI Device Integration & Pilot Engineering
One pilot-ready workflow: a device a customer can set up, a product surface they can use it through, and enough visibility for your team to run the pilot without guessing.
- 1
Assess the device and what already exists
We work against your actual hardware and your actual constraints, not a datasheet. What it can already do, what the firmware exposes, what the pilot will demand of it, and which of those gaps are software problems rather than hardware ones.
What you get
- What the device exposes today, and what a pilot would need it to
- The software gaps between here and a customer setting one up unaided
- Anything that is an embedded or electronics problem, named as such
- A written scope for the pilot workflow, and a figure
- 2
Deliver one complete pilot workflow
One path, end to end, rather than a partial version of several. A customer takes a unit out of the box, sets it up, uses it for its actual purpose, and your team can see it happening.
What you get
- Device onboarding: pairing, provisioning, and a first-run state that confirms it worked
- A companion app or operator interface built around the job, not the data model
- Cloud and backend integration, into your systems where they exist
- Pilot diagnostics: which unit, when, what it was doing, what to try
- 3
Expand and support the product
What the pilot taught you, built in. More device types, more of the workflow, the integrations the customer asked for during the trial, and the maintenance that keeps a fleet working after the pilot ends.
What you get
- Additional workflows and device variants
- AI features where they change what the product can do
- Integrations into the systems the customer already uses
- Ongoing engineering and maintenance on the software layer
How we work with your hardware team
We own the software: onboarding, the companion app or operator interface, the cloud integration, and the diagnostics your pilot team reads. Firmware, electronics, mechanical and manufacturing stay with your hardware team, or with a specialist scoped in alongside us and agreed with you first. On-device work depends on what your hardware actually supports, so we tell you what is possible after we have seen it rather than before. Where an existing model or API gives the product something it could not do otherwise, we integrate it; custom model research is a different discipline and a different engagement.
How the engagement runs
It starts with an assessment against the real device. You get the findings whether or not you continue with us. From there we build one complete pilot workflow rather than a partial version of several, because a pilot that half works teaches you nothing. A working pilot is not the same as manufacturing readiness, and we will not let a proposal imply it is.
What does a project cost?
We do not publish a number, because a quote written before anyone has looked at your problem is a guess dressed up as a price. We scope first, as a small paid piece of work, and that produces a fixed shape and a real figure. If the scope shows the project is not worth doing, you have spent a fraction of a build to find that out.
How long will it take?
Ask us after the scope, not before. Anyone quoting a duration off a first call is quoting a hope. What we can tell you up front is the shape: releases land continuously against a preview environment you can open, so you are never waiting months to see whether it is going the right way.
Do you work fixed price or time and materials?
Both, depending on what the work actually is. A defined release with an agreed scope can be fixed. Ongoing engineering against a moving roadmap cannot honestly be, and anyone who fixes it is pricing in the risk and charging you for it. We will tell you which one your project is.
We are early and pre-funding. Are we too small?
Possibly, and we will say so. If you are still testing whether anyone wants this, a full build is an expensive way to find out. Tell us where you are and we will tell you what would answer the question faster, even when the answer is not us.
Can you work with our existing team and codebase?
Yes, and most of our work is exactly that. We have joined codebases whose original authors had left and worked alongside in-house teams who needed a discipline they did not have, usually mobile or front end. We read before we rewrite.
Start the conversation
Tell us what you need to ship. You will get a straight answer on whether this is the right engagement for it.
The others
- Build a productA working release in your customers’ hands, design included.
- Fractional CTOSenior technical leadership without the full-time hire.
- Modernise existing softwareReplace what holds the roadmap back while the rest keeps running.
- Ongoing engineeringA senior team on your roadmap, release after release.