Define the outcome. Engineer the path.
Clear requirements, review points and practical handover.
1. Discovery and scope
We discuss users, operating conditions, interfaces, existing designs and the intended outcome. The proposal should identify deliverables, assumptions, dependencies and acceptance criteria.
2. Architecture and risk review
Hardware, firmware and software choices are considered together. Where an important assumption is unproven, a focused prototype can come before wider development.
3. Development and review
Agree a review rhythm and named decision-makers. Design reviews, version control, issue tracking and testing should match the project’s complexity. Scope changes should be documented with their delivery impact.
4. Validation and handover
Review acceptance criteria and deliver the documentation and design assets included in the engagement. Source-code access, ownership, third-party licences and production files belong in the project agreement.
Engagement models
| Model | Useful when | Agree up front |
|---|---|---|
| Discovery or prototype | Requirements or feasibility need clarification. | Questions, outputs and review criteria. |
| Defined development scope | Deliverables and interfaces are understood. | Milestones, acceptance and change handling. |
| Ongoing engineering support | An existing product needs iterative work. | Availability, priorities and review cadence. |
Production and external testing
Component sourcing, enclosure work, manufacturing files, test fixtures and specialist laboratory work may involve separate responsibilities. We identify the required parties and scope before committing to production readiness or certification outcomes.
Confidentiality
We undertake NDA-covered work. Share a non-confidential summary initially, then discuss an appropriate agreement and file-transfer method.
Request a consultation ↗What clients ask before starting
How does a project usually start?
With a conversation about the problem, the current stage and the constraints, followed by an agreed scope covering deliverables and how progress will be reviewed.
How do we stay informed during the project?
Through an agreed review rhythm and a named point of contact, so progress and obstacles are visible while there is still time to act on them.
What happens if requirements change mid-project?
Changes are expected in engineering work. They are handled by agreeing the impact on scope before proceeding, rather than absorbing them silently.
What do we get when the project ends?
The deliverables agreed in the scope, together with the documentation needed for someone else to maintain and build on the work.