Technology Services
Web applications, portals and integrations built to be handed over.
The problem
Every organisation has a process running on a spreadsheet that three people understand, and a portal somebody built in 2019 that nobody will touch. The cost is invisible because it is spread across everyone who works around it.
The spreadsheet is load-bearing and that is the whole problem. It works, it encodes years of institutional knowledge in formulas nobody has read, and it is maintained by people whose job description says something else. Because it works, it never becomes a project. Because it is not a project, the risk it represents never gets owned.
The abandoned portal is the other half of the same story. It was built to solve a real problem, by a supplier or a contractor, on a stack chosen for delivery speed. It has no tests, no documentation and one original author who is gone. So the organisation stops changing it and starts working around it, a parallel spreadsheet, a manual step, an email that substitutes for a workflow that broke.
The cost never appears as a line item because it is distributed. Fifteen minutes a day across forty people is a substantial number that no budget holder sees, because none of those forty people is spending enough of their own time to raise it. The visible cost only arrives with the error: a duplicate order, a missed renewal, a supplier paid twice.
Integration is where these builds usually go wrong rather than in the interface. The application ends up holding its own copy of customer or product data because integrating with the system of record was harder than importing a file, and from that moment the organisation has two truths and a reconciliation problem. That decision is nearly always made for a good short-term reason and is nearly always the thing that has to be undone later.
And then there is accessibility, which on an internal tool gets deferred and on an external portal gets discovered. A supplier or citizen portal that cannot be used with a keyboard or a screen reader does not fail quietly, it generates phone calls, which are handled by staff, which is the cost the portal was built to remove. For anything touching the public sector it is also a condition of sale rather than a quality goal.
Recognise any of these
If three or more of these are true, this page is about your estate.
What we build
Named platforms, not categories. If you run one of these, this is the conversation.
Mainstream frameworks and mainstream databases, chosen so that the pool of people who can maintain this is large and local rather than specific to whoever built it. This constrains us slightly and it is the single most important decision for the application’s second and third year. A proprietary or exotic stack transfers a maintenance monopoly to the builder, which is good for the builder.
The application reads from and writes to the systems of record rather than holding its own copy. Where a cache is genuinely required for performance, it is explicitly a cache with a defined refresh and a single source of truth behind it. The second copy of customer data is how an internal tool becomes a reconciliation problem.
Authentication goes through the identity provider you already run, so access follows your existing joiner-mover-leaver process and your existing conditional access policies. An application with its own user table is an application that will still have accounts for people who left, and it is a finding in every security review.
Built to WCAG 2.2 AA, tested with automated tooling on every change and with a keyboard and screen reader before handover. On a citizen or supplier portal this is a condition of sale in the public sector and a phone-call generator everywhere else. Retrofitting it costs several times what building it in costs, and the retrofit is usually partial.
Documentation, a runbook, a local development setup that works from a clean machine, and a walkthrough with whoever will own it, all inside the engagement rather than after it. You hold the repository from the first commit. The measure of a successful build is that somebody else can change it safely, and that is a property you have to build for deliberately.
How the engagement runs
The process as it is actually worked, with its costs measured.
VSI delivers
Workshops with the people who do the work, and a baseline of what the manual path costs.
Working software in short cycles, reviewed against real cases.
VSI delivers
Sprints demonstrated on your data, with integration to the systems of record from the first iteration.
Release with the old path still available until the numbers say otherwise.
VSI delivers
Instrumentation from day one, the deflection and error metrics the business case promised.
The backlog worked by measured value, not by who asked loudest.
VSI delivers
Usage analytics turned into a prioritised roadmap, with cycle time protected as a metric.
How it deploys
And what we need from you at each step. A timeline with no client obligations in it is a timeline that slips.
Process mapping with the people who do the work.
Build in increments, each one usable.
Accessibility audit, documentation and a walkthrough.
How this goes wrong
Published because it is only writable by somebody who has had the failure. Each of these has happened on this kind of work, and each has a specific thing that prevents it.
Return on investment
Every lever names the mechanism and how it is measured against your own baseline, captured before the work starts. That is how the return stays a number your finance team can audit rather than a promise on a slide.
A portal earns its build cost by moving transactions off phone, email and paper. We baseline the cost of the manual path, handling time, error rate, rework, and measure the portal on the share of volume it absorbs and the exceptions it kicks back.
Every status question a portal answers is a call somebody did not take. Deflection is measured in the channel data: contact volume by reason code before and after, not in an adoption slide.
Validation at the point of entry removes the downstream correction loop, the most expensive keystrokes in any process are the ones done twice. Measured as exception and rework rates in the receiving system.
The second release is where custom builds usually die. We build on maintainable stacks with test coverage as a deliverable, so the measurement is cycle time from request to production, an asset you can change is worth more than one you can only run.
Timing
Most of the value in this decision is in when, not whether. Find the row that matches your situation.
| Criterion | Verdict | Why |
|---|---|---|
| A critical process depends on a spreadsheet and one of its keepers is leaving | Now | The institutional knowledge in the formulas leaves with them, and mapping it while they are still available costs a fraction of reconstructing it after. |
| An external portal is generating support calls | Now | The calls are the cost of the portal not working, and they are being absorbed by staff rather than measured. |
| A public-sector or regulated contract requires an accessible interface | Now | This is a gate. Discovering it during evaluation means discovering it too late. |
| The process is painful but stable, and no key person is leaving | Soon | Do the process mapping anyway, it is cheap, and it frequently identifies a product that fits, which is a better outcome than a build. |
| The process changes every few months as the business finds its shape | It can wait | Building against a moving target produces something obsolete at handover. Let it settle, and keep the spreadsheet in the meantime. |
Anything a citizen touches has to meet Section 508 and WCAG 2.2 AA, and that is a condition of sale rather than a quality target, an inaccessible page is an unsellable page. Practically that means accessibility is tested on every change, evidenced in a conformance report, and validated with a keyboard and a screen reader by a person before handover. Authentication has to work with whatever identity approach the agency already runs, records retention has to be designed rather than added, and the application has to fit inside an existing authorisation boundary rather than requiring a new one. Where a requirement would need a new authorisation, we say so at the start, because that timeline usually dwarfs the build.
Objections
Questions
Occasional updates across every VSI service, new capabilities, new offerings, and what changed. No sales sequence; leaving is one reply.
Used only for these updates, see the privacy statement.
What it costs
Scoped per engagement after process mapping, which is separately priced.
Book a 20-minute assessment
