Hiring guide
Red flags when hiring a developer, and the clauses that protect you
By Samuel Marndi · Updated
The short answer
The two failures that cost the most are not technical. They are a scope nobody wrote down, and accounts registered in the developer's name instead of yours. Both are free to prevent before work starts and expensive-to-impossible to fix afterwards.
And one point most Indian clients get wrong: paying for code does not automatically make you its owner. Under the Copyright Act the author is the first owner of what they write, and an independent contractor is not an employee, so copyright passes only by written assignment. One sentence in the agreement fixes it. Without that sentence you have paid for a licence you cannot describe. (General explanation, not legal advice — for anything substantial, have a lawyer read the agreement.)
Twelve red flags, and what each one is actually telling you
- A quote with no itemisation. One number cannot be checked, compared or disputed, which is frequently the intention.
- A quote given without a single question asked. They have either done this exact thing a hundred times, or they have not understood yours. Ask which.
- Full payment demanded upfront. This removes every incentive that was protecting you. A 20–40% deposit is normal; the whole amount is not.
- Evasiveness about code ownership. The correct answer is immediate and in writing. Anything else is the most expensive flag on this list.
- Hosting or the domain "handled for you" on their account. Convenient now, leverage later. Accounts go in your name from day one.
- No staging link, ever. If you cannot see work in progress on a URL you can click, you cannot verify progress and neither can they.
- "It's all straightforward." Every real project has a riskiest part. Someone who cannot name it has not thought about yours.
- A deadline accepted without pushback. You proposed six weeks for a four-month job and they said yes. One of you is going to be wrong, and it will be presented as your fault in week five.
- No written scope, just enthusiasm. Enthusiasm does not survive the third change request.
- Portfolio links that are dead, or that they cannot explain their part in. Verify two before you proceed.
- Communication that is already slow during the sales conversation. This is the fastest they will ever be. It does not improve after you have paid.
- Pressure. "This price is only valid today" is a technique, not a discount, and it belongs to a trade you were not hoping to buy from.
Who owns the code you paid for
Most people assume that paying for software means owning it. In India that assumption is wrong in a way that only becomes visible at the worst possible moment — when you want to change developers, sell the business, or raise money and are asked to warrant that you own your own product.
The position in outline: under the Copyright Act 1957 the author of a work is its first owner. There is a carve-out where work is made under a contract of service — employment — in which case the employer can be the first owner. An independent contractor works under a contract for service, which is a different thing, so the carve-out does not apply and copyright stays with the developer unless it is assigned in writing. An assignment has to be written and signed; a verbal agreement and a paid invoice do not achieve it.
What this means practically is that the fix is trivial if done upfront and awkward if left: one clause, signed before work starts, assigning all intellectual property in the deliverables to you on final payment. Developers who work professionally will not blink at it, because it is standard. Hesitation is informative. This is a general explanation of a legal position, not legal advice; for anything substantial have a lawyer draft or review the agreement.
- Get assignment in writing, signed, before work starts. Not a verbal assurance, and not after the invoice.
- Make it cover everything: source code, designs, content, configuration and documentation.
- Tie it to final payment. That is fair to both sides and makes the clause easy to agree.
- Ask about third-party components. Nobody writes everything from scratch; what matters is that any open-source licences are compatible with how you intend to use the result, and that no paid licence is in the developer's name.
- Watch for a retained licence. "We retain the right to reuse components" is sometimes reasonable for generic utilities and sometimes means your product is their template. Ask which components.
Accounts that must be in your name from day one
This is the single most practical section on this page. Nearly every "my developer has disappeared and I cannot get into my website" situation traces back to a decision that looked like convenience eighteen months earlier. Create these yourself, then add the developer as a user you can remove.
| Account | Why it has to be yours | The cost of getting it wrong |
|---|---|---|
| Domain registrar | It is your brand, and transfers require the registrant's cooperation | The highest-leverage item there is. A lost domain can end a business |
| Hosting or cloud | It holds your data and your customers' data | You cannot move, back up or audit anything you cannot log into |
| DNS | It decides where your website and email actually point | Email and site can be redirected or simply stop |
| Source code repository | It is the asset you paid for, and its history is part of it | A rebuild from whatever happens to be on the live server |
| Google Play and Apple developer accounts | Transfers are slow, and sometimes practically impossible | You lose the listing, the reviews and the installed base |
| Payment gateway | It is in your legal entity's name and settles to your bank | A compliance problem as well as an access problem |
| Analytics, Search Console, Tag Manager | The historical data is not recoverable if you lose access | You restart measurement from zero |
| Email, SMS and transactional providers | They send in your name and carry your reputation | Deliverability and your sender reputation are not yours to protect |
A milestone structure that protects both sides
Milestones exist so that neither party is ever carrying much risk at once. The structure below is unremarkable, which is the point — it is what both sides should expect, and departures from it should be explained rather than assumed.
- Define "done" for each milestone before work starts. Ambiguity here is the root of most disputes.
- Pay against something you can see, not against a date or a percentage of effort described to you.
- Keep a retention, and say what releases it. Thirty days and a defect list is fair; indefinite retention is not and will cost you good developers.
- Agree what happens on exit — by either side. Work to date handed over, payment for work done, no hostages. Easy to agree while everyone is cheerful; impossible afterwards.
| Milestone | Paid | Released against |
|---|---|---|
| Start | 20 – 30% | Signed scope and agreement, repository created under your account |
| Design or architecture signed off | 20 – 25% | Designs, or a written architecture, that you have reviewed and approved |
| Core build working | 25 – 30% | A staging link you can click through, on hosting in your name |
| Launch and handover | 20 – 25% | Live, the full handover checklist complete, IP assignment effective |
| Retention (optional, good practice) | 5 – 10% | Held 30 days past launch against defects found in normal use |
The handover checklist
Handover is a deliverable, not an email. If it is not itemised and tied to the final milestone, it tends not to happen — not from malice, but because everyone has moved on. Put this list in the agreement and tick it in a call together.
- Source code in your repository, with its commit history, on your organisation's account.
- Owner-level access to every account in the table above, verified by you logging in while they are on the call.
- Environment variables and secrets documented and transferred securely — not pasted into WhatsApp.
- Deployment instructions a different developer could follow: how it builds, where it deploys, what breaks first.
- A recorded walkthrough. Twenty minutes of screen recording explaining the structure is worth more than any document, and costs nothing to make.
- A list of third-party services, what each costs, when each renews, and whose card is on file.
- Any paid licences transferred to your account, with proof.
- Written confirmation that IP assignment is effective on the final payment you are about to make.
If it is already going wrong
Act earlier than feels polite. The usual pattern is three weeks of unanswered messages followed by an acceptance that the project has stalled, and the recoverable window is in those three weeks.
Put the current state in writing: what was agreed, what has been delivered, what is outstanding, what you are asking for and by when. Keep it factual and unemotional — not for the developer's benefit, but because this is the document that matters if it goes further. Ask for a handover of work to date against payment for work genuinely done; most stalled engagements end here, because almost nobody actually wants a fight.
In parallel, secure what you can reach. Check which accounts you control, change passwords where you have the authority, enable multi-factor authentication, and take a copy of whatever exists — database, files, repository. Do this before the conversation escalates rather than after. If a domain or a developer account is in someone else's name, start the registrar's or platform's own recovery process now, because those run on their timelines and not yours.
Then be honest about salvage value. A half-built system from someone unreachable is sometimes worth finishing and sometimes worth abandoning, and the decision needs a technical assessment rather than sunk-cost arithmetic. That assessment is a normal, short piece of work — a consulting engagement rather than a development one — and it is cheaper than either guessing or starting again.
The clauses worth having, in plain language
| Clause | What it does | Why it matters |
|---|---|---|
| IP assignment | Transfers copyright in the deliverables to you on final payment | Without it, under Indian law you may not own what you paid for |
| Scope and exclusions | Lists what is being built and, explicitly, what is not | Prevents the slow argument about what was "included" |
| Change control | States how changes are priced and agreed | Changes are normal; unpriced changes are how goodwill dies |
| Milestones and acceptance | Ties money to deliverables and defines "done" | Neither side is ever carrying much risk at once |
| Handover | Itemises what transfers at the end | Turns handover into a deliverable rather than a favour |
| Confidentiality | Protects your data and plans, both ways | You are giving someone access to your business |
| Warranty period | Defects found within 30 – 90 days are fixed at no cost | Distinguishes a bug from a new feature |
| Termination | Either side can exit, with work and payment settled to date | The clause everyone skips and the one that prevents hostage situations |
| Third-party costs | States what is billed at cost and whose accounts they sit in | Stops surprise invoices for licences and credits |
FAQ
Related questions
Who legally owns the code if I paid a freelancer to write it?
Not automatically you. Under the Copyright Act 1957 the author is the first owner; the exception for work made under a contract of service applies to employees, and an independent contractor works under a contract for service. So copyright stays with the developer unless it is assigned to you in writing and signed. One clause before work starts fixes it. This is a general explanation, not legal advice — have a lawyer review anything substantial.
What should I do if my developer disappears?
Act in the first three weeks, not after three months. Put the position in writing — what was agreed, what was delivered, what is outstanding, what you want and by when. Secure everything you can still reach: change passwords, enable multi-factor authentication, take copies of the database, files and repository. If the domain or a developer account is in their name, start the registrar's or platform's recovery process immediately, because those run to their own timelines. Then get a technical assessment of whether the work is worth finishing.
Should I pay a developer in full upfront?
No. A 20% to 40% deposit is normal and fair; the full amount upfront removes every incentive that was protecting you. Pay the rest against milestones you can see — a staging link you can click, code in your own repository — and keep 5% to 10% for thirty days after launch against defects found in normal use.
Whose name should my domain and hosting be in?
Yours, always, created by you, with the developer added as a user you can remove. This is the single most practical protection on the list: nearly every "I cannot get into my own website" situation traces back to accounts set up in a developer's name as a convenience. The domain is the highest-leverage item, because transferring it needs the registrant's cooperation.
What are the warning signs of a bad developer?
A quote with no itemisation; a quote given without a single question asked; full payment demanded upfront; evasiveness about who owns the code; hosting and domain "handled for you" on their account; no staging link you can see; "it's all straightforward"; a deadline accepted without pushback; no written scope; dead portfolio links; slow replies during the sales conversation; and pressure tactics about a price expiring today.
What should be in a freelance development contract in India?
At minimum: IP assignment on final payment, a scope with explicit exclusions, a change-control process, milestones with defined acceptance criteria, an itemised handover list, confidentiality both ways, a 30 to 90 day warranty on defects, a termination clause settling work and payment to date, and a statement of which third-party costs are billed at cost and whose accounts they sit in. Five clear paragraphs in an email both sides have replied to prevents most real disputes, though a lawyer should see anything substantial.
Is a retention amount fair to hold back from a developer?
Five to ten per cent for thirty days after launch, released against a defect list, is normal and reasonable. What is not reasonable is indefinite retention or a retention with no stated release condition — that will cost you the good developers, who have other clients and can tell the difference between a fair term and a lever.
How do I verify a developer's portfolio?
Open the live site or install the app on your phone, not the case study. Ask which specific parts were theirs, because "I built this" can mean one screen of agency work. Ask who maintains it now — if they still do after two years, somebody kept paying them, which is the strongest signal available. Then ask for a client's phone number, not a written testimonial.