Services / Care / Continuous improvement

Software that gets better with age

Most products decay quietly between big projects, a form nobody ever fixed, a page that grew slower, a report the team works around every week. A standing block of improvement hours each month stops that, and costs a fraction of the rebuild it prevents.

Start the conversation →See the technology

Why it matters

The cost is the wait

The usual pattern is a cycle: spend a lot of money on a build, launch it, then freeze. For the next three years nothing changes except the world around it. The team develops workarounds for the awkward bits. Small annoyances accumulate, none of them ever big enough to justify a quotation on their own. Eventually the whole thing is declared outdated and replaced at full cost, and the replacement begins the same cycle, because nothing structural has changed about how the software is looked after.

The alternative is unglamorous and considerably cheaper. A defined block of hours every month, prioritised by you, spent on the small things: the field that should have been optional, the report that needs one more column, the page that has crept up to four seconds, the copy that confuses people at the point of purchase. Individually trivial. Cumulatively, the difference between a product that ages well and one that gets quietly abandoned.

What we will not do is pretend this is unlimited. A monthly allowance is a defined number of hours, not a standing invitation to build a second product for free, and any supplier who implies otherwise is either padding the fee or planning to disappoint you. Anything substantial gets scoped and quoted like the project it is. What the allowance guarantees is that the small stuff, which never wins an argument for budget, actually gets done.

What you actually get

Built to be trusted

How the improvement allowance works in practice, and what stops it becoming a vague monthly fee for nothing in particular.

A defined block of hours, prioritised by you

An agreed number each month, spent on whatever sits at the top of your list. Unused hours roll over within an agreed cap, so a quiet month becomes capacity for a busy one instead of money you simply lost.

A backlog you can see and reorder

Everything anyone has ever wished the system did, in one visible list with an effort estimate against each item. You reorder it; we advise on sequencing and flag where two cheap items done together cost less than either alone.

Evidence, not just opinion

Analytics, session recordings and your own support tickets point at where people struggle. The loudest request is not always the most valuable one, and the data usually surfaces problems nobody thought to complain about.

Performance and accessibility kept from drifting

Sites get slower and less usable one small addition at a time. Part of the allowance goes on holding the line: speed budgets, keyboard and screen-reader checks, and the accumulated cruft nobody would ever raise a ticket about.

Shipped in small, reversible pieces

Improvements go out continuously rather than as a quarterly bundle, each one tested and individually undoable. Small changes are easier to judge, easier to roll back, and let you see progress every few weeks rather than every quarter.

Your team handed the simple changes

Text, images, prices, opening hours and blog posts should never cost developer hours. We put those behind an editor your staff can use and train them on it, which frees the allowance for work that genuinely needs an engineer.

Where it earns its keep

Same pattern, different desks

The theme is always the same: a small, well-chosen change to something that thousands of people already use.

01 · Recruitment & professional services

The application form losing people at step three

The problem: Traffic to the vacancies page is healthy, applications are not. Nobody has looked at the form since launch, it asks for a CV upload before it asks anything else, and it fails silently on the file types most people actually have on their phone.
What we build: Session recordings identified the exact abandonment point. The allowance went on reordering the fields, accepting the formats candidates really use, saving progress so a half-finished application survives an interruption, and making the whole thing work properly one-handed on a phone.
What changes: A change measured in hours rather than weeks, applied to a form every single candidate has to pass through, and a pattern to repeat on the next form in the list.

02 · Hospitality & leisure

Seasonal changes that should not need a developer

The problem: Menus change, opening hours shift for bank holidays, and the Christmas offer needs to go live on a Tuesday evening. Every one of these is currently an email to a supplier, a delay of several days, and an invoice for fifteen minutes of work.
What we build: The recurring requests were moved into an editor the manager controls, with the booking flow tidied at the same time: fewer steps, clearer availability, and a confirmation email that actually contains the details people ring up to ask about.
What changes: Routine changes happen in minutes at no cost, and the monthly hours are freed for improvements that make a real difference rather than for typing in a new menu.

03 · B2B SaaS

The first ten minutes that decide the account

The problem: Trials convert poorly and support tickets cluster around the same three points in setup. Every one of them is a known annoyance the team has grown used to, and none is big enough on its own to displace roadmap work.
What we build: The improvement allowance is aimed at exactly this class of problem: better empty states, an import that explains what went wrong rather than failing silently, clearer errors on the integration step, and sensible defaults so a new account is useful before it is configured.
What changes: Steady monthly progress on the friction that quietly costs the most, without the roadmap ever having to formally admit that these items exist.

The technology

The tools behind it, named

