Software Maintenance: The Year-Three Question to Ask First

What does year three look like?

Every vendor demo ends the same way. The system works, the dashboard is clean, everyone shakes hands. Nobody in that room is thinking about year three.

They should be. Shipping is the easy part. Ask the vendor what year three looks like and watch how specific the answer gets. A vendor who plans to stay will talk about handover documents, enhancement queues and who picks up the phone when something breaks on a Saturday. A vendor who plans to leave will talk about the warranty.

Why year three decides the investment

Custom software does not fail on launch day. It fails slowly, and usually for one of three boring reasons.

The first is drift. The business changes and the software does not. A new product line appears, a workflow gets restructured, a regulation shifts, and suddenly the system that fit perfectly at launch is asking people to work around it. Workarounds multiply quietly. We have written before about what happens next in the adoption gap and why enterprise software fails: people stop using the parts that no longer fit, then the parts that depend on those parts, and the system hollows out from the inside.

The second is staff change. The operations head who championed the build moves on. The one person who knew why the approval flow had that strange exception leaves without writing it down. On the vendor side the same thing happens: the developers who built your system rotate onto other projects, and institutional memory walks out the door unless someone deliberately kept it on paper.

The third is platform movement underneath you. Operating systems update, browsers deprecate things, third-party APIs change their contracts, security patches arrive whether you are ready or not. None of this is anyone's fault. It is simply what happens to software that is alive. A system nobody maintains does not stay the same; it decays relative to everything moving around it.

Put those three together and year three is the test. A maintained system has absorbed the drift, survived the staff changes and kept pace with its platforms. An unmaintained one is already being described in meetings as "the old system", which is the beginning of the end for any investment.

The maintenance questions to ask before signing

These questions belong in the first conversation, not the last one. Any vendor serious about staying will have sharp answers. The way we structure this at Accucia is laid out on our how we work page, and the questions below are the ones we would want a buyer to ask us.

Who actually fixes things? Not which company. Which people. Is there a named team that knows your system, or does every ticket land in a general pool where whoever is free reads your codebase for the first time? Continuity of the people matters more than the logo on the contract.

What are the response expectations, in writing? How quickly is an issue acknowledged, how is severity classified, and who decides what counts as critical? Vague commitments here become arguments later. You want the mechanics written down before anything breaks, because negotiating severity definitions during an outage is nobody's best work.

How do enhancements get scoped? Maintenance is never only defect fixing. Within months you will want a field added, a report changed, an integration extended. Ask how a change request moves from idea to estimate to delivery. Is there a queue? Who prioritises it? How is a small change distinguished from a project? A vendor without a clear answer will treat every request as a negotiation.

What state is the documentation in, and who owns it? Ask to see the documentation standard from a past project. Ask what gets handed over: architecture notes, deployment runbooks, data dictionaries, credentials inventory. Then ask the harder question: if we part ways in year four, can another competent team pick this up? Ownership terms should be agreed in writing before work starts, and documentation is part of what makes that ownership real rather than theoretical.

One aside from the delivery side of the table: the buyers who ask these questions get better systems, not just better contracts. A vendor who knows the documentation will be inspected writes better documentation from week one.

Maintenance models compared

The models differ mainly in who carries which risk and how changes flow. No model is universally right; each fits a different stage of a system's life.

1. Warranty period

How it works: The vendor fixes defects in what was delivered, for a defined window after launch.

Who carries the risk: The vendor, but only for defects against the agreed scope.

How changes are handled: New requests fall outside it entirely and need a separate agreement.

2. Annual maintenance contract (AMC)

How it works: A standing agreement covering defect fixes, patches and updates for the year.

Who carries the risk: Shared. The vendor commits to upkeep, while the client commits for the term.

How changes are handled: Enhancements are usually scoped separately on top of the covered upkeep.

3. Retainer

How it works: A reserved block of team capacity each month, used for fixes and improvements alike.

Who carries the risk: The client carries utilisation risk, while the vendor commits the people.

How changes are handled: A running priority queue, reviewed regularly, with no per-request negotiation.

4. Time and material

How it works: Work is requested and delivered as needed, with effort tracked as it happens.

Who carries the risk: The client carries effort risk, while the vendor carries availability risk.

How changes are handled: Each request is scoped on its own. Flexible, but with no reserved capacity.

A warranty is not a maintenance plan, and this is the single most common confusion in these conversations. A warranty protects you against the vendor's mistakes. Maintenance protects you against time. The deeper comparison, including how to choose between these for your situation, is in our guide to choosing the right software maintenance and support model.

Signals a vendor plans to stay

You cannot verify a promise, but you can verify a track record.

The strongest signal is simple: does the vendor have client relationships older than its marketing claims? Partnerships past year seven exist and they are checkable. Our own relationship with Utech Waterproofing has run past year seven, through multiple phases of their system's life. Early on, producing a quote took days because of the number of variables involved; the system we built and have maintained since brought that from days to minutes, and it has kept working because someone has kept it working. That last clause is the part buyers underweight.

Other signals worth checking. Ask to speak to a client from several years ago, not last quarter's reference. Ask what proportion of the vendor's revenue comes from clients in their third year or later; a vendor built on new logos alone has no structural reason to invest in your year three. Look at how openly they operate: team, process, location. We state our Pune headquarters openly and publish how we handle security, ownership and continuity on our trust page, because a vendor asking for a multi-year relationship should be easy to inspect.

And ask about the boring artifacts: runbooks, handover notes, update logs from live systems. Vendors who stay accumulate these naturally. Vendors who leave never need them.

Accucia's view

The build is the smallest part of a custom software investment, and we say that as a company that has been building since 2018, with software projects delivered since 2018 across government and enterprise clients. The decision that separates systems that compound from systems that rot is made before the first line of code: who maintains this, under what model, with what documentation, answerable to whom. Buyers who insist on specific answers to the year-three question get systems that are still earning in year seven. We know because we are still maintaining some of them.

Want to pressure-test a vendor conversation or a maintenance plan you have been offered? Message us on WhatsApp at https://wa.link/1bwdd2 and we will give you a straight read.

FAQ

What do software maintenance services actually include?

Maintenance covers defect fixes, security patches, platform and dependency updates, performance monitoring and small enhancements that keep a system aligned with the business. The exact scope depends on the model chosen: a warranty covers only defects, an AMC covers agreed upkeep, and a retainer reserves capacity for fixes and improvements together.

How is a warranty different from a maintenance contract?

A warranty obliges the vendor to fix defects in what was delivered, for a limited window after launch. A maintenance contract covers the ongoing work of keeping a system healthy as platforms update and the business changes. A warranty protects against the vendor's mistakes; maintenance protects the system against time itself.

What should I ask a vendor about maintenance before signing a build contract?

Ask who specifically fixes issues and whether that team knows your system, how response expectations and severity levels are defined in writing, how enhancement requests are scoped and prioritised, and what documentation is handed over. Also ask for references from clients several years into their relationship, not recent ones.

Why does year three matter so much for custom software?

By year three, the original champions may have moved on, the business has drifted from launch-day assumptions, and the platforms underneath have changed. A maintained system absorbs all of this. An unmaintained one accumulates workarounds until people quietly abandon it, which is how a sound investment turns into shelfware.