"We paid for it, so we own it" is the assumption. Whether it is true depends entirely on what the contract says, and in the absence of a clause the default in many jurisdictions favours the developer.
What ownership should cover
A contract that handles this properly addresses four things separately:
- Custom source code written specifically for this project.
- Design assets — screens, icons, illustrations, and the editable source files, not only exported images.
- Data — everything the application stores, which should be unambiguously the client's.
- Documentation — specification, architecture notes, deployment instructions.
The clause to look for transfers ownership of custom work to the client on final payment. Two details matter: it should be on payment rather than on some later event, and it should be explicit that it includes design source files, which are frequently forgotten and awkward to obtain afterwards.
What you cannot own
Some components are licensed rather than transferred, and this is normal:
- Open-source libraries. Every modern application uses many. They come with their own licences, most of which permit commercial use freely. What matters is that the licences are compatible with your use — a list of them is a reasonable thing to request.
- Commercial components — a paid charting library, a licensed font, a purchased template. These carry licences that may be per-project, per-developer or per-deployment, and the licence needs to transfer to you or be repurchased.
- The developer's pre-existing framework code. Many agencies reuse internal tooling across projects. This is legitimate and usually beneficial, but it should be licensed to you perpetually rather than left undefined — otherwise part of your application belongs to someone else.
Stock imagery is a recurring problem. Images licensed for a mockup are sometimes not licensed for production use, and discovering this after launch is expensive. Asking where every image came from is worth the five minutes.
The handover package
The test of a handover is simple: could a competent developer who has never seen this project take it over? That requires:
- The full repository with its history, transferred to an account the client controls. The commit history matters — it is how a new developer understands why things are as they are.
- Deployment instructions detailed enough to rebuild the environment from nothing.
- Environment configuration — which settings exist, what they do, and which are secrets.
- All account credentials — hosting, domain, database, third-party services, store accounts — transferred to the client's ownership.
- Database schema and any migration scripts.
- Third-party service inventory with what each is used for and what it costs.
- Design source files.
- Known issues and deferred items, written down honestly.
That last item is worth asking for explicitly. Every project has known compromises, and a developer willing to document them is giving the client something genuinely valuable.
Verifying the handover works
The strongest verification is to have someone independent deploy the application from the handover package alone, into a fresh environment, without asking the original developer anything. If that succeeds, the handover is real.
Doing this while the relationship is still good is far easier than doing it after it has ended. It is reasonable to make a small part of the final payment contingent on it.
Escrow
Where the developer retains code — sometimes the case for platform-based or subscription arrangements — source code escrow places a copy with a third party, released to the client under defined conditions such as the developer ceasing to trade.
It costs money and adds administration, and it is proportionate mainly where the application is business-critical and the developer is small. For most small projects, straightforward ownership transfer plus a verified handover achieves more for less.
Settle before starting
- Who owns the custom code, and from when.
- Whether design source files are included.
- How pre-existing developer code is licensed.
- That data is unambiguously the client's, in an exportable form.
- What the handover package contains.
- That accounts are created in the client's name from the outset.
Related Manboo Services
- Flutter App Development for iOS and Android MVPs.
- Business Software Development for CRM, booking, inventory and workflow systems.
- Admin Panel Development for operations dashboards and backend management.
- AI API Integration when your product is ready for smart search, chat or automation.
- Request a scope review and project estimate when you are ready to plan the first version.