An app can belong to your business on paper while still depending on someone else’s login, laptop or memory. That becomes a problem when you need an urgent fix, change development partners or bring maintenance in-house.
When you work with a custom app development company, ownership needs to cover more than the finished product. You need clear rights to use and maintain the software, control of the accounts it depends on, and a repeatable way to release changes.
You don’t have to become a developer. You do need to know where the keys are, who can use them and what happens if that person is unavailable.
1. Separate legal ownership from operational control
Treat ownership as three connected questions:
- Rights: what can your business legally use, modify and share with another developer?
- Access: which repositories, accounts and credentials can your business administer?
- Continuity: could another competent team build, operate and update the app?
A contract can address rights without giving you practical access. Equally, having administrator access doesn’t establish intellectual property ownership.
Create an ownership register with a row for each important asset. Record its location, account owner, internal contact, supplier access and handover requirements. Include source code, designs, infrastructure, databases, domain names and external services.
Give someone in your business responsibility for keeping that register current. An outdated spreadsheet is a surprisingly convincing false reassurance.
2. Keep the repository within reach
The repository stores the source code and its change history. Where practical, keep it in an organisation account controlled by your business, with developers invited through individual accounts.
Check that your business can administer access, not simply view the files. Identify a primary administrator and a backup, use multi-factor authentication, and keep recovery arrangements in your organisation’s secure storage.
The repository should contain more than the application code. Ask for:
- Build and deployment configuration.
- Database migration files, which describe changes to the database structure.
- Automated tests and instructions for running them.
- Configuration examples without live passwords or API keys.
- Setup instructions and references to any separately stored assets.
A downloadable code archive is useful, but it isn’t a complete handover. It may omit history, release labels, issue discussions or dependencies held elsewhere. Check that another developer can obtain everything needed without relying on the original developer’s machine.
3. Make intellectual property rights explicit
Don’t treat payment, possession of the code and intellectual property ownership as interchangeable. Ask a UK solicitor to confirm that your agreement gives your business the rights it needs.
The agreement should distinguish between bespoke work created for you, the supplier’s pre-existing components and third-party software. Where ownership is assigned, confirm what is covered and when that assignment takes effect. Where something is licensed instead, understand the scope and conditions.
Useful questions include:
- Can another supplier modify and maintain the app?
- Are designs, documentation and build scripts covered alongside the code?
- Which components remain the developer’s property?
- Can you continue using those components after the working relationship ends?
- Are there any restrictions affecting a future sale or transfer of the product?
Aim for clear written answers. This is a legal review point, not something repository access can settle.
4. Record third-party licences and dependencies
Most apps depend on software and services your business won’t own outright. That can include open-source libraries, paid components, fonts, mapping services and AI APIs.
Ask for a dependency inventory recording the component or service, its purpose, version where relevant, licence or terms, billing owner and renewal arrangements. Flag anything that requires a separate subscription or licence for a replacement development team.
Have relevant licence obligations reviewed. Depending on the licence and how a component is used or distributed, requirements may include notices, attribution or source-code obligations. Don’t assume that “open source” means “no conditions”.
For AI features, record the provider account, model configuration, prompts, evaluation tests and workflow definitions. Document data handling and spending limits too. A workflow in a developer’s personal automation account is still a dependency, even if nobody calls it code.
5. Control the accounts that keep the app running
For mobile apps, aim to publish through an appropriate app-store account held by your business. Give developers the permissions they need rather than sharing the account owner’s login.
Record who handles store submissions, agreements, renewals and recovery. If the app already sits in a supplier’s account, investigate transfer requirements early. Eligibility, linked services and platform rules need checking before anyone promises a straightforward move.
Apply the same approach to hosting, domains, DNS, email, payments, monitoring and AI services. For each account, confirm:
- Your business controls ownership, billing and recovery details.
- Supplier access uses named users or scoped service credentials.
- A second authorised person can recover access.
- Renewal and billing notifications reach a monitored business address.
Organisations can have legitimate reasons for using supplier-managed services. If that’s your arrangement, document how access, export and transition would work, including any contractual or technical constraints.
6. Protect signing credentials and document releases
Signing credentials help establish that an app release comes from an authorised publisher. They aren’t ordinary project files, and they shouldn’t be casually emailed or committed to the repository.
Ask your developer to document the signing setup for each platform: what credentials exist, who controls them, where they are securely stored and how access can be recovered or replaced. Distinguish Android upload keys from app-signing keys where applicable. Record Apple certificate and provisioning arrangements too. Recovery options depend on the platform and configuration.
Then ask for a release runbook: instructions another qualified developer can follow. It should explain how to:
- Set up the development environment and obtain dependencies.
- Configure a test environment and access secrets securely.
- Run tests and create a release build.
- Apply database changes and deploy supporting services.
- Submit a mobile release or deploy the web app.
- Check the result and respond if something goes wrong.
Include approval responsibilities and limitations. Mobile rollback isn’t necessarily an instant return to the previous version; store processes and compatibility with backend changes need planning.
7. Test the handover before you need it
Documentation is a starting point. A rehearsal tells you whether it works.
Ask a developer who wasn’t responsible for the original setup to build the app from a clean environment and follow the runbook into a non-production environment. Record missing permissions, undocumented steps and assumptions, then resolve them.
Before signing off, confirm that your business can administer the key accounts, retrieve the code, locate licence records and arrange a release without depending on one individual.
When supplier access ends, review permissions and rotate relevant secrets through a planned process. Don’t remove accounts blindly: automated deployments may depend on them.
Good handover isn’t a farewell ritual. It’s an ongoing habit that lets you keep working with a trusted team by choice, rather than necessity.
If you’re unsure where control of your app currently sits, let’s talk through the gaps. We can help you identify what needs documenting, testing or investigating.