Sign First, Code Later: Freelance Contracts for Vibe Projects That Actually Get You Paid

The most painful moment in freelance vibe coding isn't having no work — it's finishing the work and not getting paid. The client's "start now, the money will follow" turns into "this isn't quite what I wanted, let's hold the final payment" three months later. Your late-night code becomes their bargaining chip.

It's not a skills problem — it's a missing artifact: a contract. Not a fifty-page legalese document, but a written agreement that puts the awkward stuff upfront: what gets built, what "done" means, when money changes hands, who owns the code. Solo developers resist contracts instinctively — "talking money hurts the relationship," "the client will think I don't trust them." The truth is the opposite: a client willing to sign is a client serious about paying; one who won't sign a single page is telling you everything right now.

This is the first half of the "freelance diptych": what happens before signing. For what happens after — documentation packs, permission handover, acceptance, final payment, maintenance boundaries — see Handover Done Right: Delivering Your Vibe Project to Clients on this site. Together they form a complete runway from "verbal yes" to "money and goods settled."

Three ways to die without a contract

Three painfully real scripts (composite characters, every plot point from real indie developer experiences):

Death 1: scope creep. K took a corporate website gig and "helpfully" added online booking — "it's simple," the client said. Then a membership system, payment integration, multi-language. One casual request, four extra months. With no contract defining "what," there is no "what not."

Death 2: acceptance hell. M delivered a mini-program; the client said "this isn't the feeling I wanted." What feeling? Couldn't say. Seven revisions later, still shaking heads. With no contract defining "done," acceptance equals the client's mood that day.

Death 3: the vanishing final payment. Chen's project went live three months ago; 30% of the fee is still "in finance's process." Push too hard and you burn the relationship; don't push and the money pretends it doesn't exist. With no contracted payment date, "the process" can run forever.

All three share one root cause: verbal agreements have no enforcement power. A contract isn't for court (most never see a courtroom) — it's for killing disagreements before they're born. Writing it forces both sides to negotiate the fuzzy zones upfront.

The quote: the contract's prequel

Before contracts, talk quotes — because many disputes are seeded at quoting time. A professional quote has four parts: itemized work (one line per feature, stating what's included), time/cost (per item), exclusions (boundaries declared upfront), and validity ("this quote is valid for 30 days" — so the client can't return in six months with the old price).

The quote-to-contract relationship: the quote is "intent," the contract is "commitment." The pro move is making the quote as close to the contract as possible — draft the SOW's skeleton right into the quote's attachment. Boundaries confirmed at quoting time don't get renegotiated at signing time. Many solo developers quote a single lump sum ("this project is $30k"), handing the client full interpretive power over "what $30k includes" — the source of all later disputes.

One counterintuitive tip: put the payment terms on the quote. "30% on signing, 30% at midpoint, 40% on final acceptance" should first appear on the quote, not at the negotiation table. Clients accept payment rhythms far more easily in the "excited phase" than in the "signing phase."

The six contract elements: solo-developer edition

A contract that protects you needs no legalese — just six complete elements:

• 1. Parties (who signs): full legal names. Person-to-person: ID numbers; with a company: business registration code + legal representative. Not "Mr. Zhang" — the full "Zhang Moumou." Unclear parties = waste paper.
• 2. Subject (what gets built): not "a website" fluff, but a deliverables list — how many pages, which features, what stack. The more specific, the better, as an attachment.
• 3. Acceptance criteria (what counts as done): feature list + acceptance standard. E.g.: "homepage, product page, contact page; renders correctly on latest Chrome/Safari; mobile-responsive; source code + deployment docs delivered."
• 4. Timeline (when): milestone dates, not one deadline. "Prototype 2 weeks after requirements sign-off, beta at 4 weeks, final acceptance and launch at 6 weeks." Each milestone tied to money (next section).
• 5. Money (how much, how paid): total, payment milestones, method, late liability. "How paid" matters more than "how much" — how many installments, each triggered by what.
• 6. Breach (what if it goes wrong): client cancellation settlement, your delay liability, dispute venue. Useless on good days, lifesaving on bad ones.

One rule: what's not in the contract was never agreed. Every "we talked about it" verbal promise doesn't exist in a dispute.

SOW: write the "we don't do" into the statement of work

