A Founder's Guide to Reading a Development Proposal

A development proposal turns your brief into commitments: what will be built, by when, for how much, and what happens when something changes.

The working rule is simple: if a detail isn't written down, assume it isn't included.

Good scope describes what a user can do, not just the names of screens. “Users can sign up with email or Google and reset their password” can be checked. “Authentication module” can't.

Look for user roles, core flows, and admin tools listed separately. Admin panels are easy to forget in a brief and expensive to add later.

A clear proposal lists what's not included — for example copywriting, translations, app store submission, third-party subscription fees, or hosting after launch.

If there's no exclusions section, ask for one. Everything you assumed was included and wasn't will come back later as a change request.

You don't need to be an engineer, but you should be able to answer these questions after reading:

What will it be built with — and why that stack for your product specifically?

Who owns the code and the accounts: hosting, domain, app stores, analytics?

Where will it be hosted, and roughly what will that cost each month after launch?

Will the code be documented well enough for another developer to take over?

A good agency explains its choices in plain language. “It's what we always use” is not a reason.

A single delivery date tells you very little. Look for milestones with something you can see at each one: approved designs, a working build on a test link, a launch-ready version.

Ask how often you'll see progress. Weekly check-ins are a sensible baseline; a single demo at the very end is a risk.

Check whether the proposal mentions testing, performance, and accessibility — or only features.

Look for specifics: which browsers and devices are supported, what performance the product should reach, and who tests it before launch.

Confirm exactly what the price covers and how payments are split. A deposit plus payments tied to milestones is standard; 100% up front is not.

Find the change process. It should explain how new requests are estimated and approved before anyone starts on them.

Many proposals stop at launch day. Ask what happens next: is there a support period for bugs, how long does it last, and how is ongoing work priced?

A launch with no plan for fixes and updates is where a lot of products quietly stall.

What exactly is excluded?

Who will work on the project day to day?

What happens if we need to change the scope?

Who owns the code and every account at the end?

What support is included after launch?