The short version. Custom software does not maintain itself once it goes live, and unlike a SaaS subscription, nobody maintains it for you by default. Who does that job, and on what terms, is something you choose and put in writing before launch, not something that gets sorted out the first time something breaks. If you own your code and your accounts, you keep that choice for as long as the software exists.
Who maintains custom software after launch is rarely written down anywhere, and that omission is where the trouble starts. This matters because the gap shows up at the worst possible time. A payment gateway changes its API. A WhatsApp Business API update breaks the message template your order flow depends on. A server certificate expires. None of this is rare, and none of it is optional to fix, because by the time you notice, an order has already failed or a driver report has already gone out wrong. If nobody was ever assigned to catch it, you find out about the gap exactly when it costs you the most.
What maintenance actually covers
"Maintenance" gets used loosely, so it helps to split it into what it actually is. Security patches and server updates keep the software running on infrastructure that is still supported. Bug fixes handle the small number of edge cases that only show up once real people use the system daily. Third-party changes are the ones people forget: your software talks to other services, Tally, a payment gateway, WhatsApp, a courier's tracking API, and every one of those can change its behaviour on its own schedule, whether or not you asked for it. Small adjustments, a new field on a form, a tweak to a report, sit closer to maintenance than to a full new feature.
What maintenance is not is new development. Building a new module or a new part of your operation onto the existing system is a project of its own. A maintenance arrangement that quietly gets treated as free ongoing development is unfair to whoever is doing the work, and one that never allows small changes at all is not really maintenance either. The line matters enough to ask about it directly.
Why this is not automatic, the way it is with SaaS
With a SaaS product, one vendor maintains one piece of software for every customer at once, and your subscription pays a tiny share of that cost. That is a large part of what you are actually paying for.
Custom software does not have that shared audience. It was built for your business alone, so unless a specific person or company has explicitly taken on the job of watching it, nobody is watching it. This is not a flaw in custom software. It is simply a cost that SaaS bundles for you automatically and custom software does not, and it is one more thing a fair contract has to say something about instead of leaving silent.
Who can actually do it, and when you have a real choice
In practice there are three options: the developer who built it, under some kind of ongoing arrangement; a different developer or agency you bring in later; or, once you are large enough, someone on your own payroll. All three are workable. What decides whether you genuinely get to pick is not the maintenance clause itself, it is who owns the code and the accounts underneath it. If the source code, the hosting, and the domain are in your name, any competent developer can pick up the maintenance from day one. If they are not, your only real option is whoever built it, on whatever terms they choose to offer next.
This is also why what happens if your original developer disappears and who maintains your software are really the same question asked twice. A maintenance plan that only works as long as one specific person stays reachable is not a plan, it is a hope.
The integrations are usually the part that ages fastest, and the part most worth naming specifically before you sign. If your system connects to Tally, a payment gateway, or other business tools, ask directly who is responsible for noticing when one of those changes and updating your side of the connection. This is exactly the kind of ongoing system integration and API work that either has an owner or does not. The same goes for anything that automates a manual process for you: an approval flow or a report that used to be built by hand needs someone accountable for it when the underlying steps change, which is the heart of what business process automation work actually involves once the first version is live.
The questions to ask before you sign
Before any contract is signed, get plain answers to a short list of questions. Is maintenance included in the build price, or a separate ongoing arrangement, and if separate, on what basis is it charged? What counts as maintenance versus a paid change request, in concrete terms you would recognise later? What is the realistic response time when something breaks, not the best case but the honest one? And, most importantly, if you want to leave this arrangement for someone else next year, is there anything stopping you, technically or contractually?
A developer confident in their own work answers all four without hedging. Hesitation on the last one is the clearest warning sign there is, because it usually means the real plan was to make leaving difficult rather than to make staying worthwhile.
How we handle it
We do not put ourselves in a position where you need our permission to leave. You own the source code once you have paid for it, the hosting and domain sit in your name, and your data is always yours to export. That means whoever maintains your software next, us or someone else, is your decision to make, not ours to gatekeep. If you want to talk through what an ongoing arrangement would actually look like for your system, there is no discovery call required to start that conversation. You can reach us by the contact form, by WhatsApp, or by email at syed@wilayagroup.com.
Ask the maintenance question before you sign, not after something breaks. It is a five-minute conversation now against a much longer, costlier one later.