Negotiating Contracts as a Solo Founder

Over one week I went from receiving a corporate work agreement with an uncapped liability clause to a signed contract with a cap I could live with. Along the way I also resolved a billing dispute and priced a separate proposal. The lessons generalize to any small firm negotiating with a much larger client.

Win billing disputes with evidence, not argument

When a client questioned my invoiced days, I didn't defend the number - I reconstructed the engagement day-by-day, with dated screenshots for every period. The reconstruction actually surfaced one more billable day than I'd originally claimed, and I disclosed that too, explaining the discrepancy instead of quietly keeping the convenient figure.

The evidence log is the playbook: it removes ambiguity, demonstrates diligence, and protects both sides. And transparency about a revision in your own favor builds more trust than a tidy number ever could.

Bundle objections into one clean shot

When the contract arrived with three problems - an uncapped audit/liability clause, an overbroad IP assignment, and the wrong legal entity - I sent all three objections in a single, well-structured email: the ask, the reasoning, the proposed language. Piecemeal back-and-forth burns goodwill and telegraphs disorganization. One comprehensive counter reads as professional diligence.

Email is for confirmation, not surprise

Here's what didn't work: pushing back on "standard legal clauses" by email, after the legal team had already pre-approved them. The reply was predictable - "standard provisions, non-negotiable." The mistake wasn't the objection; it was the channel and the timing. Liability concerns should be raised verbally in the initial scoping conversation, with the decision-maker, so the eventual email merely confirms what's already been agreed. Cold objections to a legal department rarely move; a warm agreement with a sponsor almost always does.

Open at 20, settle at 50, and send the exact words

My opening position was a liability cap at 20% of fees. We settled at 50%. The opening ask did its job - it converted "uncapped" into "capped" - and the settlement was a risk I could price. Perfect is not the goal; bounded exposure is.

The final unlock was mechanical: when the counterparty said "share what you want included," I sent ready-to-paste clause language, not a description of what I wanted. Every day a contract sits unsigned costs goodwill and delays revenue, and vague asks are the main source of drag. Exact words close loops.

Know why you're discounting

In the same week, pricing a separate proposal, I caught myself about to cut my own rates out of nothing but doubt - even though the quoted price was below market for the scope. There are legitimate reasons to discount: the client supplies the design, the scope is execution-only, the relationship has strategic value. "I feel like it's too expensive" is not one of them. Name the reason for a discount before you give it, or don't give it.

The pre-send checklist

One embarrassing near-miss: a finished proposal PDF carried a date exactly one year in the future. Any AI-assisted document needs a three-point human check before it leaves the building: dates correct, rates as intended, contact details right. Thirty seconds of checklist beats a credibility dent.

Don't build past what you were paid for

The negotiation doesn't end when the contract is signed - it continues every time you decide what to actually deliver against it. A few months into one retainer, I caught myself speccing a six-module SaaS application - a credit ledger, a RAG pipeline, a multi-tenant admin panel - for a client who had contracted two documents: a playbook and a spreadsheet model. Nobody asked for software. I was about to build it anyway, because I already had the hardest pieces of that architecture sitting in my own product and porting them felt efficient.

It isn't efficient. It's scope creep with better production values. The correction that stuck: the spreadsheet isn't the deliverable, it's the control panel. A tool that helps you produce the two documents you were paid for is fine. A resellable product built on a client's dime, without a commercial conversation about who owns it, is a liability dressed as a favor.

Three rules came out of nearly making that mistake:

• Lock the numbers in the document before you encode them in software. Funnel rates, targets, pricing assumptions - all of it is still draft until the client signs off. If they push back after you've built five interconnected modules around those numbers, you're not revising a paragraph anymore. Get agreement on the document first. Code is expensive to re-negotiate; prose isn't.
• Stub the complex subsystems instead of porting your hardest work. The pieces of your own product that took the longest to get right - a ledger, a retrieval pipeline, a permissions model - almost always solve a problem the client doesn't have yet. Log a number instead of reserving and settling a balance. Paste full context instead of chunking and embedding it. Build the simple version that fits the actual scope, not the impressive version that fits your other project.
• Settle the IP question before you write a line of resellable code. If a client is paying for the work, they can reasonably claim ownership of anything built under that engagement - including a tool you intended to reuse elsewhere. A one-line assignment or license clause, agreed before you start, is cheap insurance against a fight you'd rather not have later.

The instinct to over-deliver is not a character flaw - it's usually good energy pointed at the wrong target. The discipline is remembering that a contract defines a boundary in both directions: it protects you from doing too little, and it should stop you from quietly doing too much.

When a task survives its own calendar block

Twice in the same week, a task I had explicitly time-blocked - not just intended to do, but scheduled with a dedicated slot - failed to get done. It happened again the next day. And the day after that. Six days running, an unsent letter that unlocked a six-figure invoice sat in draft while I filled the same calendar slot with something else.

The pattern only became visible in writing it down each night: if a task survives two dedicated calendar blocks without getting done, the problem isn't time. Scheduling more time is the wrong fix - it treats a symptom. Something else is blocking it: an unresolved dependency, an uncomfortable conversation you're avoiding, or uncertainty about the exact wording. The fix isn't a third calendar block. It's ten minutes spent naming, explicitly, what is actually stopping you - then either resolving that one thing or just shipping an imperfect draft and iterating from there.

Split payments move faster than full ones

I went into a new consulting engagement planning to invoice the full value upfront. The client pushed back, asking for 50% advance and 50% on completion instead. My instinct was that this was a downgrade - less cash, sooner objections. It wasn't. The advance still moved that day, the client felt in control of the risk, and the balance came just as fast once the deliverable landed. Insisting on 100% upfront from a client you don't have a track record with is optimizing for your own comfort, not for speed of cash in. A split that matches the client's risk tolerance closes faster than a "cleaner" number that stalls in their inbox.

The throughline

Asymmetric negotiations reward preparation over posture: evidence beats assertion, one bundled counter beats a drip of complaints, verbal pre-alignment beats written surprise, a priced-out cap beats an unwinnable fight for zero risk, a deliberate discount beats a doubtful one, and a client's actual scope - not your own ambition - defines what gets built. The party with less leverage wins on process - and the same discipline applies after the ink dries: a stalled deliverable is a signal to diagnose, not a reason to schedule more time, and a payment structure that matches the other side's risk tolerance closes faster than one that only suits yours.