Software engineering
Anyone can produce code quickly now. What separates an application that lasts from one that is rewritten in three years is what surrounds the code: requirements written to be executed, decisions written down, and quality checked at every commit rather than at acceptance.
The expensive part of software is never the first version.
Organisations put around thirty per cent of their IT budget into managing technical debt, and developers spend a large share of their time working around it rather than building. None of that debt was created deliberately. It accumulates through decisions nobody wrote down, requirements clarified verbally, and quality checks that were negotiable when the date got close.
So we work on the surroundings. Behaviours written in a form that executes, so the gap with the code shows by itself. Architecture decisions recorded with what was rejected and why. A small number of blocking gates, few enough that nobody switches them off under pressure. And accessibility and page weight treated as requirements from the first sprint, because since June 2025 the European directive makes the first one a legal duty rather than a preference.
What we do
Four workstreams, from the first requirement to the tenth year of service.
Design and build
Web, mobile and cloud-native applications, with the interface designed with the people who will use it. Microservices where two rhythms genuinely differ, and a single deployable where they do not.
the architecture answers a constraint, or it is not adopted
- Web, mobile and cloud-native applications
- A boundary per domain, when the rhythms differ
- Design system and journeys tested with real users
Hold the quality line
A small number of blocking gates at commit time: behaviour coverage, dependency vulnerabilities, automatic accessibility violations and a page weight budget. Few enough that none of them gets switched off.
an assistant proposes, a named engineer answers for it
- One test per behaviour, that fails without it
- Accessibility verified at every commit
- Generated code reviewed by a named owner
Audit and locate the debt
Code, security and dependency audits that produce a map rather than a score. What matters is not how much debt exists, it is whether it sits where the business asks for the most change.
debt is arbitrated with an estimate next to it
- Debt located file by file, not averaged
- Crossed with the change history
- An estimate in front of each remediation
Sustain and evolve
Corrective and evolutionary maintenance on the same chain that built the application, with accessibility and weight measured on every release. A product that stops being measured starts drifting quietly.
eco-design measured on the journey, not claimed
- Fixes and changes on the delivery chain, not beside it
- Weight and requests budgeted, then held
- Debt tracked as a trend, published to the team
What you get
One project runs through the four deliverables below: rebuilding a customer portal. Each step states what is actually handed over, in the order it is handed over.
How we deliver
Frame
depending on the number of journeys and the state of existing requirements
- Expected behaviours, written to be executed
- Accessibility and weight requirements, quantified
- Blocking gates, few in number and owned
Build
depending on the scope and the number of integrations
- Architecture decisions written down, with what was rejected
- The first journey in production, not in a demo
- The chain that checks at every commit
Extend
depending on the pace of the business and the debt already there
- The remaining journeys, at the same standard
- Debt located, costed, arbitrated
- The internal team equipped on the same chain
Sustain
service commitment defined with you
- Fixes and changes on the same chain
- Accessibility and weight measured on every release
- Debt tracked as a trend, not as an absolute value
Augmented engineering, in partnership with Vercel
Adservio and Vercel share a simple conviction: ship fast without giving up performance or security. The partnership anchors our development practice on a modern delivery platform, from commit to production, through preview deployments and the edge.
In practice, our teams build and industrialise Next.js applications that are fast, observable and eco-designed, AI-augmented at each step: measurable time-to-market, a quick web experience, and a codebase that stays maintainable over time.
What software actually costs
Products that are still standing
Forty-two applications held to a measured standard
96% accessibility score · 42 applications
A critical application estate used daily by more than 120,000 local government staff, where an outage is noticed by the users before the monitoring, and where accessibility is a legal duty rather than a preference.
Systematic instrumentation, measurable service levels and accessibility tracked release by release rather than audited once a year, with the practice transferred to the internal teams.
A product where model accuracy is the feature
96% model accuracy · error rate 35% → 1%
Dental charting done by hand, slow and inconsistent, on a product where a wrong reading is not a defect to fix later but a clinical answer given to a practitioner.
Deep learning built into the product rather than bolted onto it, co-designed with the practitioners who use it, with accuracy measured as a delivery criterion and not as a research result.
Insights & Perspectives
Domain-driven design: principles, patterns and benefits
Ubiquitous language, bounded contexts, aggregates and event storming: when to adopt DDD, and the benefits you can reasonably expect from it.
API design: REST vs GraphQL and beyond
Your API is your contract with the outside world. REST held for twenty years, GraphQL changed the terms, and the choice is not a matter of taste.
Software architecture decisions: who should be involved?
Andrew Harmel-Law on decentralising architecture decisions: advice not permission, ADRs, and how to build the organisational trust it requires.
Build something still standing in five years
Requirements written to be executed, decisions recorded, a small number of gates that hold, and debt located rather than averaged.
Frequently asked questions
From decisions nobody wrote down and requirements clarified verbally, far more than from bad code. Around thirty per cent of IT budgets go to managing it, and none of it was created deliberately: it accumulates every time a gate becomes negotiable under deadline pressure.
Only where two parts genuinely change at different rhythms. Splitting by screen multiplies network calls on a journey that fits in one transaction, and moves complexity from the code into operations. A boundary is a cost, and it has to buy something.
In the requirements, not at acceptance. The European Accessibility Act has applied to consumer digital services since 28 June 2025, on the EN 301 549 standard which follows WCAG 2.1 level AA. Written up front it costs hours; found at acceptance it costs a rebuild.
By having very few of them. A long list of blocking checks gets disabled the first time a release is at risk, and never comes back. Four gates that always hold are worth more than twenty that hold until the first difficult week.
A named engineer, the same as for any other code. The volume produced does not change who signs. Review stops being a formality precisely because the amount of code arriving has gone up, not despite it.
No, it means budgeting weight and requests the way you budget latency. Most of the result comes from the same levers that make a page fast: fewer requests, less transferred weight, better caching. The user sees a quicker product, not a smaller one.
Framing takes 2 to 6 weeks depending on the number of journeys and the state of existing requirements, and produces the executable behaviours, the quantified accessibility and weight requirements, and the blocking gates. The first journey in production, not in a demo, follows in 4 to 10 weeks.