How we build connected products that keep working after launch.
Firmware, apps and cloud fail at the joins and in the field. Our process is built around both: one interface contract for the whole system, and every milestone proven on your real hardware.
Four rules on every project.
Hardware first
We start from your board, chip and existing firmware, not from screens. The device decides what the app and cloud can promise.
One owner for the whole system
Firmware, protocol, app and cloud are designed by one team, so a bug never falls between two vendors.
Proven on the device
A feature is done when it works on your real unit and a real phone, not when it passes on a simulator.
Built to hand over
Code in your repository, documented decisions and a clean handover, so you're never locked in to us.
How a project moves from your hardware to your customers.
- 1STEP 1
Hardware and code review
Schematics, chip, radios, existing firmware and app reviewed. You get a written list of risks before any build starts.
- 2STEP 2
Interface contract
One versioned document for every command and data message between device, app and cloud, agreed before coding.
- 3STEP 3
Build in two-week milestones
Each milestone ends with a demo on real hardware and a short written report of what changed.
- 4STEP 4
Verify on real units
Connection, update, power and edge-case tests run on your devices and a spread of phones at every milestone.
- 5STEP 5
Release safely
Signed firmware, staged OTA rollout to a small group first, and a way back if anything goes wrong.
- 6STEP 6
Handover and support
Documentation, credentials and a walkthrough for your team, then 60 days of included bug fixes.
What we test, on every milestone.
On-device tests
Every feature checked on your real board or unit, which you ship to us at the start of the project.
Connection tests
Pairing, range, reconnection, locked phones and Bluetooth toggled off and on, on several iOS and Android models.
Update failure tests
Power and connection cut during an update on purpose, to prove the device always recovers to a working version.
Power checks
Sleep and radio behaviour measured against your battery target, with the heaviest consumers reported.
Edge cases on purpose
Low battery, lost signal, bad input, full storage and clock changes tested deliberately, not by accident.
Regression before release
The core user journeys re-run before every release, so a fix in one place doesn't break another.
Code your own engineers can trust.
- All code in your GitHub or GitLab from the first commit
- Every change reviewed by a second engineer
- A versioned protocol document shared by firmware, app and cloud
- Release notes for every firmware and app version
- Issues and progress tracked in a board you can see
- Secrets and keys kept out of the code
- Firmware and app versions kept compatible on purpose
- Architecture decisions written down, with the reason
How we work with your hardware team and partners.
You ship us hardware
A few units or dev boards at the start. We test on them throughout and return them if you need them back.
Joint debug sessions
When a problem needs both sides, we debug live with your hardware team over video.
Your partners, our interface
We work directly with your electronics or manufacturing partner and agree the interface with them early.
Your time zone
A fixed daily overlap with US and European working hours, plus written updates so you wake up to progress.
What you receive at the end.
- Source code for firmware, apps and cloud in your repositories
- Build and release instructions
- Protocol and architecture documentation
- Cloud and store accounts in your name
- Test results from the final release
- A live handover session with your team
Engineering questions hardware teams ask us.
Book a 20-min callHow do you test hardware you don't have in your office?
You send us a few units or dev boards at the start. Every milestone is tested on them, and we run joint sessions over video when your team needs to see a result.
What if our hardware changes during the project?
The interface contract is versioned. Changes are agreed in writing, quoted if they affect scope, and both sides update against the new version.
Can our engineers review your code?
Yes. Everything lives in your repository, so your team can review any change, any time.
How do you stop an update from bricking devices?
Signed firmware, a fallback version on the device, update failure tests before release, and staged rollouts that start with a small group.
What happens after handover?
60 days of included bug fixes, then an optional support plan for OS updates, OTA releases and small features. You can also take it fully in-house.