Most businesses that hire a developer assume they own what gets built. The assumption is natural — you're paying for it. But "paying for it" does not automatically transfer ownership of the underlying intellectual property. Without a contract that explicitly addresses IP, you may not own the code that runs your business.
This is not a hypothetical risk. It creates real problems when the relationship ends, when you need another developer to take over, or when you want to sell the business.
The IP Ownership Problem
Copyright in software works differently from how most people expect. In many legal frameworks, including Indonesian copyright law under UU Hak Cipta, a contractor who writes code is the initial owner of that copyright unless it is explicitly assigned to someone else in writing.
Employment is different — code written by a full-time employee in the scope of their employment typically belongs to the employer. But a contractor or freelancer is not an employee. They create work, and unless you have a written assignment, they may retain the rights.
This means a developer can — without a contract — potentially:
- Claim ownership of the codebase they built for you
- License the same code to another client
- Refuse to hand over source code after the project ends
- Use your business logic and workflows in their other projects
You paid for the development. You do not automatically own the output. This needs to be fixed contractually before work starts, not after a dispute arises.
What the IP Contract Must Cover
Full IP Assignment
The contract must state explicitly that all intellectual property created during the project — code, design assets, database schemas, documentation — is assigned to you upon final payment. Not licensed to you. Assigned. The difference matters: assignment transfers ownership permanently; a license gives you permission to use something while the developer retains ownership.
"Assigned upon final payment" is the standard structure. This means the developer retains rights during the project (giving them protection if you don't pay) and the rights transfer completely when you fulfill your payment obligation.
Source Code Handover
A contract should specify that you receive the complete source code — not just access to the running application.
Many businesses find themselves locked in with a developer who hosts their application and "lets them use it" without ever handing over the actual code. If the relationship sours, or the developer raises prices, or they simply stop responding, you have no way to migrate to another developer. The application runs but you can't touch it.
The contract should specify:
- Complete source code delivered in a standard version control repository (Git)
- All configuration files and deployment scripts
- Documentation sufficient for another competent developer to understand and maintain the system
- Delivery timing: ideally handed over at project completion, not held until a dispute arises
No Reuse of Client-Specific Code
A developer should not take the specific logic they built for your business — your pricing engine, your workflow automation, your customer data model — and reuse it in a competitor's project. The contract should prohibit this explicitly.
There's a reasonable distinction here: a developer who builds a contact form component for you should be able to use generic contact form code elsewhere. A developer who builds a specific order management system designed around your unique operational processes should not be able to lift that logic and sell it to your competitor. The contract should draw this line clearly.
What the NDA Must Cover
An NDA (Non-Disclosure Agreement) protects the information you share with the developer during the project — before any code is written and during the entire development process.
In a software project, this includes:
Business processes and workflows. When you explain to a developer how your business operates — how orders are processed, how pricing is determined, how customers are segmented — you're sharing internal business logic that may represent real competitive value.
Financial information. Revenue numbers, margin structures, pricing models shared during requirements discussions should be protected.
Client and customer information. If the developer needs access to production data, or even sanitized sample data, any information relating to your clients should be explicitly covered.
Strategic plans. The fact that you're building a new product or entering a new market, which you may discuss during scoping conversations, is business-sensitive information.
The NDA should cover the development period and extend for a reasonable period after project completion — typically 2-3 years.
Timing: Before Work Starts
These documents need to be signed before any work begins, before any meaningful business information is shared in discovery sessions, and before any designs or code are produced.
A developer who presents a contract after the project has started is presenting it from a position of leverage — work is already done, you're already committed. Reviewing contract terms at that stage is more difficult and psychologically harder than reviewing them before any investment has been made.
Make it a condition of engagement: no discovery sessions, no design work, no development without signed IP assignment and NDA in place. Once the legal groundwork is covered, knowing how to evaluate a software proposal is the next thing to get right — scope, timeline, and payment terms all matter as much as the contract terms.
When Developers Push Back
Most professional development firms sign these agreements as a matter of course. Established software houses have standard contract templates that cover IP assignment appropriately.
Resistance to IP assignment terms is a significant red flag. A developer who is reluctant to assign IP may be planning to reuse your code, may have built similar systems for other clients using shared components they don't want to give you full ownership of, or may simply not understand the legal implications — which is concerning in its own right.
If a developer says "we don't do IP assignment" or asks you to agree to a license-only arrangement, take that seriously. It means you're building on land you'll never own.
This Is Basic Business Hygiene
None of this is adversarial. A well-drafted development agreement protects both parties: you have clear ownership and code delivery rights; the developer has clear payment milestones and scope definition. The contract makes the relationship predictable.
What's adversarial is discovering, after you've spent significant money building a system, that you don't own it and can't move it without starting over.
CERIS provides clear IP assignment and NDA documentation as standard practice on every project — ownership is never ambiguous. See our web development service or get in touch if you're starting a software project and want to understand what the contracts should look like.
