Your Proposal Is Your First Deliverable

When a prospect asks for a proposal, most founders treat it as paperwork standing between them and the real work. You've had a good conversation, they seem interested, and now there's a document to send before anything can start. It's easy to pull up the last one, swap the names and numbers, and get it out the door.

But think about it from the other side of the table. The prospect can't see the work you'll do for them, because you haven't done it yet. They can look at your website and maybe a few past examples, but none of that was made for them. The proposal is the first thing you produce specifically for this client, on their problem, under a little bit of time pressure. Whether you intend it or not, they read it as a preview of what working with you will be like.

That changes what a proposal is for. It isn't only a price and a list of tasks. It's evidence.

Did you actually listen?

The first thing a careful prospect looks for is themselves. Does the proposal describe their situation, in terms they'd recognize, or does it describe a generic client who could be anyone? A proposal that opens with a few sentences restating the problem in the client's own words tells them you were paying attention during the conversation. A proposal that opens with three paragraphs about your company tells them something too.

This is also where the copy-and-paste habit bites. Leave the last client's name in a heading, or describe an industry they're not in, and the prospect learns something real about how closely you'll look at their work once they've paid. It's a small mistake, but it lands at the moment they're deciding how much to trust you.

Is the scope clear about what's not included?

Most proposals do a good job of listing what you'll do. Fewer say plainly what you won't do, and that's usually where the trouble starts later. A vague scope feels friendly when you send it, because nobody has to have an awkward conversation. Then, a month in, the client asks for something "while you're in there," and you're having that conversation anyway, except now it's about money they thought was already spent.

A short "not included" section does a lot of work. It shows you've done this before and know where projects tend to grow. It also gives you both something to point to when a request falls outside the lines. Pair it with a sentence about how changes are handled, and the eventual "can you also..." becomes a routine question instead of a test of the relationship.

Is the timeline honest about what it depends on?

A timeline with no conditions attached reads as confident, right up until it slips. Most projects depend on things the client controls: content they need to write, logins they need to share, decisions they need to make. A proposal that names those dependencies is being honest about how the project will actually go. It also quietly tells the client that their part matters, which tends to make them more responsive when the time comes.

The same goes for dates in general. If you can't promise a launch date because it depends on a third party, say so. A slightly less impressive timeline that holds up is worth more than an exciting one you'll have to walk back.

Does the price make sense on its own?

Founders often worry about whether the number is too high. Prospects tend to worry more about whether they understand it. What exactly does the fee cover? When is each payment due, and what has to happen first? Is anything billed separately, and if so, how will they know before it shows up on an invoice?

A clear price with no surprises does more for trust than a lower one with fuzzy edges. If the payments are tied to clear points in the project, the client can see how their money and your progress line up, and you avoid the uncomfortable "I thought that was included" conversation later.

How easy is it to say yes?

The last part of a proposal is the part most people forget to design: what the client actually has to do to accept it. If saying yes means printing a page, signing it, scanning it, and emailing it back, some prospects will put it off until next week, and next week has a way of becoming never. Whatever method you use, the path from "this looks right" to "we're started" should be short and obvious, with the next step spelled out.

Timing counts here too. If you told a prospect they'd have the proposal by Thursday, Thursday is a promise. Sending it on time, as described, is the first commitment they get to watch you keep.

The first promises you'll be measured on

Underneath all of this is a simple idea. Every line in a proposal is a promise, and they're the first promises the client will hold you to. If the proposal says you'll check in weekly, they'll notice the week you don't. If it says revisions are included, they'll count them. If it describes a result you've never actually delivered before, they'll remember that too.

That's the real reason to treat a proposal as a deliverable rather than a formality. The prospect is deciding whether to trust you with their business, and so far, the proposal is the only thing you've made for them. They're going to judge the work by it, so it should be work you'd be comfortable being judged by.

‍