Software & systems engineering
The software behind an operation, engineered properly.
Every business runs on software it did not write from scratch and software that does not yet exist to join the pieces up. 1722 configures, integrates and automates the platforms you already run, and builds the connective software — APIs, data pipelines, automation and embedded/control code — that makes those systems actually work together. Delivered directly by a senior engineer, tested, documented, and yours.
The software that makes an operation run — engineered, tested and documented, with the source and IP yours.
What we build
Five things, one engineer.
Each stands alone, or the whole set comes together on a single operation.
- 01
Systems integration & APIs
Connecting the platforms a business already runs — API design and development, webhooks, authentication and the glue code that lets two systems that were never meant to talk actually exchange data reliably.
- 02
Automation & tooling
Replacing manual, error-prone steps with engineered automation — scripts, scheduled jobs and internal tools built to be maintained, not one-off hacks that only the author understands.
- 03
Data pipelines & ETL
Moving and shaping data between systems on a schedule or an event — extraction, transformation and load logic engineered for correctness and built to be watched, not guessed at.
- 04
Embedded & control software
Firmware and control code for the hardware and control systems an operation runs on — engineered and tested to the same standard as any other production software.
- 05
WMS & warehouse systems
A specialisation of this discipline applied to warehouse operations — WMS configuration, automation integration and commissioning, and warehouse data engineering.
Warehouse systems engineering
When you need it
The moment two systems should already be talking, and are not.
| A manual step that should not exist | Someone re-keys data between systems, or runs the same export/import by hand every week. |
|---|---|
| Systems that do not share data | A WMS, an ERP, a CRM or a controller each hold part of the picture, and nothing joins them up. |
| A report that lives in someone’s head | The numbers exist somewhere, but getting them out and current takes a person, not a pipeline. |
| A build with no source of truth | A previous integration or tool was written once, never tested, and nobody wants to touch it now. |
| Hardware that needs software | A control system, instrument or embedded device needs firmware or control code engineered to run it. |
What you get
Deliverables you own.
Every engagement ships concrete artefacts your team keeps and can act on — never advice alone.
- Source code — commented, version-controlled, and yours to build on
- Automated tests — unit and integration tests run against the real systems, not stubs alone
- Documentation — architecture, configuration and how to operate and extend what was built
- Integration & deployment notes — how it connects, how it is deployed, how it fails
- Handover — a working session so your team can run and change it without us
Out of scope — off-the-shelf products and one-off marketing sites — this is bespoke systems and integration engineering.
How we engage
Scoped work, or a seat on your team.
Two entry points, the same senior engineer either way.
- —
A scoped engagement
A defined integration, pipeline or tool, written up as a statement of work with named deliverables and acceptance, priced fixed-scope or T&M.
- —
Plugging into your team
Joining an existing codebase or programme for a period — picking up a stalled integration, covering a gap, or adding senior capacity on a retainer.
Point us at the systems that should be talking.
A short discovery call, then a scoped plan.
FAQ
Software & systems engineering, answered.
What stacks and languages do you work in?
Whatever the system in front of us runs on. Recent work spans Python, C#/.NET, SQL, JavaScript/Node and C/C++ for embedded and control code, against REST/SOAP APIs, message queues and relational and time-series databases. The stack follows the platform you already run, not a house preference.
Do you build apps or websites?
No — that is a different job and a different kind of firm. This is systems and integration engineering: connecting, automating and extending the software behind an operation. If what you actually need is a customer-facing app or a marketing website built from a brief, we will say so on the discovery call.
Do you test what you build?
Yes, as standard, not as an afterthought — automated tests, integration tests against real endpoints, and a documented test record ship with the work. See software testing & QA for the discipline in depth.
Who owns the code?
You do. Every engagement is work-for-hire: the source, the tests, the documentation and the IP are yours from delivery, with nothing held back and no licence to negotiate.
Can you join an existing team or codebase?
Yes. Picking up an integration that has stalled, taking ownership of a data pipeline, or extending an existing service is a common entry point. Scope is agreed against where the code already stands, and the work is handed back documented, not left as tribal knowledge.
How is this scoped and priced?
Against a written statement of work, after a short discovery call — day-rate, time-and-materials, retainer or fixed-scope, depending on how well-defined the work already is. No published price list.
Do you cover embedded and control software as well as backend systems?
Yes. The same engineering discipline applies whether the target is a cloud API, a warehouse control system or firmware on a microcontroller — the code is engineered, tested and documented to the same standard regardless of where it runs.