Ongoing maintenance and support

The short version

Custom software is not a thing you buy once. It sits on a stack that keeps moving underneath it — framework releases, security patches, a payment provider changing an API, a browser changing a default. Nothing about your business changed, and yet the software needs attention. The question is not whether that work happens, but who does it and how it is paid for.

• The Anvil Care Plan is a flat monthly fee covering hosting, monitoring, patching, bug fixes and a block of improvement hours.

• If something we built breaks, fixing it is not a change order. That line is the point of the plan.

• Plans are sized to the system we are looking after, and quoted alongside the build so there is no surprise after launch.

• You can leave. You already own the code, the repository and the accounts — there is nothing to reclaim.

• If your system uses AI, keeping those features accurate as the models change underneath them is included.

What actually breaks after launch is rarely the software

Rarely the thing you were worried about. Software that worked on Friday does not spontaneously stop working on Monday; what changes is the world around it.

What genuinely causes post-launch work:

• Security advisories in dependencies — several a month across a normal stack, most trivial, occasionally not.

• Third-party APIs — a payment processor, a shipping provider or an email platform deprecating what you were using.

• Certificates and credentials expiring, which never happens at a convenient hour.

• Data growth — a query that was instant at ten thousand rows and is not at two million.

• Real usage finding the edge cases no test suite anticipated, usually in the first month.

• Your own business changing — a new price band, a new rule, a new person who needs a different view.

The pattern is that most months need very little and one month a year needs real attention. That is exactly the shape a flat fee handles well and hourly billing handles badly, because hourly billing makes you hesitate to report things.

What the Care Plan covers

Everything needed to keep what we built running, patched and improving, for a flat monthly fee with no per-ticket surprises:

• Hosting and daily backups — managed, monitored hosting with off-site backups and a restore process we have actually tested.

• Uptime monitoring — we watch it around the clock, and usually know before you do.

• Security patching — framework, dependency and server updates applied on a regular cadence rather than in a panic.

• Bug fixes included — if something we built breaks, fixing it is not a change order.

• Monthly improvement hours — a standing block for the small features and tweaks that otherwise pile up for a year.

• Priority response — one business day on normal requests, same day on anything that stops work.

Those improvement hours matter more than they look. Most small businesses have a list of five small changes that would each save someone twenty minutes a week, and none of them are ever individually worth raising a quote for. A standing block is how that list gets done instead of getting longer.

The line between a bug and a change

This is the question that decides whether a support arrangement is worth having, so here is the plain answer: if the software does not do what we agreed it would do, that is ours to fix and it is included. If you want it to do something new, that is a change.

Response times mean something specific here. One business day on a normal request is when a human replies with what is happening and when it will be done, not an automated acknowledgment. Same day on anything that stops work means exactly that — if your team cannot invoice, book or sell, it goes to the top of the list regardless of what else is running.

Borderline cases get decided in your favor and mentioned, rather than argued about. An arrangement where every request starts a negotiation is one where people stop reporting problems, and unreported problems are how small faults become expensive ones.

What it costs

Plans are sized to the system being looked after — how much of it there is, how much traffic it carries, how many integrations have to be kept alive, and how quickly you need answering when something stops. Most small business applications land in a predictable monthly band.

It is quoted with the build, before you commit to the build, so the total cost of ownership is on the table while you are still deciding. Being told the monthly figure after launch is a bad surprise and an avoidable one.

Worth comparing it against the alternatives honestly. A part-time developer costs several times a Care Plan and is unavailable the week you need them. Calling someone new each time means paying for a stranger to learn your system before they can help, every single time.

If you would rather run it yourself

That is a perfectly good answer and we will hand it over properly. You get the code, the documentation and the accounts, and we will walk your developer or your IT provider through the deployment rather than emailing a zip file and wishing them luck.

What we would ask you to arrange, whoever does it:

• Somebody watching for security advisories in the dependencies, and applying them.

• Backups that are tested by restoring them, not merely configured.

• Uptime monitoring that alerts a person who can act.

• A staging environment, so changes are not made directly on the live system.

• Someone reachable when it breaks, with the access to fix it.

We are still available hourly afterwards if you need us. Running your own system for a year and calling when something unusual happens is a perfectly legitimate way to do it.

Systems with AI features need more attention

Systems with AI features need more attention than conventional software, and the reason is unusual: the thing underneath you changes without you deploying anything. A provider updates a model and a prompt that behaved perfectly for six months starts formatting its output slightly differently, or becomes cautious about something it used to answer.

On the Care Plan that is covered. We keep a set of known-good examples for each AI feature, re-check them against the current model on a schedule, and adjust when the behavior drifts. Providers also deprecate model versions on their own timetable, so migrating to a supported one before the deadline is part of the plan rather than an emergency.

One piece of practical advice: if we are quoting you a project, ask what the Care Plan for it would cost while you are still deciding whether to build at all. It is a fairer basis for the decision, and it is a number you should have early.

We also take on systems somebody else built, after a short review of what we would be inheriting — what it runs on and who built it is enough to start that conversation.