Infrastructure · Security · Engineering
Tell us what you need
Home / Application Engineering
Practice
We develop custom applications, APIs, integrations, and automation tools that connect your business systems and streamline operations. With application development and infrastructure managed by the same team, you get seamless integration, faster support, and a single accountable technology partner.
No ticket queue between the people who wrote it and the people who run it.
One contract, one accountable party, whoever writes the code.
Your repository from the first commit. No lock-in to us.
Under an agreed arrangement, not goodwill.
MCloud and DDMS were built by this practice.
What we build
| Capability | What it covers | What changes |
|---|---|---|
| Custom applications | Internal business applications, operational tooling, management dashboards and mobile applications, built for how your organisation actually works. | Software that fits the process, not the reverse |
| API development & integration | Building APIs, and connecting systems that were never designed to speak to each other. | Data stops being re-keyed between systems |
| Self-service portals | User-facing provisioning and management interfaces built on infrastructure APIs. | Routine requests stop reaching your engineers |
| Workflow automation | Replacing manual operational steps with automated pipelines, with the exceptions handled properly. | The work happens at 3am without anybody awake |
| CI/CD and DevOps | Build, test and deployment pipelines, infrastructure as code, environment automation. | Releases become routine rather than events |
| Identity integration | LDAP, Active Directory, SAML and single sign-on wired into applications and platforms. | One place to grant access, one place to revoke it |
| Application modernisation | Moving legacy applications onto current platforms without a rewrite where a rewrite is not justified. | Life extended without a two-year project |
Identity and privileged access implementation lives here. Reviewing an existing estate for sprawl and privilege creep is assurance work — that is on the Security Assurance side.
The proof
The strongest evidence a development practice can offer is not a case study. It is a product that other organisations pay for, built and maintained by the same team.
The managed desktop — endpoint data control, software deployment and per-user access, all driven from Active Directory. Built here, sold as a product, running in production.
Document management with full-text search, versioning, workflow and a desktop sync client. Built here, sold standalone and alongside MCloud.
Project monitoring, document workflow and operational tooling built for the group and run daily. Not demonstrations — systems people depend on.
How we work
Usually narrower than the initial description, and usually cheaper. The first meeting is mostly us asking what would happen if we built nothing.
Which systems, which APIs, what happens on failure, and what the rollback is. Written down and agreed before code.
Your repository from day one, reviewable as it goes. No reveal at the end.
Documentation, tests, a deployment pipeline and a walkthrough — so the second change is as safe as the first.
When a business system needs to talk to your infrastructure,that is a development task, not a procurement one.
For smaller builds
A fixed-price architecture review for teams who can build an application but have never sized a database, separated environments or set up an identity provider. Workload sizing, bandwidth, database hosting, access management and a scaling path.
Scope
If configuration, an existing product or a smaller change would do it, we will say so. A development practice that never recommends not building is selling hours, not outcomes.
Source in your repository, documentation as we go, and no dependency on us to deploy it. If you want to take it in-house later, that is a handover.
We staff engagements with a few people who understand the whole thing, rather than a large team who each understand a part. It is slower to start and considerably faster to finish.
What systems need to talk to each other, what the process looks like today, and what you have already tried. We will come back with a scope — or tell you it is not worth building.
An engineer replies within two business days.