Direct answer
Maintenance is decided before launch, not after the first incident. Launching software does not finish the work: hosting keeps running, dependencies keep ageing, providers change their interfaces and users find cases nobody tested. Someone has to own that, and you should know who, what they will do and how you will pay for it before you go live.
Maintenance work is not one thing. It is a set of routine tasks (updates, monitoring, backups) plus a stream of small fixes and requests. Being clear about the difference between that and new development is what keeps both sides comfortable.
What maintenance covers
Ask any provider, including us, to list what is included in words rather than a label. A useful list usually falls into these groups.
- Keeping the software running: hosting, certificates, domain renewals, scheduled jobs
- Keeping it current: framework and dependency updates, security patches
- Keeping it watched: monitoring, error tracking, alerting and someone who reads them
- Keeping it recoverable: backups and, importantly, tested restores
- Keeping it working: fixing defects in what was delivered
- Keeping it useful: small changes and adjustments, which is where scoping matters most
Updates and security
Software that is never updated becomes less safe and harder to change each month. Regular updates keep each step small; skipped updates pile up into a large, risky one. Ask how updates are tested before they reach production, and how they can be undone if something breaks.
Also ask who decides when a security patch is urgent enough to interrupt other work, and how you are told. Make sure the answer does not depend on one person's attention.
Fixes versus new work
This is the most common source of disagreement. A fix restores behaviour that was agreed and is not working. New work adds or changes behaviour. The written scope and the acceptance criteria from the build are your reference: if the delivered feature does not match them, it is a fix; if you now want something different, it is new work.
Some requests are honestly in between, such as a small change that follows a new business rule. Agree in advance how those are handled: who classifies them, who approves, and how they are estimated. LATYNEX agrees one scope and one price in writing before work starts, and the same approach suits small changes: agree the scope first. For how larger changes are priced in general, read web application development cost.
Monitoring
Monitoring is only useful if someone is looking. Decide what is watched (availability, errors, failed jobs, expiring certificates), where alerts go, and who acts on them. An alert that lands in an unread inbox is not monitoring. Also decide what you can see yourself, such as a simple status view, so you are not dependent on being told.
Backups
Agree what is backed up, how often, where the copies are kept and who can access them. Then agree a periodic restore test into a separate environment. Ownership matters here too: backups should sit in an account you control, or you must know how to get them. The software handover checklist covers the initial restore check.
Response expectations
Be specific about what you need. Which problems are urgent because they stop the business, and which can wait for the next working day? Who do you contact, through which channel, and when will you hear back? LATYNEX has no published support terms or service levels, and it would be wrong to invent any here. Whatever you agree with any provider, get the response expectations, working hours and time zone written down, rather than assumed.
Who does it
There are three real options: the team that built it, another vendor, or your own staff. The builder knows the code best but is not always the cheapest or the most available. An internal person knows the business but can be a single point of failure. A different vendor needs a clean handover to be effective. Whatever you choose, make sure someone else could take over: documentation, runbooks and accounts in your name matter more than who is chosen today.
How LATYNEX approaches it
The site's pricing page lists support and maintenance as hosting, updates, monitoring and small changes after launch, with no published price: it is scoped to what your application actually needs. Tell us what is running and what you want covered, and we will scope it. The starting point is web application development, and it is best raised during scoping, not after launch.
Ending an arrangement cleanly
Plan the exit on day one. Confirm that code, accounts and documentation are in your name so you can move to another provider without permission. Agree how much notice is needed, what a handover to a new team includes, and that access is removed afterwards. A maintenance arrangement you cannot leave is a warning sign; see the comparison of what to confirm in who owns the code and accounts.
Questions
Do we need maintenance if the app works fine?+
Usually yes, in some form. Working software still depends on hosting, updates, certificates and third-party services that change. The question is how much attention it needs, not whether it needs any.
Is maintenance the same as support?+
They overlap but differ. Maintenance is planned upkeep; support is responding to problems and questions. Ask a provider to describe both in words.
What does LATYNEX charge for maintenance?+
There is no published price or fixed terms. It is scoped per project based on what is running and what you want covered.
Can another company maintain software LATYNEX built?+
That is the intent of handing over code, domain and accounts in your name. A clean handover, with documentation, makes it practical.
How do we keep small change requests from becoming disputes?+
Use the original scope and acceptance criteria as the reference, and agree in advance who classifies a request as fix or new work and how new work is scoped.