We design, build and maintain software, embedded systems and infrastructure, and we carry the result rather than supplying people to work on it. What has changed is what a finished product now obliges its owner to do. Two European regimes now land on whoever places a digital product on the market, and the first reporting duties applied from September 2026.
When Cyber Resilience Act reporting starts, including for products already on the market. Actively exploited vulnerabilities, inside 24 hours.
When the rest of it applies: conformity assessment, technical documentation, CE marking.
Or the product lifetime, whichever is shorter. That is how long vulnerabilities must be handled.
Custom development
Building tailored software and systems.
Embedded and connected systems
Where the product itself falls in scope.
Infrastructure modernisation
Upgrading platforms for scale and security.
Security by design
No longer a preference, now a requirement.
Vulnerability handling
For the product lifetime, or five years.
Technical documentation
The file a conformity assessment will want.
Maintenance and support
From deployment onward, not from handover.
Built to be kept
Systems handed over with documentation your own engineers can work from, rather than with a dependency on the people who wrote them. The measure is whether your team can change it six months after we leave.
Compliance built in
Security requirements, vulnerability handling and the documentation trail designed into the build rather than retrofitted before an audit. Retrofitting a product that already shipped is the expensive version of this.
Obligations settled in the contract
Who handles vulnerabilities, who holds the technical file and who reports inside twenty-four hours, agreed at the start. These questions have answers now whether or not anyone wrote them down.
One build team
The people who designed it are the people who build it and the people who maintain it. Handover between three different suppliers is where most of the cost of a system appears, long after the invoice for building it.
With us | In-house | Offshore build | Product vendor | |
|---|---|---|---|---|
| What you buy | A working system, built to spec | Nothing, you have the capability | Capacity, at a lower rate | Their product, configured |
| Who owns the code | You do, from day one | You do, obviously | You do, on paper | They do, and always will |
| Compliance duties | Yours, but designed for by us | Yours, entirely | Yours, and harder to evidence | Theirs, as manufacturer |
| Maintenance | Same team, if you want it | Yours, and it competes for time | A separate contract, usually | Included, on their roadmap |
| Fits when | The need is specific to you | The team exists and is available | The spec is stable and detailed | A standard product fits the need |
If a product exists that does eighty per cent of it, we will tell you to buy that instead.
Scope and architecture
What it has to do, what it has to comply with, and which decisions will be expensive to reverse later.
Build in increments
Working software you can accept in stages, with security requirements treated as part of the build.
Documentation and conformity
The technical file assembled as the work happens rather than reconstructed for an assessment afterwards.
Maintenance and reporting
Handled for the agreed period, with a route for reporting that meets the deadlines rather than meeting them by chance. Where you keep maintenance in-house, we hand over the process and the file rather than only the code.
When Cyber Resilience Act reporting starts, including for products already on the market. Actively exploited vulnerabilities, inside 24 hours.
When the rest of it applies: conformity assessment, technical documentation, CE marking.
Or the product lifetime, whichever is shorter. That is how long vulnerabilities must be handled.
Business applications
Custom software where no product fits, and integration between the ones that nearly do.
Embedded software
Firmware and device software, squarely inside the new product cybersecurity rules.
Industrial systems
Control and automation, where safety requirements and security requirements now meet.
Platform modernisation
Migrations where the risk sits in the cutover rather than in writing the new thing.
Data platforms and pipelines
Pipelines and reporting layers, usually the easiest scope to define properly.
Integration and interfaces
The connective work that nobody scopes and everybody discovers.
Automotive and manufacturing
Connected products where the cybersecurity rules now attach to the device itself.
Energy and utilities
Operational technology, where a security requirement and a safety requirement can conflict.
Financial services
Where a build engagement also sits inside the ICT third-party question.
Tell us what has to exist and what it has to comply with. You get a view of what it takes to build, and of which obligations attach to it once it exists.
Driving business success with expert solutions.
.avif)
