No Good Faith: Why Informal Agreements Are Not a Business Model

Good faith is not a contract.

It is, at best, an assumption — one that holds until circumstances change, until money gets tight, until one party's memory of what was agreed diverges from the other's. And when that assumption breaks, as it eventually does in enough engagements, there's nothing underneath it to stand on.

The operators who run projects on handshakes and email threads are not naive. They're often experienced, well-networked, and operating in industries where relationships matter and reputation travels. They choose informal structures not out of ignorance but out of a belief that the relationship is strong enough to hold, that documentation would signal distrust, that the overhead of formal agreements isn't worth it for engagements that feel straightforward.

That belief is understandable. It is also one of the most expensive assumptions in project-based work.

This post names what operating informally actually costs — the specific exposure that good faith doesn't cover — and makes the case for what needs to be in writing before any engagement begins.

What Good Faith Actually Covers

Good faith covers intent. It does not cover interpretation.

When two parties enter an engagement with genuinely good intentions, good faith governs the spirit of the relationship. Both parties want it to work. Both parties intend to fulfill their commitments. Both parties expect to be treated fairly.

What good faith does not cover is what happens when those two parties have different interpretations of what was agreed — different understandings of scope, different assumptions about revision rounds, different memories of what the payment terms were, different definitions of 'complete.'

Those gaps don't require bad faith to become expensive. They only require ambiguity. And ambiguity is the default state of every informal agreement.

The fix for informal agreements is not distrust. It is documentation. The operators who cannot tell the difference between those two things will keep absorbing gaps that belong in an agreement.

The Five Things Informal Agreements Never Settle

1. Scope boundaries

Informal agreements describe what you're going to do. They almost never define what you're not going to do.

That omission is where scope creep lives. Every 'can you also...' request, every 'while you're at it...' addition, every 'I thought that was included' conversation traces back to the same root: a scope boundary that was never drawn.

A written agreement with a defined scope — what's included and, explicitly, what isn't — converts scope expansion from a relationship negotiation into a documented change order. The conversation still happens. But it starts from a different position.

2. The vendor who never agreed to your terms

Operators who work with subcontractors informally are not just operating without protection — they're assuming their sub has accepted terms the sub was never shown.

You may have a clear internal understanding of what you need: a specific deliverable, by a specific date, meeting a specific standard, with IP that belongs to you. If your sub never signed anything that reflects those terms, they haven't agreed to them. Your internal clarity is not a binding commitment on their part.

The subcontractor who delivers late, delivers below standard, or delivers something they claim partial ownership of is not necessarily operating in bad faith. They may simply be operating under a different understanding of an arrangement that was never formally defined.

3. What 'we'll work it out' meant

Informal agreements often defer hard conversations to later. Payment timing is 'flexible.' Revision scope is 'reasonable.' Ownership of work product will be 'figured out.' These deferrals feel collaborative in the moment. They become contentious when later arrives and both parties have a different idea of what was deferred to.

'We'll work it out' is not a term. It is an open question that one party will eventually answer unilaterally — usually the one with more leverage at that moment, which may not be you.

4. What happens when the client doesn't pay

An informal engagement with no written payment terms gives you limited recourse when a client delays, disputes, or simply stops paying.

Without a written agreement specifying payment amounts, due dates, late fees, and what constitutes a breach, you're relying on the client's continued goodwill to collect what you're owed. When that goodwill evaporates — after a dispute, after a budget cut, after a change in the client's internal priorities — you have a relationship problem where you need a contractual remedy.

5. What happens when something goes wrong

Disputes happen in project-based work. Deliverables are missed. Scopes are misunderstood. Clients are dissatisfied. Vendors underdeliver. These events are not rare; they are a predictable feature of complex, multi-party engagements.

When something goes wrong in a formally documented engagement, there's a reference point: the agreement. What was the scope? What were the milestones? What did the approval process look like? What are the dispute resolution terms?

When something goes wrong in an informal engagement, the reference point is memory — and memory is the least reliable document in any dispute.

The Cost of Absorbing the Gap

Operators who run informal engagements are not avoiding cost. They're deferring it.

Every gap that a written agreement would have covered — every undefined scope boundary, every unwritten payment term, every undocumented deliverable standard — gets absorbed somewhere. Either the operator absorbs it (by delivering more than they priced, waiting longer than they planned to get paid, or losing the dispute because they can't prove what was agreed), or the relationship absorbs it (through the friction, resentment, and damaged trust that unresolved ambiguity creates).

The operators who resist formal documentation because it 'takes too long' or 'feels too formal for this relationship' are trading known upfront cost (the time to draft and execute an agreement) for unknown downstream cost (whatever the gap eventually costs when it surfaces).

That trade almost never favors the operator.

What Needs to Be in Writing Before Any Engagement Begins

The standard for documentation doesn't have to be a 40-page contract reviewed by outside counsel. It has to be specific enough that both parties are operating under the same understanding — and that understanding is verifiable if something goes sideways.

For every client engagement, that means:

— A defined scope — what you're delivering and what you're not, specific enough that additions are unambiguous

— Milestone definitions with approval mechanisms and payment triggers — not vague phases, but specific deliverables tied to specific events

— Payment terms — amounts, timing, late payment consequences, and what happens if a milestone is disputed

— IP ownership — when it transfers, under what conditions, and what happens if final payment isn't made

— A change order process — how scope changes are documented and priced before work begins

For every subcontractor engagement, that means:

— A defined scope and delivery standard — specific enough that 'complete' is unambiguous

— Deliverable dates that sit before your client milestones — with buffer for your review

— IP assignment — all work product transfers to you

— Confidentiality — client information stays protected

— Non-solicitation — your client relationship stays yours

None of this is adversarial. Professionals who intend to honor their commitments have no objection to signing agreements that reflect those commitments. The resistance to documentation, when it comes, is itself information about the engagement.

Documentation Is Not Distrust

The operators who formalize every engagement — client and subcontractor alike — are not signaling that they don't trust the people they work with. They're signaling that they run a professional operation where expectations are clear, commitments are documented, and both parties know exactly what they've agreed to.

That signal is not a liability. It is a differentiator. The clients and subcontractors who respond well to formal agreements are the ones worth building long-term relationships with. The ones who resist are flagging something worth knowing before the project starts.

Oblige is built to make this documentation standard practice rather than an exception — agreement templates that cover both sides of a dual-layer project, milestone structures that activate payment obligations automatically, and a record layer that documents what was delivered, approved, and paid across every engagement.

Good faith is how you show up to the work. Documentation is how you protect it.