General
Share and discuss tech, products, business, startups, or product recommendations
Start new thread

Where does scope actually get locked — before the contract, or in it?

by•

I launched a booking tool for day-rate freelancers this morning and got a comment I haven't stopped thinking about:

"The friction is never the calendar; it's locking scope and terms before anyone starts working."

Fair challenge. What I built assumes scope is settled by the time a contract goes out — signing is the "we already agreed, now make it official" step, not the negotiation.

For those of you who do client work, is that true for you? Is scope usually settled before you'd want anything signed, or is it still moving right up to the signature? And if it's still moving — what specifically? Price, deliverables, timeline, revision count?

Not pitching. Genuinely want to know whether I've built for the step that comes after the hard part.

86 views

Add a comment

Replies

Best

is the contract a final step or part of the discussion?

 Final step, deliberately. The client picks dates, the contract populates with those specifics, they sign, the day is locked. No editing terms at the signing screen.

The bet is that the negotiation already happened over email or a call, and what’s missing is the part where “sounds good” becomes something binding. Reasonable people are telling me today that the negotiation is the hard part, so it’s a bet I’m now re-examining in public.

do you include revision limits in your contracts?

 Not as a built-in field — no revision counter, and I’d be wary of one, since “2 rounds” means something different for a logo than for a 60-second edit.

What’s there instead: your contract template is yours to edit, and there’s a generator where you describe your terms in plain English — “cap revision rounds at 2,” “travel reimbursed separately,” “credit on published work” — and it writes the clause in. After that it’s in every contract you send, automatically.

Is a hard revision cap something you actually enforce, or more a thing you want on paper as leverage?

what details must be clear before starting work?

 Not my question to answer, but from building this: what my tool locks by default is dates, day rate, number of days, total, and payment terms. What it doesn’t lock unless the freelancer writes it in — deliverables, revision rounds, kill fee if the client cancels, usage rights.

My read is the second list is where jobs actually go wrong, and it’s the list most people skip because it’s uncomfortable to raise. Curious whether that matches your experience.

should booking tools help define scope before contracts?

 Mostly no — with one distinction: defining scope isn’t the same as negotiating it.

Negotiating is a conversation, and software that mediates it adds a step your client didn’t ask for. Not building that.

Defining is different. Dates, rate, days, total, terms are already structured fields. Deliverables and revision rounds are free text, if they’re written at all. Making those structured too — filled in by the freelancer, before the link goes out — wouldn’t touch the negotiation.

Does that distinction hold up in practice, or does defining always turn into negotiating?

I've made the mistake of relying on verbal agreements before, and it taught me a valuable lesson. Now I treat every conversation before the contract as preparation.

 “Every conversation before the contract is preparation” — that’s the whole thesis, better put than I’ve managed. The contract isn’t where you figure it out. It’s where you stop being able to pretend you didn’t.

do you also define acceptance criteria, or do you keep things more flexible?

 No acceptance-criteria field — same as revisions, it’s yours to write into the template if you want it.

Though day rate changes the question a bit. You’re selling days, not deliverables, so “done” is less of a cliff. Acceptance criteria matter much more when you’ve quoted a fixed fee for a fixed thing.

Are you mostly day rate or project fee? Changes the answer a lot.

I think it depends on the type of client, but in my experience the scope is usually mostly agreed before the contract. The contract is there to document what both sides have already discussed and to make sure expectations are clear.

That said, I've seen the final details—like timelines, revision limits, payment terms, or one or two deliverables—continue to evolve right up until the signature.

I work in Online Reputation Management, and having a clear scope upfront has been important for avoiding misunderstandings later. The more specific both parties are before signing, the smoother the project tends to be.

The comment you received is interesting, though. It makes me wonder if there's an opportunity for your product to help with that transition from "we're discussing the work" to "we're ready to sign," rather than focusing only on what happens after the agreement.

 Agree with most of this. And the specific list you name — timelines, revision limits, a deliverable or two still moving right up to the signature — is what several people have landed on today, so you’re clearly onto something real.

On the transition you’re pointing at: the portal already does a quiet version of it. A lot of pre-contract back-and-forth isn’t negotiation at all, it’s information retrieval. What’s your rate. Are you free the 12th. What about the week after. When the client can see availability and price and just choose, those rounds don’t happen — and what’s left is the actual disagreement, which is a much shorter conversation.

