By Mo Hussein

1 min read

Why the proposal matters

Most fallings-out on software projects come down to a gap. The client expected one thing, and the developer thought they'd agreed to build another. A clear written proposal closes that gap before it opens.

Six things it should include

  • What will be built: the screens, features and integrations, in plain language.
  • What's left out: the things you might assume are included but aren't. This is often the most useful section of all.
  • What's needed from you: access, content, data and decisions, with dates.
  • How you'll both know it's finished: checks you can run yourself.
  • The price and payment terms, including when each payment is due.
  • What happens after launch: who hosts it, who maintains it, who owns the code and data, and what that costs.

What to ask if something's missing

If the proposal doesn't say who owns the code, ask. If it doesn't say what happens when you want a change after launch, ask. If the price has no scope attached, ask what would make it go up.

A good developer will be glad you asked. In my experience, vague answers at this stage are a reliable sign of vague work later.

Where ours fits

Every proposal we send covers all six. If you'd like to see how that works for your project, start with the estimate or book a discovery call.