What to send a development partner before asking for a quote

An estimate is a prediction about work that hasn't happened yet. Its accuracy depends almost entirely on what the person estimating could see when they made it. When a project runs over, the cause is often something that existed all along but wasn't in the brief, rather than slow development.

This is the list we'd want from an agency or product team before quoting. Not everything will exist for every project. That's fine, as long as everyone knows what's missing.

The design, and what the design doesn't show

Approved designs are the single biggest input for anything with an interface. The most useful version includes:

• Every distinct template, not just the homepage and one inner page. A "product page" that has three variants is three templates.
• Mobile layouts for anything non-trivial. Responsive behaviour that has to be invented during the build is a scope question disguised as a technical one.
• The design system or component library, if there is one, with the states each component needs.

Then the parts designs commonly leave out. Write them down even if the answer is "use your judgement":

• Empty states, error states and loading states
• What happens with very long or very short content
• Form validation messages
• Logged-in versus logged-out views
• What an editor can change, and what's fixed

The systems it has to talk to

Integrations are a common reason estimates go wrong, because the effort depends on the other system as much as on the build. For each one, send:

• The name and plan of the service (some API features are only on higher tiers)
• A link to its API documentation, if you have it
• Whether a sandbox or test account exists
• Who controls the account: your agency, your client, or someone else who needs to be asked

"Connect to the CRM" can be an afternoon or a month. The difference is usually in the answers above.

Content and data

If content is being migrated, say from where, how much, and in what shape. A spreadsheet of 40 products is a different job from 4,000 products with variants in a legacy database. If the client is writing new content, it helps to know when it will arrive; building with placeholder content and swapping it later is normal, but it should be planned.

Constraints that aren't in the brief

These are the questions that change architecture, so they're worth asking your client early:

• Is there a required hosting provider or cloud account?
• Are there security, privacy or compliance requirements? (Under Singapore's PDPA, for example, it matters what personal data a form collects and where it ends up.)
• Who needs access to what after launch?
• Is there a fixed launch date, and what's driving it?

Decisions, and who makes them

A project with one person who can answer questions and approve scope moves faster than one where every decision needs a meeting. Tell your development partner who that person is. If the client will be making decisions directly, say so, because it changes how communication is set up.

What a good estimate sends back

In return, you should get more than a number. A useful estimate lists:

1. What it includes, at a level of detail you could check against
2. What it assumes, meaning its understanding of the answers above
3. What it excludes
4. What it depends on that neither of you controls

That list protects both sides when something changes. If an estimate arrives without it, ask for it.

If you're preparing a brief now and want a second opinion on what's missing, send it over.