The SOW (Statement of Work) is the contract's attachment — and its most battle-tested part. Its job isn't listing "what we do" (that's the requirements doc) — it's writing the "we don't do" (exclusion list) and how changes get priced.

A usable SOW has four blocks:

1. Scope boundary list. List deliverable features one by one, one sentence each. E.g.: "user registration/login (incl. WeChat QR scan)," "product listing + search + filters," "WeChat Pay integration." Outside the list = not included by default.

2. Exclusion list. The soul of the SOW. State explicitly "the following are OUT of scope": e.g., "no App development," "server/domain costs borne by client," "no logo or brand design," "no operations or marketing." When the client later says "just add an App," you point at this line.

3. Change process. The nuclear weapon against scope creep, in three sentences: "Any requirement beyond the SOW needs a written change order confirmed by both sides; the change order states added workload and cost; work starts after the client signs." — verbal additions never count, full stop. Most disputes root in "but you agreed" / "I thought it was included."

4. Assumptions and dependencies. State what you need from the client: e.g., "client provides logo and copy within 3 business days," "client provides WeChat Pay merchant account." Client delays on materials causing schedule slips are not your fault — provided it's in the SOW.

A mini example — the SOW for a ¥30,000 corporate site might read: Included: design + build of 4 pages (home/products/cases/contact), mobile-responsive, form submissions to WeCom, Baidu Analytics; Excluded: logo and copywriting (client-provided), server and domain costs, multi-language, SEO; Changes: out-of-scope work billed at ¥1,500/person-day, work starts after written confirmation; Dependencies: client delivers all copy and images within 5 business days of signing. One page, crystal boundaries.

Milestones and money: every payment tied to an acceptance

Payment design is the contract's heart. Two classic structures:

30-30-40 (for mid-size projects under ¥50k): 30% on signing (startup capital — filters out tire-kickers), 30% at midpoint acceptance (core features delivered, client signs off), 40% at final delivery (full acceptance, source code and docs handed over).

50-50 (for quick projects under ¥20k): 50% on signing, 50% on delivery. Simple, for trusted repeat clients.

Either way, three iron rules:

• The deposit is a filter: no work starts before the deposit lands. It filters 90% of flaky clients. "Build a demo first"? Fine — but the demo's scope and fee go in writing too.
• Every payment tied to a written acceptance: midpoint payment needs a signed midpoint acceptance form; final payment needs the final acceptance form. Verbal "looks good" doesn't count — pair with the acceptance templates in the client handover guide.
• Late payment gets a penalty clause: "0.05% of the due amount per day of delay." Rarely triggered — but it gives "finance's process" a cost. Clients don't delay from malice; your invoice just lacks priority. The penalty clause manufactures priority.

Distinguish retention from final payment: the final payment is "money owed on delivery"; retention is "money held against bug fixes." Keep retention under 30 days and under 10% — anything beyond that is delayed payment wearing a costume.

IP ownership: whose code is it?

The clause where vibe coders get hurt most. Default rule (China Copyright Law): for commissioned software, ownership follows the contract; without agreement, it belongs to the contractor (you). But "default yours" isn't "safe" — the paying client naturally believes "the code is mine," and disputes follow.

Write three things into the contract:

1. Who owns the copyright. Two common formulations: A) "all IP in this project belongs to the client" (what clients usually want); B) "copyright stays with the developer; the client receives a permanent, irrevocable license" (better for you, suits SaaS-able reuse). Pick one based on leverage — but pick one explicitly, never fudge.

2. The "hostage exchange" of final payment and source code. The most effective real-world clause: "source code is retained by the developer until the final payment clears; full source and docs transfer within 3 business days of receipt." Not "withholding" — contractual lien thinking. Your leverage exists only while the client doesn't have everything yet.

