The engagement
I am the sole developer behind Valuing Care, a SaaS used by UK local authorities and NHS organisations to cost and compare care home placements. I built it from scratch in 2015 and have been the only person writing its code ever since. It is still in active use today, and still on my desk.
The marketing site lives at valuingcare.co.uk. The application itself runs at app.valuingcare.co.uk and is auth-gated behind Clerk because of who uses it and what they put into it. Public sector commissioning teams, social care finance, and adult social care leads sit behind that login deciding real placements for real people.
What the product does
Care home placements are one of the larger discretionary spends a UK local authority makes, and one of the hardest to defend without a clear costing framework. Valuing Care exists to make those decisions evidence-led: it gives commissioners and finance teams a consistent way to model the cost of a placement, compare providers, and document the reasoning behind a fee. The output is the kind of thing that has to stand up to scrutiny from internal audit, providers, families, and occasionally a tribunal.
That is the shape of the work. Build software that helps a small group of specialists do a high-stakes job more consistently, and keep the model correct as policy, costs, and the wider care sector all move underneath it.
What "ten years, sole developer" actually looks like
A solo, long-running SaaS build is mostly the unglamorous work of staying in one codebase for long enough that nothing about it surprises me anymore.
- Domain modelling. Care-home costings are not generic line items. Bed types, funding sources, top-ups, contributions, NHS-funded nursing care, Section 117 and CHC interactions: the model has to reflect how the sector actually accounts for placements, not how it would be neat to.
- Framework moves. The product has lived through the working life of the modern JavaScript ecosystem and now sits on Next.js with Clerk for auth. Each move was a deliberate decision, not a rewrite for novelty, and each one had to leave the product working on Monday morning.
- Public-sector reliability. Users are working to council and NHS timelines, not startup ones. Outages are visible, slow pages are remembered, and a wrong number on a placement is not a bug report, it is a decision someone has to undo.
- One developer, long memory. Every quirk in the data model, every reason an early decision was made, every report that someone needs at year-end: it all sits in one head. The benefit is continuity. The discipline is writing things down so it does not become a single point of failure for the client.
Why solo, why this long
Most products do not need ten years of one developer. This one does.
The domain is narrow enough that there is no off-the-shelf framework to lean on, and serious enough that the people using it cannot afford to chase a feature roadmap that is being shaped by anyone other than them. Keeping a single developer close to the users has meant the product can change shape when policy changes, without having to translate that change through three layers of project management first. When a commissioning team needs a new report by the end of the month because the regulator has moved a goalpost, the path from "we need this" to "it is live" is short.
The flipside is the obvious one. A single developer is a single dependency. A decade in, that means a codebase that is well documented, deployments that are boring, and a working understanding with the client about what happens when I am on holiday or, eventually, when this engagement ends. That is part of the job too.
What I take from it
Long solo builds teach you to design for the version of yourself who has forgotten everything. The kindest thing I can do for future-me is leave the code in a state where today's reasoning is still legible: clear module boundaries, descriptive naming, comments where the why is not obvious from the what, and a domain model that reads like the way the users actually talk about their work.
Ten years in, the product is still in active use, still shipping, and still owned end-to-end by one developer with deep context. That is the case study.
If you are running a long-running product, public sector or otherwise, and want a developer who treats it like their own, get in touch.