Home / How we work
How an engagement actually runs
No stage‑gate diagram with abstract nouns. This is the sequence we follow, what you get at each point, and what we put in the contract.
Engagement models
Choose the shape that fits where you are
These are not fixed packages. Most programmes start in one model and move to another as the product matures.
Build the product
We own scope, architecture and delivery from concept to production, and hand over a working product plus everything needed to keep manufacturing and improving it.
- Best when you have a product idea and no engineering team for it
- Fixed scope per phase, re‑scoped between phases
- Handover includes design files, source, builds and documentation
Dedicated team
A named team working only on your roadmap, in your repositories, your tools and your sprint rhythm, scaling with the programme.
- Best when you have a roadmap and need capacity or a missing skill
- Monthly, on a rolling term with clear notice
- You set priorities; we staff, run and report on delivery
Rescue and maintain
Take custody of software nobody can build or safely change any more, stabilise it, and put it back on a footing where it can be improved.
- Best for inherited firmware or an unsupported platform
- Starts with a fixed‑price assessment and a written report
- Ongoing maintenance with agreed response times afterwards
Add one discipline
You have firmware but no cloud, or an app but no embedded capability. We supply the missing layer and integrate with the team you already have.
- Best when one layer is holding up an otherwise healthy programme
- Scoped to the interface between us and your team
- Your engineers stay in control of the parts they own
The sequence
Six stages, in this order, every time
Understand the constraint
Before scoping anything we find the constraint that actually decides the programme — a certification date, a chipset on allocation, a protocol the estate already runs, a support team that cannot grow. Scope written without it gets rewritten later at your expense.
Agree the shape of the work
A written scope with deliverables, assumptions, dependencies on your side and the things explicitly excluded. Where uncertainty is genuinely high, we propose a short paid discovery instead of an estimate that pretends to be precise.
Design before building
Architecture, interfaces between layers, security model and update strategy, reviewed with your team. This is the cheapest point at which to disagree, and the last point before decisions become expensive to reverse.
Build in visible increments
Two‑week iterations against a shared backlog, working software at the end of each, and a demo you can attend. Your team has repository access from the first commit and can review any change we make.
Prove it, then ship it
Test evidence, a build you can reproduce, and a release checklist that is the same every time. For hardware, that includes bring‑up results and production test procedures.
Run it with you
Agreed support terms from the day of go‑live, a maintenance rhythm rather than emergencies, and documentation written so your own engineers can take over whenever you want them to.
Commercials
How we price, plainly
Time and materials
A monthly rate per named engineer, billed on actual time, with a report of what was worked on. Suits evolving scope and dedicated teams.
Fixed scope per phase
A firm price for a phase with clearly written deliverables and exclusions. Suits well‑understood work with a hard commercial deadline.
Paid discovery
A short, firm‑priced engagement that produces an architecture, a scope and a credible estimate. Suits programmes too uncertain to price honestly yet.
We will tell you when fixed price is the wrong instrument for your project. A fixed price on genuinely unknown scope is priced with a risk premium you pay for whether or not the risk occurs.
In the contract
What we commit to
These are standing terms rather than negotiating positions. They are in the agreement, not only in the proposal.
Ownership and confidentiality
- All intellectual property created for you is yours, without carve‑outs
- Source and design files live in your repositories and accounts from day one
- NDA signed before the first technical discussion
- Your project is never used as a named reference without written consent
Engineering practice
- Reviewed code, automated tests and continuous integration as standard
- Every release accompanied by test evidence and a reproducible build
- Security review covering identity, key storage, transport and updates
- Documentation written for the engineer who takes over after us
People
- Named engineers, introduced before the engagement starts
- No silent substitution; replacements are proposed and overlapped
- Direct access to the engineers doing the work, not through an account layer
- A single point of accountability for the whole programme
Communication
- A demo of working software every two weeks, open to your team
- Written status covering progress, risks and decisions needed from you
- Overlapping working hours with your team, agreed at the start
- Bad news early — a slipping date is reported when we see it, not when it arrives
Want to see this applied to your programme?
Send an outline and we will come back with the model we would recommend and why — including if it is not us.