Understand
I need to understand an existing system
Architecture review, technical discovery, risk analysis, system mapping, and technical decision support.
Engineering for software that must survive real use.
We work on new systems, inherited codebases, and technical decisions that need stronger evidence. The correct engagement may be a focused review, a repair, a new build, or continued engineering support.
Start with the condition you are facing.
Understand, stabilise, build, or continue, then we agree how to engage.
Stabilise
I need to stabilise or rescue software
Codebase audits, refactoring, reliability work, security remediation, performance improvement, and rebuild decisions.
Build
I need a new capability built
Custom operational systems, SaaS platforms, APIs, backends, automation, integrations, and responsible AI systems.
Continue
I need the system to keep improving
Ongoing engineering, maintenance, monitoring, technical guidance, documentation, and system evolution.
Engagement models
Discovery is a phase within an engagement, not a separate commercial product. Greenfield development is a type of work, not an engagement structure on its own.
| Model | How it works |
|---|---|
| Audit and advisory | A structured technical review of your codebase, architecture, or decision, delivered as a written report and walkthrough. For leadership that needs independent evidence before a major investment, repair, or strategic hire. |
| Fixed-scope delivery | A defined deliverable with clear boundaries: a platform, migration, launch, or specific capability added to an existing system. Milestone-based delivery. Scope is agreed in discovery; changes follow a written change-order process. |
| Embedded engineering | A dedicated technical unit working alongside your team: shipping features, owning architecture, and staying close to product decisions. For teams that need sustained engineering capacity without the overhead of building a full internal function immediately. |
| Ongoing support | Continued engineering after launch: maintenance, monitoring, documentation, and responsible system evolution. No lock-in. You retain ownership; we help the system stay understandable and operable as requirements change. |
Not sure which model fits? Start project check and we will suggest the right structure.
How we describe capability
Public case studies represent a fraction of our work. On this site we distinguish three levels of claim:
- Demonstrated publicly: custom operational software, backend/API work, privacy-aware implementation, and handover (see the BIMCOT case study).
- Available capability: services we deliver regularly; detail may not be published when work runs under NDA.
- Selective work: engagements we take when scope, data, and evidence justify them (for example large-scale ML training or mobile at scale).
Browse by topic
If you already know the capability you need, these detail pages go deeper.
Build
- Demonstrated publiclyCustom softwareSoftware built for the exact problem you have, not the nearest approximation a SaaS product offers.
- Available capabilitySaaS developmentMulti-tenant platforms designed for growth in tenancy, billing, and operations, not a demo that stops at the first paying customer.
- Demonstrated publiclyBackend & APIsThe foundation your application runs on, designed before it's coded, tested before it's shipped.
- Selective workAI & MLML and AI systems scoped for production constraints: data quality, inference cost, monitoring, and maintainability, not notebook prototypes.
Continue
- Available capabilityOngoing supportPlanned capacity for maintenance, security, and steady improvement so deferred work has a defined place in the schedule.
- Available capabilityInfrastructure & scalingReliable hosting, deployment pipelines, and observability so your software stays fast and available in defined environments.