You should not assume you own the source code just because an app agency promises full responsibility. Your contract needs to establish which rights you receive and on what conditions. ScriptSector's app development FAQ says you own the source code, Figma designs and documentation in full once you meet the agreement's conditions and make the required payments. Its system development FAQ states that you own the source code, design, data and documentation produced for you. But ownership also needs practical access. Otherwise, you could still depend on the original supplier to build, deploy or update your own app.
Who owns the code when the agency promises full responsibility?
Full responsibility usually describes who handles the work. It does not, by itself, establish who owns the result. An agency might manage development and hosting while leaving your intellectual property rights unclear. Likewise, “full control of the code” tells you little unless you can retrieve it and authorize another developer to work on it.
Separate three questions: what do you own, what can you access, and what can you do without the supplier? Check each part of the product:
- Source code: Does the transfer cover the app, backend, integrations and project-specific deployment scripts?
- Repository: Is the repo held under your organization? Do you have administrator access and the full development history?
- Apple and Google: Require relevant developer accounts to be under your organization, with appropriate access granted to the supplier.
- Domains: Check the registered holder, registrar account and access to DNS settings.
- Backend and cloud services: Identify who controls billing, databases, backups and production infrastructure.
- Design: Require editable Figma files and components, not just screenshots or exported images.
- Documentation: Make sure another developer can understand how the product is built, deployed and maintained.
A repository under your account is useful evidence of access, but it does not itself transfer IP rights. The reverse is also true: an ownership clause is not enough if only the supplier can publish an update. You need both contractual rights and operational control.
What your contract needs to establish about source code ownership
Make the agreement specific enough for someone outside the project to understand the deliverables. “The client owns the app” leaves important questions open, including when ownership transfers and which components are excluded.
Ask the agreement to identify:
- The deliverables covered, including app code, backend code, design, documentation and project-specific tooling.
- The economic IP rights being assigned, including your ability to modify the product and engage another supplier.
- When the transfer takes effect and how it relates to payments and other contractual conditions.
- Any pre-existing components, libraries, fonts or third-party assets, together with their applicable licenses.
- How code, design files, data and documentation remain accessible during the project and at termination.
- What happens to partially completed work if the engagement ends early.
- The process for handover, exports, access removal and any associated handover charges.
Distinguish work created for your project from material the supplier or a third party already owned. An open-source library does not become your exclusive property because it is used in your app. You still need to understand its license and any conditions affecting use or distribution.
This is a practical purchasing checklist, not legal advice. The exact terms belong in the signed agreement; obtain legal review where appropriate. For the wider supplier discussion, use 12 questions before you hire an app developer.
An SLA without a published price: what to require in the maintenance agreement
Source code ownership does not tell you who handles an outage. Your maintenance agreement needs to define scope, responsibilities, communication and service levels, often called an SLA. ScriptSector publishes neither a maintenance price nor numerical SLA commitments. Require these details in your proposal and agreement rather than inferring them from a service description.
Separate response time from resolution time
A response may simply confirm that someone has received the issue. Resolution means the problem has been fixed. Ask your agreement to distinguish between them and specify:
- How incidents are prioritized according to business impact, such as a blocked core workflow versus a minor display issue.
- The agreed response time for each priority and the service hours during which it applies.
- The agreed bug-fix or resolution time and how temporary workarounds are handled.
- When measurement begins and how waiting for information or an external provider affects it.
- The support channel you should use and the escalation route for serious incidents.
Define what ongoing maintenance covers
ScriptSector describes maintenance as security patches, package updates, operational monitoring, proactive measures, OS and platform compatibility, and ongoing technical support. That outlines the service. Your agreement needs to turn it into a defined scope for your particular app.
- Patches and updates: Specify the dependencies covered, how updates are assessed and what testing is required.
- OS and platforms: Agree which versions are supported and how major changes from Apple, Google or other platforms are handled.
- Monitoring: Define the environments and workflows monitored, who receives alerts and which follow-up actions are included.
- Reporting: Agree the content and frequency, such as completed updates, incidents and unresolved risks.
- Change requests: Establish when work counts as maintenance and when it needs a separate estimate and approval.
- Monthly price: Agree the price for the defined scope, what it includes and how additional work is authorized and charged.
Also identify who can approve extra spending. A support request should not silently become authorization to redesign a feature.
The day after launch: warranty, maintenance or new development?
Similar symptoms can have very different causes. A failed login might come from an original defect, a change to an external service or a new requirement the app was never designed to meet. Separate the work into three categories:
- Warranty: ScriptSector states that bugs are fixed at no extra cost during the warranty period. Its length is not published. Confirm the duration, start date, coverage and process in the agreement.
- Maintenance: Ongoing work to keep the existing product secure, compatible and operational within the agreed scope.
- Further development: New features and planned improvements, potentially informed by analytics, user behavior or performance needs. The agreement should determine how individual requests are classified.
Ownership matters for a smaller first release too. For MVP Sprint, ScriptSector states that after delivery you own the source code, design, data and documentation and are not tied to ScriptSector. However, a public app-store release is not automatic for every MVP. Confirm the delivery format and responsibility for any store submission.
Plan the transition to live operation before development finishes. The guide to how long it takes to develop an app provides useful context for planning the wider delivery process.
Handover and exit: prepare for a change of supplier
An exit plan does not mean you expect the relationship to fail. It gives you a workable choice if your needs change. The same documentation also helps with troubleshooting while the original supplier is still involved.
Require a handover that includes:
- Source code: Repositories, history, release tags and identification of the version running in production.
- Figma files: Editable originals, component libraries and details of third-party design assets.
- Build and deployment instructions: How to build, test, publish and, where necessary, roll back the app and backend.
- Architecture overview: Key components, data flows, integrations and external dependencies.
- Accounts and credentials: An inventory of services, permissions, certificates and secrets, with a secure transfer and rotation process.
- Data and operations: Export options, backups, restoration instructions and known operational risks.
- Outstanding work: Known defects, technical debt and decisions the next developer needs to understand.
Do not put secret keys in an openly accessible repository. Transfer them securely, create appropriate access for the incoming supplier and plan when old access will be revoked. Coordinate the transition before removing permissions that are still needed to keep the service running.
A useful acceptance check is to have the incoming developer build and deploy the product in a test environment using the supplied material. This exposes missing steps before a production transition.
Read taking over an existing app: code review, rewrite or continue to assess the next step without assuming that a change of developer requires a complete rebuild.
Who owns the source code when you hire an app agency?
Check the contract and the rights it actually assigns. Payment or a promise of full responsibility is not enough to assume full ownership. According to ScriptSector's app development FAQ, you own the source code, Figma designs and documentation in full when you satisfy the agreement's conditions and make the required payments. Review third-party licenses separately, and confirm that you also have practical access to everything being delivered.
What should the contract say about source code and IP rights?
It should identify the deliverables and rights being transferred, when the transfer takes effect and any payment conditions. It should address your ability to modify the product and appoint another developer. List exclusions for pre-existing components and third-party material. Specify how code, design, documentation and data will be handed over, including if the engagement ends early. This is not legal advice; have the exact wording reviewed where needed before signing.
What does app maintenance include after launch?
Maintenance can include security patches, package updates, operational monitoring, proactive measures, OS and platform compatibility, and technical support. These are also the areas ScriptSector describes for its service. Your agreement needs to establish the actual scope, response time, bug-fix time, reporting and monthly price for your app. Confirm which environments are covered and how new features are distinguished from upkeep. Maintenance is separate from warranty and does not automatically include unlimited product development.
Can you switch developers if you own the source code and repo?
Yes, ownership and repository access provide important foundations, provided your rights allow another developer to continue the work. However, the new developer also needs to build, test and deploy the app. That requires documentation, account permissions, design files and access to the backend and relevant data. Check external licenses and dependencies as well. A technical review before the switch can identify missing material and the handover work you need to arrange.
What is the difference between owning the code and only having a license?
Ownership here means that the agreed economic rights to project-specific code are assigned to you. A license instead gives you permission to use code under stated conditions. Those conditions may be broad or may restrict modification, further development or transfer. Read what the agreement allows rather than relying on its label. Even when you own the custom code in your app, some included components may remain subject to third-party licenses.
Discuss ownership and maintenance before you commit
Want to clarify what you own and what app maintenance you need? Anton Kihlström is ScriptSector's solo founder and builds the solutions himself. Bring your agreement, proposal or open questions to a conversation about scope and handover. You can book a free call through the contact page to discuss a suitable next step.