Direct communication inside the booking flow is something I’ve been circling. It’s the hardest path though, and I’d rather not bolt a chat box on for the sake of it. Removing the reasons to email is more interesting to me than hosting the email.

 That makes a lot of sense. I like the way you're thinking about it removing unnecessary conversations instead of just giving people another place to have them.

You're right that a lot of the back-and-forth is really just people trying to find basic information, not actually negotiating. If your booking flow answers those questions upfront, it naturally shortens the process.

I think that's a cleaner approach than adding a chat feature. It'll be interesting to see whether users still ask for direct messaging over time, or if the booking flow ends up covering most of what they need.

 That’s the experiment, and I genuinely don’t know the answer. My guess is some of it holds and some of it doesn’t: the pure information questions go away, but there’ll be a category of “can you do X” that no form covers.

from the hiring side, not the freelancer side: price and dates are almost never what's still moving at signature time, you're right about that. what's still moving is the definition of "done" - especially on anything even slightly creative or judgment-based. two people can agree on "redesign the onboarding flow" in a call and mean completely different amounts of work. the list you flagged as the one people skip (deliverables, revision rounds, kill fee) is exactly the list I'd want a freelancer to force me to fill in, because as the client I have no incentive to bring it up myself. if your tool nudges freelancers to write that stuff down as a structured field instead of a paragraph nobody reads, that's the actual value, not the e-signature

 Most useful thing anyone’s said to me today.

The asymmetry is what I hadn’t articulated: the client has no incentive to raise deliverables or kill fee, so if the freelancer’s tool doesn’t force it, it doesn’t happen. That’s a design principle, not a feature request.

One pushback — the signature isn’t the value, but it is the forcing function. It’s the deadline that makes anyone define “done” at all. Structured fields with no moment where they become binding are just a nicer paragraph nobody reads.

Which argues the fields belong at signing rather than before it. Chewing on that.

 fair pushback, but there's a timing risk on "at signing" - that's also the moment of maximum pressure to just get it done. the client's already mentally committed, so a deliverables/kill-fee field that first shows up on the signing screen is more likely to get rubber-stamped than actually read. I'd bet the fields still need to be seen once before that moment, even informally, so the signature is locking something the client already reacted to rather than something they're seeing for the first time under time pressure. otherwise you've just moved the "sounds good, didn't really engage" problem one step later instead of solving it

 You’re right that first exposure at the signing screen gets rubber-stamped. Maximum commitment, minimum attention. I’ve done it myself on things I’ve signed.

But there’s already a “before” in the flow — the client picks dates and sees the rate a couple of steps ahead of the contract. So deliverables and kill fee probably belong there, with the signing screen showing them again as confirmation of something already seen. Same fields, seen twice, binding once.

I take the point that signing doesn’t mean reading. But I don’t think that makes it my job to police attention.

Think of it as a menu. If it says the salad has onions and you ordered it anyway, that’s yours — nobody owes you a free salad. Rules exist before the game; if you don’t agree to them, you don’t play. That’s what a contract is.

Where you’re right is that most freelance contracts aren’t menus. They say “design services” and expect that to mean something. You can hold someone to a menu. You can’t hold them to a category.

So the fix isn’t making people read. It’s making the document worth reading — an itemized summary in plain language at the top, so what they’re agreeing to is legible in ten seconds. Not reading it stays their choice. It just stops being an accident.

The pattern I keep seeing is not that people forget to write deliverables down, it is that they write them down in a place nobody opens again after the contract is signed. The information exists, but it goes quiet the moment the job starts, and quiet is exactly when scope drifts. I run a few different service style businesses, and the details that cause the most damage later are never the ones structured up front, they are the side comment in an email thread that everyone assumed the other person remembered. What I am building, FounderFlow, is less about locking scope at signing and more about catching the moment weeks later when a client casually changes what was agreed and nobody flags it as a change. Have you noticed scope drift happening more inside the work than at the signing moment itself?

 I’d be happy to check out founderflow, let me know when it’s available,

Yes — though I’d argue they’re the same problem at two points in time.

Drift needs a baseline to drift from. If the agreement said “redesign the onboarding flow,” nothing has actually drifted six weeks later — it was never specific enough to violate. You can’t flag a change against a document that never committed to anything.

So the quiet you’re describing is real, but a document going quiet matters less than a document being empty.

I stop at the commitment deliberately. Once the work starts you’re in project management, and that’s a different tool. Sounds like yours begins roughly where mine ends.