How we work

We deliver proof of concept systems, prototypes and low-volume production. That is our defined scope rather than a stage on the way to something larger, and it determines how every project is planned and run.

Engagement models

Four ways to start

Each one has a defined end point and a deliverable you can act on. None of them requires a commitment to the next stage.

You have a design and need a second opinion

Technical assessment

We review the schematic, the firmware and the test setup, and report what we would change, what we would keep, and in what order. In some cases the conclusion is that the design is sound and the problem is elsewhere.

A written review of hardware and firmware
Risks ranked by the cost of correcting them late
A recommended order of work

You need to prove feasibility

Proof of concept

A single technical question answered on the bench, normally on development kits and a wired-up board. The deliverable is the answer and the evidence supporting it.

A working demonstration, or a documented reason it is not achievable
Measurements and test data rather than an opinion
The approaches that were ruled out, and why

You need working units

Prototype and low-volume production

Custom board, firmware, enclosure fit and a first batch of assembled units. Low volume is our standard scope rather than an exception to it.

Schematic, layout, gerbers and BOM
Firmware with a field update path
Assembly and test documentation a contract manufacturer can follow

A project has stalled

Project recovery

Loss of the original engineer, a failed board revision, or a defect that cannot be reproduced. We regularly take over existing code and existing hardware.

An assessment of what can be reused
The blocking defect isolated and reproduced
A build that runs from a clean checkout before anything else changes

Process

Development process

Five stages, in this order. Technical risk is addressed in the second stage, before anything is committed to a PCB, because that is where a change of direction starts costing weeks.

Requirements
A technical call, followed by a written scope: deliverables, acceptance criteria, and what is explicitly excluded.
Risk reduction
The highest-risk element is prototyped first, on development kits or a wired-up board, before hardware is committed.
Development
Schematic, layout, firmware and tests. Progress is reported as commits, measurements and bench photographs.
Integration and validation
Boards are brought up and instrumented. Current consumption, timing and every interface are measured and recorded.
Handover
Sources, schematics, gerbers, BOM, build scripts and test fixtures are delivered, and the build is verified on a clean machine.

Project fit

What we take on

A proportion of enquiries belong with a different supplier, and establishing that in week three benefits nobody. The second list is a scope statement, not a negotiating position.

Within scope

Projects we take on

A proof of concept that has to answer a specific technical question by a date
A prototype required for demonstration, user testing or investor review
Production volumes in the tens or low hundreds
Hardware or firmware supplied without documentation
A project stalled after the loss of the original engineer
A single discipline missing from an otherwise complete team

Outside scope

Projects we decline

Programmes requiring twenty engineers within a quarter
Department staffing or long-term contractor placement
Regulated devices where we would be the legal manufacturer
Volume manufacturing, which we place with a contract manufacturer
Fixed-price delivery of requirements that are not yet defined

Handover

Deliverables you own

A project is complete when another team could continue it without us. That is the standard applied to the documentation, and the reason handover is a defined deliverable rather than a courtesy at the end.

Sources, schematics, gerbers, BOM, build scripts and test fixtures are delivered to you. Licensing terms are agreed in the scope, before development starts, rather than discovered when you want to move suppliers.

Builds are verified on a clean machine

Before handover, firmware is built from a fresh checkout on a system that has never been used for the project. A build that only works on one machine is not a deliverable.

Test fixtures are included

The equipment used to program and test units here is delivered with the design, together with the pass criteria. A contract manufacturer can run production from the fixture and the documentation alone.

Start with a technical conversation

What the product is, what is currently blocking it, and when it has to exist. That is enough for a direct answer on whether the project fits our scope and what delivering it would involve.