How we work
Working hardware early, a maintainable platform at the end
Platform programmes fail in predictable ways: certification discovered late, a build only one person can run, and a vendor tree nobody documented. We work to avoid all three.
Delivery
Four phases
Phases overlap in practice — hardening starts well before bring-up is finished — but the sequence and the exit criteria stay the same.
Scoping and architecture
We review your schematic, the vendor BSP, your peripheral list and your certification target. The output is a written scope: what has to be built, what the vendor already gives you, where the schedule risk actually sits, and what we would need from your team.
- Schematic and peripheral review
- Vendor BSP gap analysis
- Certification and security target defined
- Written scope, estimate and risk list
Bring-up
Bootloader, kernel and device tree first, then peripherals in dependency order — the things everything else needs before the things that need everything else. CI and a pinned manifest go in during week one, not at the end.
- Boot to shell, then boot to UI
- Peripherals enabled in dependency order
- CI building every change from day one
- Weekly images you can flash and try
Integration and hardening
HALs against the vendor interface, SELinux moved from permissive to enforcing, verified boot with your keys, and the OTA path built and tested before you need it. Test suites enter CI here so the failure list shrinks continuously.
- HALs implemented and VTS-clean
- SELinux enforcing, not permissive
- Verified boot and OTA proven end to end
- CTS and VTS trending in CI
Certification and handover
The suite failure list worked to zero, submission evidence assembled, and a documented platform handed over — either to your team, or into a maintenance agreement where we carry the monthly security bulletins.
- Failure list closed with root causes
- Submission evidence package
- Bring-up report and build documentation
- Optional ongoing maintenance
Engagement models
Three ways to work with us
Most customers start with a fixed-scope bring-up and move to a dedicated team once the programme grows.
Dedicated platform team
Multi-year device programmes
A named team of platform engineers working as an extension of your organisation, in your tracker and your review process. Scales up during bring-up and down into maintenance.
- Named engineers, not a rotating pool
- Your sprint cadence and tooling
- Monthly rolling commitment
Fixed-scope bring-up
A defined board, a defined deadline
A bounded engagement with an agreed deliverable — a booting board, a passing suite, a shipped HAL. Priced and scheduled against a written scope from phase one.
- Written scope and acceptance criteria
- Fixed price against fixed deliverables
- Clear change process when scope moves
Platform maintenance
Devices already in the field
We take over an existing platform: monthly security bulletin merges, kernel and Android version upgrades, regression gates, and re-certification when you take a new release.
- Monthly security patch merges
- Android and kernel version upgrades
- Re-certification support
Working with us
The parts that usually go unsaid
How we handle source, history, documentation and your team's time.
- You keep the source. Everything we write lands in your repositories, under your licence.
- Real commit messages and reviewable history — not one squashed drop at the end.
- Written bring-up reports, so the reasoning survives the engineer who had it.
- Overlap with your working hours for reviews and standups, wherever your team sits.
- NDAs and hardware handling as standard; we work under customer security requirements.