Improvement work touches everything, so the toolkit is broad. The constant is that changes ship safely and small, and that your own team can handle whatever should not need us.

6 layers · 25 technologies

Deciding what is actually worth doing

Behaviour, not opinion. Where people hesitate, where they abandon, and which pages carry the most traffic per improvement hour spent.

PostHog
Plausible
Hotjar
Google Analytics

Where the month's work is planned

A visible backlog with estimates, so priorities are your decision and progress is something you can check rather than take on trust.

Linear
Jira
GitHub
Notion

Changing things without breaking them

Automated tests around the journeys that matter, so a small improvement in one place cannot quietly damage something else.

Vitest
Cypress
Storybook
GitHub Actions

Shipping without an event

Preview builds for every change, one-step deployment, and a rollback that works, so releasing an improvement is routine rather than a scheduled evening.

Vercel
Cloudflare
Netlify
Docker

So your team can make its own changes

Content, copy and imagery under your control. Every change your staff can make themselves is an hour of the allowance spent on something better.

Sanity
Payload CMS
Storyblok
Contentful
WordPress

Design and front-end polish

A shared component set means a refinement made once appears everywhere, instead of being reapplied by hand across twelve pages.

Figma
Tailwind CSS
React
Next.js

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

The first month builds the list. After that it is a simple monthly rhythm: you prioritise, we ship, we report.

We start with a backlog, not an empty month

An audit of the product, a read through your support tickets, and half an hour each with the people who use it daily. Staff who have stopped complaining about something are usually sitting on the most valuable item on the list.

You rank it, we estimate it

Every item gets an honest hours figure, including the ones where the honest figure is uncomfortable. You decide the order; we advise on dependencies and on where doing two things together is cheaper than doing either alone.

We work in small increments

Changes ship through the month rather than landing in one release. Each is tested, deployed and individually reversible, so you see movement every couple of weeks and nothing ever accumulates into a risky bundle.

We measure the ones that claim a number

If an improvement was justified by a conversion figure or a load time, we check it afterwards and tell you what happened, including when it made no measurable difference, which is genuinely useful information about where not to spend next month.

Monthly report and re-prioritisation

What shipped, what it cost in hours, what rolled over, and what we would suggest next. Half an hour on a call, and the list is reordered around whatever has changed in your business since.

Quarterly, we step back

Some things cannot be fixed with improvement hours, a data model fighting the way you now work, a platform reaching end of life. We would rather say so and scope it properly than keep spending your allowance on symptoms.

Before you commit

The questions worth asking

What counts as an improvement rather than a new project?

The rough line is whether it fits inside the month's hours without redesigning how your data is structured or adding a significant new dependency. Reordering a form, adding a column to a report, tuning a slow page, changing a workflow step: improvements. A new customer portal, a payment provider migration, an integration with a system you have never connected to: projects, scoped and quoted separately. We tell you which side something falls on before starting, not after.

What happens if we do not use the hours?

They roll over, up to a cap agreed at the start, typically a couple of months' worth, because unlimited accrual eventually creates an obligation neither side can schedule sensibly. If you consistently under-use the allowance, we will suggest reducing it rather than quietly banking the difference.

Can we spend them on something other than code?

Yes, and some of the highest-value months are not development at all. Copy rewrites, SEO fixes, an analytics review, training a member of staff to run the CMS, a second opinion on a quotation from another supplier. It is your allowance and the goal is the product improving, not the hours being billed against a particular activity.

Who decides what gets done?

You do. We bring evidence and recommendations (what the data suggests, what will get harder if it is left, what is cheap to do while we are already in that area) and then you rank the list. We will argue our case when we think something is being deprioritised at real cost, but it is your product and your money.

Will this mean we never need a rebuild?

It usually delays one by years, and it removes the most common cause. Steady neglect. But it is not a permanent stay of execution, and we would be lying if we said otherwise. Frameworks reach end of life, business models change, and sometimes what you now need is genuinely a different shape of software. When we can see that coming, you will hear it early enough to budget for it rather than as a surprise.

Could our own team do some of this?

We would encourage it. Anything routine (content, images, prices, opening hours, blog posts), belongs with your staff, and we will set the tools up and train people so it is not a developer task. Some clients also have a capable person internally who takes on small changes with us reviewing their work. Both arrangements make your allowance go considerably further.

What would you fix if it only took an afternoon?

Send us the three things about your software that quietly annoy your team every week. We will tell you what each would take and what a sensible monthly allowance looks like.

Start the conversation →

Explore more

The rest of Ongoing Care & Support

Security & updates Always-on monitoring A real response promise Software we didn't build ← All of Care