What a proposal to build your website or store should include

The problem appears after signing

Almost no web project becomes complicated in the first meeting. It gets complicated in the third week, when someone asks whether the form included the CRM connection, whether the supplier would take the photos, or whether the blog came with articles. Each of those questions has an answer, and ideally it should be written in the proposal before you approve it.

Reading a proposal carefully does not require knowing how to code. It requires checking six blocks with the same question: is this written down or am I assuming it?

The six blocks you should find

Scope and deliverables

Good scope is a list, not an adjective. It should state how many pages or templates, which features, which integrations and which languages. Deliverables answer another question: what you will have in hand at the end. Besides the published site, request that administration access be delivered in your company’s name and a way to understand what was built.

Exclusions: the section that prevents most disputes

A proposal that does not say what it excludes leaves everything open to interpretation. Typical exclusions are content writing, photography, third-party licenses, ad spend, integrations not listed and design changes after approval. Something being excluded is not bad: the problem is discovering it late.

Inputs, access and deadlines

Every deadline depends on something you deliver: texts, logos, photos, domain access. A serious proposal states when the clock starts and what stops it. At RealStack, for example, the 72 h* timeframe for Launch™, Commerce™ and Scale™ begins with onboarding approval, with a standard scope closed in writing and complete inputs; it does not start from payment and does not apply to any development.

Measurement and continuity

Ask what will be measured on launch day and with which tools. Analytics accounts should be in your company’s name, with provider access granted as a user, not the other way around.

Under continuity there are four distinct things you should not mix: warranty (bug fixes to the delivered work for a defined time), hosting and infrastructure (keeping the site online), support (who handles requests and under what plan) and evolution (improvements and new features, which are quoted separately). If the proposal groups them with a single word, ask that they be separated.

Review procedure

1. Read the entire proposal once without marking anything.
2. On the second reading, locate the six blocks and mark which are missing.
3. Make a list of what you are assuming and what is not written.
4. Send those questions to the provider in writing and request an adjusted version.
5. Compare the final version with the downloadable checklist before approving.

Applied example

Limits of this guide

This guide helps you review the commercial and operational content of a proposal. It is not legal or tax advice: clauses on liability, intellectual property, taxes and payment terms should be reviewed by your lawyer or accountant.

Criteria for comparing proposals

Two proposals with the same price can contain very different scopes. Comparing them by price without normalizing scope leads to choosing the one that explains the least, not the one that is most suitable.

Complete concise example

Concise example. A fictitious company receives three proposals for its corporate site. It uses the checklist and finds that proposal A details eight templates, exclusions and delivery conditions; B promises “everything necessary” without a list; C includes content writing, but does not state who owns the domain or analytics.

Instead of discarding B and C, it sends the same questions to all three providers: which templates are included, what is excluded, who creates and administers the accounts, what happens at the end. With written answers, the three proposals can be compared equally. The company chooses the provider that best responds, not the cheapest one. Invented example.

How to use the downloadable checklist

1. Print or copy one checklist per proposal.
2. Mark only what is written in the proposal, not what was said in the meeting.
3. Turn each empty checkbox into a question for the provider.
4. Request the answers in writing and annex them to the proposal.
5. If there are contractual doubts, consult your legal advisor: this checklist is not legal advice.

Questions to ask the provider

• What happens if inputs arrive late: does the deadline move or does the price change?
• How many rounds of revisions does each deliverable include and what counts as a revision?
• Who creates the domain, hosting and analytics accounts, and in whose name are they registered?
• What documentation and training will my team receive at closeout?
• What post-delivery services do you offer and how are they contracted separately?

Pre-start diagnosis

• Gather all proposals received and the emails or chats where something was negotiated.
• Write down what you expect to have at the end of the project in a list of no more than ten lines.
• Identify who will sign and who will review the deliverables.

Signals that it works or not

• Good signal: you can explain in one sentence what is included and what is not.
• Bad signal: the answer to your questions is “we’ll see that later.”
• Measure it yourself: count how many boxes remained empty after the written answers.

A second contrasting example

Concise example. A fictitious company receives a single, very detailed proposal from a recommended provider. Since it has nothing to compare it to, it uses the checklist as a reference: everything is covered except continuity. Instead of seeking another provider, it requests that an annex be added about what happens after delivery. Unlike the first example, here the problem was not the scope, but what came afterward. Invented example.

What to do when something fails

• If, upon review, something is missing from what was delivered, compare it with the written scope and communicate it in writing with the exact point.
• If the disagreement concerns something that was not written, negotiate it as a change, not as a breach.
• If the relationship breaks down, first secure the domain, access credentials and copies.

Common mistakes

• Approving based on price without comparing equivalent scopes.
• Accepting “support included” without knowing what it covers or for how long.
• Not requesting access credentials in the company’s name.
• Assuming content and photos are included.
• Leaving measurement until after launch.

Checklist

• The scope lists pages or functionalities.
• There is a list of exclusions.
• Inputs are defined and who delivers them is specified.
• Deadlines state when they start running.
• Domain, hosting and analytics accounts are in your company’s name.
• It is clear what happens after delivery.