What Your Web Development Contract Should Say About Ownership, Escrow and Warranty
A web development company in Pune should hand you a contract that names you, in writing, as the owner of your source code, your domain, and your hosting accounts the day the final invoice is paid — not "eventually," not "on request," and not only for an extra fee. Most disputes between businesses and their web developers in India are not about design taste. They are about who actually controls the website once the relationship ends, and that question is answered by three clauses most business owners never read closely: ownership, escrow, and warranty.
This matters more in 2026 than it did five years ago. Websites now sit on top of payment gateways, CRM integrations, WhatsApp Business API connections, and customer databases. A vague contract that was merely inconvenient in 2018 — the developer holds the hosting login, the domain sits in the agency's registrar account, nobody can find the original files — is now a business continuity risk. If your web development company in Pune goes quiet for a month, or shuts down, or simply stops answering calls, you need to know exactly what you can do about it without waiting for their cooperation.
This guide breaks down what each clause should actually say, what "escrow" means for a website (it is simpler than it sounds), how to write a fair warranty period, and the handover checklist to run through before you release the final payment.
Why the Contract Matters More Than the Mockup
Most first-time buyers spend their attention on the design proposal — the homepage mockup, the color palette, the font choices — and treat the contract as boilerplate to sign quickly so work can start. That ordering is backwards. The mockup tells you what the website will look like for the first six months. The contract tells you what happens for the next five years: who can edit it, who can move it, who can sell it, and what happens the day you and the developer disagree about anything.
A written scope of work matters too, but scope disputes are usually recoverable — you negotiate, you pay for the extra page, you move on. Ownership disputes are not recoverable in the same way. If your domain registrar account was set up in the agency's name and email address, getting it back after a falling-out can take weeks of registrar-mediated disputes, and in the worst cases, months. This is the single most common and most avoidable failure mode in Indian small-business web projects, and it costs nothing to prevent — it only costs the discipline to insist on the right clauses before you sign.
What "Ownership" Actually Means in a Website Contract
"You own your website" is a marketing line, not a legal clause. A real ownership clause has to separately cover four different assets, because a website is not one thing — it is source code, a domain name, a hosting account, and licensed third-party components, and each one is owned or controlled differently.
Source code and design files
The contract should state plainly that copyright in the custom code, custom graphics, and custom content created for your project transfers to you on full and final payment — not on signing, and not "upon request." Under Indian copyright law, in the absence of a written assignment, the default position under the Copyright Act, 1957 can leave the creator (the developer) as the first owner of the work even though you paid for it, unless the contract of service or a specific assignment clause says otherwise. This is exactly the ambiguity a proper website development contract has to close: name the transfer explicitly, name the date it takes effect, and name what is covered — front-end code, back-end code, database schema, and any custom design assets.
Domain name
The domain should always be registered in your company's name, using your company's email address as the registrant contact, with your card or bank details on the registrar account — never the agency's. This is not a contract clause so much as an operational rule, but it belongs in the contract anyway: state explicitly which party owns the registrar account and who holds administrative access. If a domain was already registered by the agency before this rule was made clear to you, ask for a registrar transfer as a condition of any further payment. It is a five-minute task for the agency and a serious long-term liability for you if left undone.
Hosting and infrastructure accounts
The same logic applies to hosting. Whether the site sits on a shared hosting panel, a cloud server, or a managed WordPress host, the account should be created under your business's billing details, with credentials shared with you directly — not only known to the developer. A contract line requiring "full hosting and server credentials to be provided to the client within 5 business days of go-live" removes an entire category of future leverage a difficult developer could otherwise hold over you.
Licensed third-party components
Not everything in your website is something the developer can transfer, because not everything was built by them. Premium WordPress themes, page-builder plugins, stock photography, and paid font licenses are usually licensed to whoever purchased them, under that vendor's own terms — and many of those licenses are non-transferable between owners. Your contract should list which components are licensed (and to whom) versus custom-built, so you know in advance what needs re-licensing in your own name if you ever change developers.
| Asset | Who should hold it | Common failure mode |
|---|---|---|
| Source code copyright | Client, on final payment | No written assignment; ownership stays ambiguous |
| Domain registrar account | Client's company name and email | Registered under the agency's account |
| Hosting/server account | Client's billing details | Only the agency has login access |
| Premium plugins/themes | Whoever purchased the license | License tied to agency's account, not transferable |
| Analytics/Search Console | Client's Google account | Agency's personal account, access revoked later |
Source Code Escrow: When You Actually Need It
Escrow sounds like something only enterprise software vendors need, but the underlying idea applies to a website contract of any size, and it is much simpler in practice than the word suggests. At its core, escrow means a current, working copy of your source code exists somewhere you control, independent of whether the developer is cooperating that week.
For most small and mid-sized business websites, formal third-party escrow services are unnecessary overhead. What actually solves the problem is a contractual requirement that the developer push all code to a private repository (GitHub, GitLab, or Bitbucket) that your business owns, with the developer added as a collaborator rather than the reverse. This costs nothing, takes minutes to set up at project start, and means you are never one unanswered phone call away from losing access to your own website's code.
Escrow becomes more important, not less, as the site becomes more custom. A template-based WordPress site can usually be rebuilt or migrated by a new developer within days even without full historical code access, because the content lives in a portable database. A custom-coded application with its own business logic — a booking system, a donor CRM, a B2B ordering portal — is much harder to reconstruct from scratch, and that is exactly the kind of project where a repository clause in the contract is worth insisting on before work begins.
Warranty Periods: What a Fair Bug-Fix Clause Actually Covers
A warranty clause in a web development contract answers one question: after launch, who pays to fix something that breaks, and for how long? Left undefined, this becomes a source of friction the very first time a form stops submitting or a checkout button misbehaves on one browser.
A reasonable warranty period for a standard business website is 30 to 90 days after go-live, during which the developer fixes, at no extra cost, any defect where the delivered functionality does not match the agreed scope of work. That is the operative distinction a fair clause has to draw: a warranty covers bugs in what was promised, not new features you decide you want after launch, and not problems caused by a plugin or theme you installed yourself after handover.
Three things a fair warranty clause should specify:
- Duration. State a fixed number of days from the go-live date, not from contract signing — a project that slips by two months should not eat into your warranty coverage before the site even exists.
- Scope. Define a bug as "the delivered feature does not behave as specified in the signed scope of work," and separately define what counts as a new request outside that scope, so both sides have a shared basis for disagreement instead of an open-ended argument.
- Response time. A written commitment — for example, an acknowledgement within one business day and a fix or fix-timeline within three to five business days for a non-critical defect, faster for anything that stops the site from functioning (a broken checkout, a form that silently fails) — turns a vague promise into something you can actually hold the developer to.
Beyond the warranty period, most businesses move to either a maintenance retainer or a pay-as-needed arrangement for ongoing support; that is a separate commercial decision from the warranty, and it should be documented as a separate clause so the two are never confused.
Handover Checklist Before the Final Invoice Is Paid
Release the last payment only after each of the following has actually been confirmed, not merely promised for "after payment":
- Full source code pushed to a repository your business owns, with the developer's temporary access documented
- Domain registrar login confirmed in your company's name and email, with two-factor authentication reset to a device you control
- Hosting or server panel credentials shared directly, with any developer-only admin accounts either removed or clearly labelled
- Database export or direct database access, current as of go-live
- Google Analytics, Google Search Console, and Google Business Profile access transferred to accounts your business owns, not the developer's personal login
- A written list of every third-party plugin, theme, and paid license used, with renewal dates and whose payment method they are billed to
- SSL certificate ownership and renewal responsibility clarified
- A signed statement confirming the warranty start date and its duration
If any single item on this list cannot be confirmed before the final payment, that is the moment to hold the payment — not the moment to trust that it will be sorted out afterward. Reviewing a completed portfolio of business websites is a reasonable way to judge a developer's design work before you sign, but it tells you nothing about how cleanly they hand a project over; ask directly, and ask for it in writing.
What Happens If the Agency Becomes Unresponsive or Shuts Down
Freelancers and small agencies do occasionally become unreachable — sometimes because of a bad-faith dispute, more often because a small team scaled down, a key person left, or a business simply closed. If your contract already covers ownership, escrow, and handover the way this guide describes, an unresponsive developer is a serious inconvenience, not a crisis: you already hold the domain, the hosting, and a working copy of the code, and a new developer can pick up the project without needing the original team's cooperation at all.
If those clauses were never put in place, your options narrow considerably. A domain registered under someone else's account can sometimes be recovered through the registrar's dispute process if you can show proof of payment and business ownership, but this can take weeks. A website with no accessible source code repository may need to be rebuilt rather than migrated, which is more expensive than it would have been to simply insist on the right contract terms at the start.
Freelancer, Small Studio, or Registered Web Development Company in Pune: Does Size Change the Risk?
The size of the team you hire changes how likely a handover problem is, not whether the same clauses matter. A solo freelancer is more exposed to simply becoming unavailable — illness, a full-time job offer, or moving cities can all end contact with no malicious intent involved, and there is no second person at the firm to pick up the thread. A larger, registered web development company in Pune usually has more institutional continuity, but size is not a guarantee either: a company can still default to keeping domains and hosting under its own master account across all its clients purely as an operational habit, not a deliberate power play, and that habit creates exactly the same risk for you.
The practical takeaway is not "always hire a bigger firm." It is that the ownership, escrow, and warranty clauses in this guide matter regardless of who you hire, and if anything they matter more with a solo freelancer, precisely because there is no institutional backup if that one person becomes unreachable. Ask every prospective developer, freelancer or firm, the same direct question before signing: "If I never spoke to you again after launch, what would I be able to do with my website?" A confident, specific answer is a good sign. A vague one is worth pushing on before any money changes hands.
Frequently Asked Questions
Does a website contract need to explicitly mention copyright assignment?
Yes. Payment alone does not automatically transfer copyright under Indian law; the contract needs a specific clause stating that copyright in the custom code and design transfers to the client on final payment, or ownership can remain legally ambiguous even after the invoice is settled.
Can a web development company legally hold my domain hostage?
Practically, yes, if the domain was registered under their account rather than yours — it is not necessarily illegal, but it gives them significant leverage in any dispute. The fix is preventive: always register the domain under your own company's registrar account from day one.
Is source code escrow expensive to set up?
For most small business websites, no — it typically means adding your business as the owner of a private code repository and having the developer push code to it as a contractual requirement, which costs nothing beyond a few minutes of setup at the start of the project.
What is a reasonable warranty period for a business website?
30 to 90 days from go-live is standard for most business websites, covering defects against the agreed scope. Larger custom applications sometimes negotiate longer periods, and ongoing support beyond the warranty is usually a separate maintenance agreement.
Should I pay 100% upfront to a web development company in Pune?
Most reputable agencies work on a milestone basis — commonly an advance to begin, a payment at design approval, and the balance at launch — rather than full payment upfront or full payment only at the end. A staged structure protects both sides and gives you natural checkpoints to confirm ownership and handover items before the relationship concludes.
What if my current developer refuses to add these clauses?
Treat it as information. A developer who resists a standard ownership, escrow, or warranty clause is telling you, before the project even starts, how a future disagreement is likely to go.
Where to Start
Before signing with any web development company in Pune, ask for these three clauses in writing: an explicit copyright assignment on final payment, a repository-based escrow arrangement you have access to from day one, and a defined warranty period with a stated response time. None of this adds meaningful cost to a project, and all of it removes the single most common source of dispute between Indian businesses and their web developers. If you would like a second opinion on a contract you have already been sent, or want to discuss pricing structures that build these protections in from the start, the Govindani Infotech team is available on WhatsApp to walk through it with you.