Contracts, payments and who owns the website

Never 100% upfront — that removes every incentive after the first invoice. Normal and healthy: a 25–50% deposit that books the schedule, staged milestone payments against visible progress, and a final tranche on acceptance. Developers who resist staged payments are as much a red flag as clients who resist deposits — both sides need the same rope.

Both are legitimate: fixed price for defined scopes (you pay for certainty), hourly or monthly for evolving work (you pay for flexibility). Hybrid is common and honest — fixed for the defined phase, hourly for the discovered work. What is not legitimate is "fixed price" on an undefined scope: that quote is either a guess or a trap.

Fixed when the scope is genuinely known and stable — a defined site build with signed design. Hourly/monthly when requirements will evolve — products, growing stores, maintenance. The trap is mismatching: fixed-price discovery phases and hourly one-pagers both inflate. The choosing logic is in the contract guide.

25–50% is the honest professional band: enough to book committed schedule, small enough to keep delivery pressure real. Milestones then track visible progress — design approved, build on staging, launch complete — with the final 10–25% on acceptance. Anything demanding full payment before handover is asking you to loan money to a stranger.

Deposit at signing, milestone invoices with a few days' terms, final on acceptance, net-15/30 for established business clients. International work runs on Wise or bank transfer; India-based independents invoice in USD or INR with GST where applicable. The full terms this desk uses are published: payments and terms.

Seven load-bearing clauses: scope and deliverables, milestone schedule and payments, IP assignment (explicit, on final payment), confidentiality, warranty and defect-fix window, exit/kill terms, and maintenance expectations after launch. The clause-by-clause reasoning is the contract guide; the fill-in version is the SOW template.

You should — and "should" requires a clause saying so. Payment alone does not transfer copyright; the contract must assign work product to you, typically on final payment. Verify the sentence exists before signing. A developer who resists assigning the deliverable is reserving leverage over you — that is the polite version.

If the contract assigns it: yes, completely — design, code, content, configuration. Collect the ownership pack at handover: repository, credentials, domains, hosting, analytics — the full list is the handover checklist. If accounts were opened in the developer's name, ownership is partly theoretical until they are transferred. Insist on accounts in your name from day one.

For genuinely sensitive material — customer data, algorithms, unreleased strategy — yes, standard practice, and reputable developers sign without drama. For ordinary business sites, an NDA is usually theatre: the differentiating asset is execution, not the idea. A mutual NDA with a 2–3 year term covers 99% of cases: the template is free.

Technically possible, practically rare — reputation is a working developer's entire asset, and ideas are abundant while execution is scarce. The protections that matter: a contract with confidentiality and IP clauses, staged payments, and a developer whose portfolio shows no suspicious clones. Protect data and differentiators with contracts; do not protect the idea of "a booking site for X" — that idea has had ten failed launches this year already.

No to both — that is the single most common ownership trap. Domain, hosting, CMS accounts: registered in your name, your email, your payment method. The developer gets scoped access (collaborator seats, not account ownership). If a developer insists on owning the accounts, they are insisting on owning you. Recovery from this trap is possible but miserable; avoidance is one afternoon.

Prevention is structural: repo and accounts in your ownership, staged payments, documentation with each milestone. If it happens: secure every account first, export everything accessible, then vet a replacement — a documented project transfers, an undocumented one gets rebuilt. The recovery playbook is the second half of the handover checklist.

Audit what exists (deployed, in-repo, in their heads), secure access before the conversation, then a formal handover: repo, credentials, environment documentation, open-issues list. Contracts handle the money — kill fees and work-completed-to-date are standard clauses. Mid-project changes are painful and survivable; the difference is whether the previous developer documented as they went.

Yes — the determining factor is handover quality, not completion percentage. A half-built project with a repository, environments and documentation transfers well; a "90% done" project with none of those is a rebuild wearing a rescue costume. This is why professionals deliver documentation continuously instead of at the end.

Nothing catastrophic, if ownership was set up correctly: you hold the domain, hosting, repository and analytics — any competent developer continues from the handover pack. Everything continues running; what you lose is the knowledge in one head, which is exactly what continuous handover documentation insures against.