The problem
We were invited to tender for a public sector contract to redesign a lease extension calculator and lease length checker. The organisation already had both tools, but they had been built separately and operated as two disconnected services. No shared data between them. No analytics. No APIs. No way to plug them into other government systems or plan for future digital transformation.
The real issue was what this meant for users. Leaseholders across the UK were leaving it too late to extend their leases, and by the time they checked, fees had already climbed significantly. But the organisation had no way of knowing this was happening. Nobody could tell when people were checking, how far they got through the process, or how many were arriving when it was already too late. Without any tracking or analytics, there was no way to measure whether the service was meeting user needs, identify where people were dropping off, or prioritise early outreach to leaseholders most at risk.
What we built
We built this as part of a competitive tender for a public sector contract worth around £160k. Rather than submitting a written proposal, we built the thing. A fully working prototype that showed how the digital service should actually work.
Two people. Two days. Here is what we delivered.
A unified, user-centred digital service. We brought the lease length checker and extension calculator together into one joined-up user journey. Instead of bouncing between two disconnected tools, a user could check their lease, understand what it meant, and get a quote without leaving the service. This is what the GDS Service Standard means when it talks about solving a whole problem for users.
API-first architecture built for interoperability. Every function was exposed through clean, documented open APIs because we knew where government digital services are heading. We had attended GDS events where the message was clear: new public sector services need open APIs so they can integrate with each other, in line with the Technology Code of Practice. The planned progressive web app, CRM tools, other government platforms... the architecture was ready for all of it from day one.
A real-time analytics dashboard. This was arguably the most important part, because it gave operational teams something they had never had before: actual insight into user behaviour. The GDS Service Standard requires teams to identify metrics and KPIs to measure service performance. Our dashboard did exactly that.
It was designed to track leases checked (including peak usage times), email summary completion rates, average time to complete the journey, and the lease term mix. That last one was the real headline feature. It would allow the team to see what proportion of searches were coming from people with short leases remaining, giving them a single metric to forecast demand for extensions and prioritise outreach to those most at risk of paying higher fees.
The dashboard also surfaced operational data: manual reviews in the queue, automation rates, and customer satisfaction scores. The vision was to give leadership a single screen covering both user behaviour and service performance.
An engagement funnel tracking drop-off. The prototype included a step-by-step engagement funnel showing where users were falling out of the journey, from initial search through to receiving an email summary. Making drop-off visible for the first time would allow design improvements to be targeted where they would actually make a difference. This kind of data-driven iteration is exactly what the GDS Service Standard expects from teams running accessible digital services.
