How we work
Scoped, signed, and yours to own.
A new firm earns trust through method, not a wall of logos. So the way 1722 works is deliberately legible: a written statement of work, named deliverables, clear acceptance, and a defined end. You always know what you are buying, who is doing it, and what you will be left holding.
The method
Four stages, artefacts at each.
The same shape whether the work is a warehouse go-live, a circuit board, or an architecture review.
- 01
Understand & scope
A short discovery call, then a written statement of work. We map the problem to your existing systems, name the deliverables, and agree how we will know it is done — before any work starts.
- 02
Design & engineer
The actual engineering, done by the senior engineer: configuration, integration, schematic and firmware, architecture and design. Decisions are documented as we go, not reconstructed at the end.
- 03
Deliver, integrate & commission
Into your systems, your floor, your estate — tested, commissioned and proven against the acceptance criteria we agreed. No hand-wave “done”.
- 04
Handover & support
Documentation and training so your team owns it. Optional follow-on support or a retainer if you want ongoing senior capacity — but continuity, not dependence, is the goal.
Commercial model
You pay for the engineering.
One consistent principle: you are buying senior engineering expertise and time, tied to a written scope. Pick the shape that fits the work.
| Day rate | A senior engineer for defined days — reviews, advisory, focused hands-on work. |
|---|---|
| Time & materials | Open-scope engineering billed for hours actually worked, with regular checkpoints. |
| Retainer | Reserved senior capacity across a period — escalation, review, roadmap steering. |
| Fixed-scope package | A bounded engagement — assessment, design or commissioning — at a fixed scope and price. |
Not this — no published price list, no fixed monthly subscription (that is a product), and no fixed-price product build to a brief (that is an agency). Just engineering time against a signed scope.
What you keep
Deliverables you own — always.
- A signed statement of work with scope, deliverables and acceptance
- The engineering output — configuration, schematics, firmware source, designs, architecture packs
- The decisions — documented rationale you can act on and defend
- Handover documentation and training so your team can run it
- Full IP ownership of commissioned work — you commission it, we deliver it, you own it
Start with a conversation.
Tell us the problem. We will tell you honestly whether it is a fit, and how we would scope and price it.
FAQ
How we work, answered.
Why don’t you publish prices?
Because honest pricing depends on scope, and scope depends on your systems and your problem. Every serious engineering engagement is quoted after a short discovery call — not read off a menu. What we can tell you up front is the commercial model and exactly what you will receive.
What is in a statement of work?
The problem, the scope, the named deliverables, the acceptance criteria (how we both know it is done), the commercial basis, and the boundaries — what is explicitly out of scope. It is short, plain, and signed before work starts.
What happens at handover?
You get the deliverables and the documentation to run them, plus training for your team. We do not disappear, and we do not make you dependent on us: continuity is a deliverable, not an afterthought. Follow-on support is available if you want it, never required.
Can you start small?
Yes — a bounded first engagement (a review, an assessment, a discrete work package) is often the right way to start. It earns trust both ways before anything larger, and it stands on its own if we go no further.
Do you work remotely, on-site, or both?
Both. Much of the engineering is done remotely; discovery, commissioning and go-live often want time on the floor or with your team. We agree the mix as part of scoping.