What happens to your custom software after handover
Who owns the code and the access, which documentation is actually useful and how support, maintenance and evolution differ.
Delivering software is not the end of the project. What happens afterwards decides whether the tool is still in use in a year or ends up in a folder nobody knows how to touch.
Many companies hire development thinking about the handover and not about what comes next: regulatory changes, new staff, a supplier that changes an API, or a failure at eight in the morning. It is worth being clear about that part before signing.
Who owns the code and the access
The first practical question is who owns the code, the server accounts, the domain and the integrations. In many projects those credentials stay in the supplier's name. If the relationship breaks down, the company can end up with software that works but that it cannot change or migrate.
Ask the contract to state in writing what is delivered: the source code, installation documentation, credentials and access to the contracted services. And check that all of it is in the company's name.
The documentation that is actually useful
Useful documentation is not a hundred-page manual. It is what someone on the internal team needs to run the software without calling the supplier every time: how a backup is made, what to do if the connection with the ERP fails, who approves a change and where the access details are.
Ask when the documentation was last updated. If the answer is "at handover", it is already out of date.
Support, maintenance and evolution
Business software needs three different things after handover. The first is support: handling incidents and restoring the service when something breaks. The second is maintenance: updating dependencies, reviewing security and checking backups. The third is evolution: extending the software when the business changes.
These three can be contracted together or separately, but they must be written down. "We will help you" has no response time and no person responsible.
At Efiprox we treat this stage as part of the project: we support adoption, make the adjustments that appear with use and keep the service stable. If you want to see how we organise it, look at our maintenance service.
Before you sign the handover
- Source code and documentation delivered in writing.
- Accounts, domains and access in the company's name.
- An internal person who can decide on changes.
- A written response time for incidents.
- Backups tested, not just configured.
Is something eating up your time that a program could do?
Tell us what it is in one sentence. We'll call you the same working day and within 30 minutes you'll know whether it can be fixed and roughly what it would cost.
684 752 841contacto@efiprox.com