3. Open-source license contagion notice. If you used GPL-family components, disclose the contagion risk upfront (see this site's Vibe Project Open-Source Release Guide). Add one line: "third-party open-source components used are listed in the attachment; the client shall observe their license obligations in downstream use." Don't let license trouble boomerang back to you.

AI-era special clauses: who owns AI-written code?

The new 2026 problem no traditional template covers. Vibe-coded code is AI-generated, making the ownership chain one layer more complex than "human-written." Give the contract a standalone "AI-assisted development" clause covering three points:

• Ownership: "code assisted by AI programming tools during this project follows Section X (IP ownership) of this contract." — one sentence folding AI-generated code into the existing ownership framework, preempting "AI-written code isn't your work" disputes.
• Training-data contamination liability: "the developer shall take reasonable measures to avoid feeding client confidential information into public AI services; data leaks via AI services follow the confidentiality clause." — the operational counterpart is secrets management (see this site's secrets management guide): client DB passwords and API keys never enter a public model's prompt.
• Client-data AI boundaries: "without the client's written consent, the developer shall not use client business data for AI model training or public demos." — protects the client, and protects you: no data incident, no dispute.

In 2026 these aren't "forward-looking," they're table stakes. Some clients already demand "no AI for core code" in reverse — keep a negotiation line ready: AI is a tool, you are the responsible party, and delivery quality is guaranteed by acceptance criteria, not by "whose fingers typed."

Breach and exit: the art of parting well

The contract's last chapter writes the breakup. Nobody signs up thinking about it — but partnerships with clear exit rules last longer:

Client cancels midway: settle by completed milestones. "On unilateral client termination, paid amounts are non-refundable; completed-but-unpaid milestones settle within 15 days." — prevents "we changed our minds halfway, thanks for the free half-project."

You can't deliver: the honesty clause. "If the developer confirms inability to deliver on schedule, written notice 15 days in advance, refunding payments for uncompleted portions." — taking an over-your-head gig isn't shameful; riding it into a flaming wreck is. An exit mechanism is what lets you dare bigger gigs.

Dispute venue: state "litigation in the courts of the developer's domicile" or "arbitration at X commission." Arbitration is final and fast but pricey; litigation is cheaper but slow. Solo developers usually pick their home courts — never sign "litigation at the client's domicile," or you'll spend the dispute traveling.

Negotiation lines: raising the contract without hurting feelings

Everyone gets the theory; most freeze at "how do I bring it up." Three ready-to-use lines:

• Introducing the contract: "I have a standard collaboration template covering the requirements, timeline, and fees we discussed — it protects both sides. Take a look; we can revise anything." — keywords: "standard template" (not aimed at you) and "protects both sides" (not just me).
• "Do we need to be this formal?": "The closer the friends, the clearer the writing — even brothers settle accounts clearly. With changes handled through the written process, you're protected too — otherwise something I verbally promised might slip my mind, right?" — framing the contract as the client's protection halves resistance.
• On the deposit: "Standard practice is 30% on signing to start; scheduling follows payment order. If your process runs slow, the schedule may have to shift accordingly." — "scheduling" is the perfect lever: it's not about wanting your money, it's about your project's queue.

One core mindset: negotiating a contract isn't distrust — it's professionalism. Big-company procurement is ten times stricter than your contract — the more professional you are, the more comfortable clients feel handing you bigger gigs. The deals scared off by "hurt feelings" were likely going to hurt your wallet anyway.

The 15-point pre-signing checklist

Print it. Check every box before signing:

Parties (2): □ counterparty's full name/ID written? □ signatory authorized (company chop)?
Subject (3): □ deliverables list specific? □ exclusion list written? □ change process agreed?
Money (4): □ total tax-inclusive? □ payment milestones and triggers clear? □ deposit ≥30%? □ late penalty written?
Timeline (2): □ milestone dates explicit? □ client cooperation duties (materials/accounts) written?
IP (2): □ copyright ownership picked one of two? □ final-payment-vs-source-handover order written?
Breach (2): □ midway-cancellation settlement written? □ dispute venue on your side?

Sign only when all 15 check out. Anything missing goes back for revision — contracts are negotiated, not begged for. A client who won't even negotiate a contract properly — do you really expect them to pay properly?

Remember this piece's place: it's the first half of the freelance diptych. Signed well, you deliver with confidence; for the delivery craft (doc packs, permission handover, acceptance rituals, maintenance boundaries), read the second half, Handover Done Right. Together: may every gig you take begin in black and white and end with money and goods settled.

Disclaimer

This article shares solo-developer practical experience and is not legal advice. For large amounts or complex situations, consult a licensed attorney. Laws vary by jurisdiction; this article primarily references mainland China practice.