All articles
Detaljan vodičproposalconsultingcross-border

What a web design proposal should answer before you sign

A web design proposal you can compare names the scope and what is excluded, who owns the code and the design, the CMS, who supplies copy and photography, the running costs and payment tied to deliverables.

A web design proposal is worth comparing only when it answers your brief point by point: the scope and what is left out, who owns the code and the design, which CMS you get, who supplies copy and photography, what the site costs after launch and how payment follows delivery. Two proposals for the “same” website that differ by a factor of three rarely describe the same job. Compare those answers first and the price last. Below is the checklist I would use with two to four proposals on the desk, and a method for putting them on the same basis.

What is a web design proposal, and why do proposals for the same site differ so much?

A web design proposal is the written document in which a designer or studio states what they will build, by when, for how much and on what terms. It becomes the basis of the contract, so anything it leaves out becomes a matter of interpretation later. A good proposal answers your questions before you ask them.

Proposals differ mainly in what they include, not in the day rate. One covers copywriting, photography, content migration and support. Another stays silent on all four, so its total looks smaller. On my pricing page I keep two lists, what is always included and what is billed separately, because those items are the reason quotes for the same job look so different.

Proposals also differ in their starting point. A site assembled on a purchased theme and a site designed for your brand are different products, even when both promise “five pages and a contact form”. Proposals differ in who does the work, too: one named person, a team, or a subcontractor you will never meet.

A cheaper proposal is not necessarily worse. Often it is just shorter. Your job is to find out what is missing from it and what adding it would cost.

Does the proposal answer your brief point by point?

The first test of any proposal is whether it answers the brief you sent, one point at a time. If you asked about the CMS, ownership, the timeline and photography, each of those needs its own answer. A proposal that replies with a generic package description has not read your brief, and it will not read your feedback either.

I have seen this test decide a real project. A client in the UK found me through ChatGPT, asking for small boutique agencies or solo designers in Eastern Europe or the Balkans. He contacted several studios and compared their proposals over a weekend. What decided it, he told me, was that my proposal answered his brief point by point: CMS, ownership, timelines and photography.

He also named two other things: that the proposal showed I understood his business, not only the design, and that my prices were public before we ever spoke. Showing that you understood the business and publishing prices are not tricks. Both remove guessing, and guessing is what makes proposals impossible to compare.

So before you read the price, put your brief next to the proposal. Mark every point that got a specific answer, every point that got a vague one and every point that got none. That list tells you more about the next three months than the total does.

What should a website proposal include? The checklist

A website proposal you can compare covers eleven points, and each one has a red flag that tells you something is missing. The table is a reading checklist; the sections below explain the points that cost the most when they go wrong.

What to checkWhy it mattersRed flag
Answers to your briefShows whether anyone read what you needA package description that ignores your questions
Scope, page by page and feature by featureThe only basis for comparing two proposals“Website up to 5 pages” with no description
What is not includedExplains most of the price differenceNo list, or “everything included”
Copy and photographyEither can be half the workNobody named as responsible
CMS and editingDecides who can change a sentence after launchNo CMS named, or “we handle updates for you” only
Ownership of code, design and domainOwnership you cannot exercise is not ownershipCode “licensed” while you pay, domain in the studio's name
Running costs after launchYou compare years, not the first invoice“Maintenance by arrangement”, with no figure
Timeline with conditionsShows what can move the dateA date with no start point and no dependencies
Revision roundsSeparates a change from new work“Unlimited revisions” with no definition
Payment scheduleYour only hold on the project while work is unfinishedThe full amount up front on a project of several thousand euros
Data, contract and lawPersonal data, VAT and jurisdiction cross borders“GDPR compliant” with no detail, no contract offered

Don't ask for every point to be long. Ask for it to exist. One sentence such as “the domain stays registered to your company” is worth more than a page about the technology stack.

When a point is missing, write it down as a question for that studio, not as a minus. How they answer before you sign is a fair sample of how they will communicate during the project.

Scope: what is included, what is not, and who supplies the content?

The scope in a proposal should name every page and every feature, because only then can two proposals be compared line by line. “Home, about, services, contact” is a list of titles. “A contact form that sends the enquiry to two addresses and stores it in your CRM” is a feature with a price.

The list of exclusions matters just as much. Three things are most often assumed rather than written: who writes the copy, who provides the photography and who moves existing content from the old site. On a website, the most common reason for delay is not the build but the content, so a proposal should say who delivers each piece and by when.

This is what a scope with an explicit exclusions list looks like in my proposals, on the example of a fictional web shop:

webica
Document
Proposal
Client
Example Ltd
Valid for
30 days

Proposal: Web shop for Example Ltd

What is included

  • Design and build of the web shop and its pages
  • Card payments connected
  • VAT invoices issued automatically for every order
  • Delivery methods and rates
  • Legal pages: terms, returns and cancellations, privacy, cookies
  • Two rounds of design revisions

In the price, though you did not ask for it

Most others charge for these separately.

  • Product guidesAn article template and categories, linked to the products.Included
  • Animation and data displayMotion that guides people through checkout instead of slowing it down.Included

What is not included

I can do any of this, but it is agreed and charged separately, so nothing is unclear later.

  • Product entryYou get step-by-step instructions; entry can be contracted separately, per product.
  • Product photography and editingA photographer's job, agreed before the build starts.
  • Translation of product descriptionsIt depends on the number of languages and products, so it is estimated separately.
  • Newsletter and ad campaignsThe tools are connected to the shop; the campaigns themselves are separate work.
STU DEVELOPMENT, sole proprietorship for serviceswebica.hr
An excerpt from a sample proposal for a fictional client. The structure is the one your proposal follows.

If you plan to write the copy yourself, ask for the structure first: which sections each page has and roughly how long each one is. Copy written without that frame tends to arrive late and in the wrong shape. The photography question is similar. Either the proposal names a photographer and a cost, or it says plainly that images are yours to supply.

Which CMS, and who edits the site after launch?

The proposal should name the CMS, say who can edit what after launch and say whether you can export the content if you leave. A CMS is the editing interface behind the site, and it decides whether you can change a sentence on a Monday morning or have to send an email and wait.

Ask three questions about it. Is there a licence or subscription, and who pays it? Can you export pages, products and media in a standard format? Do you get training, or a recorded walkthrough you can watch again?

Every website I build is handed over with an editing interface and a short recorded walkthrough. You depend on me only when you decide that is the faster route. If a proposal promises that the studio “handles all updates for you” and mentions no CMS at all, ask whether you will be able to edit anything yourself.

Who owns the code, the design and the domain after handover?

You should own the code, the design files, the hosting account and the domain, and the proposal or contract should say so in writing. If ownership is not mentioned, don't assume either way. Ask in writing before you sign.

For a UK buyer this is not a formality. Under the Copyright, Designs and Patents Act 1988, the author of a work is its first owner, and only an employee's work belongs to the employer by default (legislation.gov.uk, CDPA 1988 section 11, accessed 2 October 2026). The UK Intellectual Property Office says the same about commissioned work: the creator is the first owner, not the client who paid, unless agreed otherwise in writing (GOV.UK, Ownership of copyright works, accessed 2 October 2026).

An assignment of copyright is not effective unless it is in writing and signed by or on behalf of the person assigning it (legislation.gov.uk, CDPA 1988 section 90, accessed 2 October 2026). Other countries have their own rules, and a studio abroad may work under a different law. Whatever the law, a written clause is the safe answer. This is a checklist, not legal advice; for wording, ask your own lawyer.

Ownership also has to be something you can open. At handover I give you the repository, every access credential, the hosting, the domain and the documentation, and nothing stays with me as a bargaining chip. This is how the handover section of my proposals reads:

webica
Document
Proposal
Client
Example Ltd
Valid for
30 days

Proposal: Web shop for Example Ltd

Handover and ownership

With the final payment you receive, with no further conditions:

  • The Git repository with its full history, on your account
  • The hosting account and connected services (payments, delivery, mail) in your name
  • Access to the shop admin and the content management system
  • A database export with products, orders and customers, ready to restore
  • Every credential, key and access token
  • The source code and the editable design files
  • Instructions for running the shop and a recorded training session

Handover does not depend on working together afterwards or on a maintenance contract. Nothing stays with me as leverage.

STU DEVELOPMENT, sole proprietorship for serviceswebica.hr
An excerpt from a sample proposal for a fictional client. The structure is the one your proposal follows.

What does the website cost after launch?

Running costs after launch are hosting, the domain, platform and plugin licences and support, and a good proposal lists them with an approximate yearly figure. Without them you compare only the first year, and a website lives for years.

A custom site has no monthly subscription to the tool it was built in. Hosted platforms such as Shopify, Wix or Squarespace charge one, and that fee belongs in the comparison even when the proposal leaves it out. With WordPress and WooCommerce, ask which plugins are paid and whether their licences expire after a year.

webica
Document
Proposal
Client
Example Ltd
Valid for
30 days

Proposal: Web shop for Example Ltd

What runs on after launch

These are the only costs that carry on once the shop is live. There is no platform licence, because there is no platform to license.

ItemPer year
HostingThe first year is in the project price. After that it is paid yearly.€90
DomainStays with its current registrar and you keep paying it as you do now. It is not transferred and I do not take it over.paid by you, as now
EmailStays with your current provider. Launch changes two DNS records for the site, not your mail.paid by you, as now
Card payments and deliveryFees under your own contracts with the payment provider and the courier, not through me.per order
Platform licenceThere is none. The site is custom built, so there is no monthly subscription to the tool it was made in.€0
Maintenance€50 a month, flat. No annual commitment, 30 days' notice.€600
Third-party plugins and licencesNothing in this scope requires any. If a licensed font or an external service is needed, its cost is quoted before it is taken.€0
STU DEVELOPMENT, sole proprietorship for serviceswebica.hr
An excerpt from a sample proposal for a fictional client. The structure is the one your proposal follows. The running costs are real figures.

Support is a separate line. Mine is from €50 a month, with no annual commitment. Over three years that is €1,800, more than my smallest website project, which is from €1,500. It belongs in the sum as much as the build price does.

The red flag is “maintenance by arrangement”. An arrangement with no figure means you learn the price when something breaks, at the moment you can least negotiate.

Timelines, revision rounds and payment by phases

A deadline in a proposal holds only with conditions: when the clock starts, what moves it and who is responsible for which part. My frames are 3–6 weeks for a website, 6–12 weeks for a web shop and from three months for an app. If copy and photography are not ready, that is planned in before the start date, not discovered in week four.

Revision rounds have to be a number, and the proposal has to separate a revision from a new feature. My proposals include two rounds of design revisions. “Unlimited revisions” sounds generous, but without a definition it turns into an argument about what counts as a revision.

Where revisions happen matters as much as how many there are. Changing an idea in a clickable prototype costs an hour. Changing it three weeks into the build costs three weeks. That is why a proposal should say when you see the design, and in what form, before anything is built.

Payment on a project of several thousand euros should run in phases tied to deliverables. With me the first part is due on signing and the rest as phases are approved, so you never pay much more than has been delivered. The contract amount is in euros; for clients in the UK the proposal also shows an approximate sterling figure at a fixed rate, so it does not drift between proposal and contract.

webica
Document
Proposal
Client
Example Ltd
Valid for
30 days

Proposal: Web shop for Example Ltd

Investment

Total: a fixed amount, agreed before signing. The price does not change for the duration of the contract.For a web shop, the investment is from €3,000, depending on the scope of the project.

Payment follows phase approvals, not the calendar:

InstalmentDue
Advance paymenton signing
Second instalmenton approval of “Build and integrations”
Final instalmenton approval of “Launch”

No instalment falls due because a date has passed, only because you have confirmed a deliverable.

STU DEVELOPMENT, sole proprietorship for serviceswebica.hr
An excerpt from a sample proposal for a fictional client. The structure is the one your proposal follows. The starting figure is the public one from the pricing page.

Cross-border questions: contract, data, VAT and accessibility

When the studio is in another country, the proposal also has to cover four things a local supplier would take for granted: the contract language and law, personal data, VAT and, for EU web shops, accessibility. None of them is exotic. Each needs one clear sentence.

Contract and working hours. Ask for the proposal, the contract and any NDA in English, and for the governing law and courts to be named. My cross-border example is the website for FESCA, a European patient federation based in Belgium: the proposal, the mutual NDA and the contract were all in English. I work from Zagreb on Central European Time, Monday to Friday 09:00–20:00 CET, which is 08:00–19:00 in London.

Personal data. A studio that handles your customers' data acts as your processor. Article 28 of the GDPR requires a written contract with a processor and your prior written authorisation before it brings in another one (EUR-Lex, Regulation (EU) 2016/679, accessed 2 October 2026). The UK GDPR has the same requirement, and the ICO explains what the contract must contain (ICO, Contracts, accessed 2 October 2026).

VAT. A UK business buying services from a supplier that belongs outside the UK normally accounts for the VAT itself under the reverse charge (GOV.UK, VAT Notice 741A, accessed 2 October 2026). In the EU, Article 196 of the VAT Directive makes the business customer liable in the same situation (EUR-Lex, Directive 2006/112/EC, accessed 2 October 2026). The proposal should state prices net of VAT and say which treatment applies. This is not tax advice; confirm it with your accountant.

Accessibility. The European Accessibility Act has applied since 28 June 2025 and covers e-commerce services to consumers in the EU, with microenterprises providing services exempt (EUR-Lex, Directive (EU) 2019/882, accessed 2 October 2026). If you sell to EU consumers and are not a microenterprise, the proposal for your shop should name the standard it is tested against, such as WCAG 2.1 AA, and say whether testing is in the price.

How to compare web design quotes on the same basis

You can compare proposals only after you bring them to the same scope, the same time frame and the same terms. The method takes seven steps and an afternoon.

1. Write down what you need before you open the proposals

List the pages, features and integrations you need on one page. Without it, each studio quotes for something different and the proposals cannot be compared. If you have not asked for proposals yet, send everyone the same list.

2. Build a grid: rows are items, columns are proposals

The rows are your list plus the eleven points from the checklist above. In each cell write “included”, “not included” or “not stated”.

3. Turn every “not stated” into a question

Send the same questions to every studio, in writing. Written answers become part of the proposal, and the way each studio answers is a sample of how it will communicate later.

4. Price what is missing

If a proposal leaves out copy, photography or content migration, ask for a figure or estimate one yourself. Only then do the proposals cover the same scope.

5. Add three years of running costs

The three-year cost is the build price, plus three times the yearly running costs, plus whatever you added in step four. The order often changes here, because a platform subscription and support over three years can outweigh the difference in build price.

6. Compare the deadline and the payment schedule

A deadline with conditions is worth more than a shorter one without them. Payment tied to approved deliverables is worth more than payment tied to dates.

7. Only now compare the totals

If the cheapest proposal is still the cheapest on the same scope, that is good news: take it. If the gap has disappeared, you now know why it was there.

Common mistakes when comparing web design proposals

The most common mistake is comparing totals before comparing scope. Most of the others follow from it.

  • Taking “everything included” literally. Without a list of exclusions, the phrase means nothing. Copy and photography are the first two items to check.
  • Assuming the studio writes the copy. If the proposal does not say who writes it, assume you do, and plan for it before the deadline.
  • Letting the studio register the domain in its own name. Convenient in the first month, a problem the day you stop working together.
  • Leaving running costs out of the sum. If the first year of hosting is in the build price, the second year arrives as a surprise.
  • Paying the full amount up front on a larger project. Payment is the only hold you have on the project while the work is unfinished.
  • Asking for proposals without a list of needs. Three studios then quote for three different websites, and you compare the prices of things that are not the same.

When you don't need a detailed proposal

You don't need a detailed proposal when the job is small, short-lived and touches no customer data. A landing page for a single event, which lives for two months and collects sign-ups through an off-the-shelf form tool, needs a price, a date and a switch-off date, not eleven checkpoints and a three-year calculation.

The same goes for a small budget and a short deadline: an off-the-shelf template will serve you better than a custom build. I work only on custom projects, from €1,500 for a website, so below that I am not the right person to talk to, and I say so openly. For a web shop or an app that carries your sales, there is no exception, because each of the eleven points becomes a cost the first time it is skipped.

FAQ

Why do quotes for the same website differ so much?

Because they almost never describe the same job. The difference sits in copywriting, photography, integrations, content migration, support and whether the site starts from a theme or from a design for your brand. Once you bring the proposals to the same scope and add three years of running costs, the gap either disappears or gets an explanation.

What questions should I ask a web designer before hiring?

Ask who does the work, which CMS you get, who supplies copy and photography, and what you receive at handover. Then ask what the site costs per year after launch, how many revision rounds are included and what payment is tied to. If the studio is abroad, add the contract language, the governing law and how personal data is handled under Article 28 of the GDPR.

Is it normal to pay for a website in full up front?

Not for a project of several thousand euros. Good practice is payment in phases: a first part on signing, the rest as deliverables are approved. That way you never pay much more than has been delivered, and if the work stalls, you lose at most one phase. Paying in full up front only makes sense for a small job with a short deadline.

Who owns the website if the proposal says nothing about it?

Under UK law, the designer owns the copyright in commissioned work unless it is assigned to you in writing and signed. So don't assume anything: ask for the proposal or contract to state that at handover you receive the repository with its history, the design files, the hosting, the domain and every credential. For the legal wording, ask your own lawyer.

Should a proposal from a studio abroad be in English and in euros?

It should be in a language you can sign with confidence, and for a UK or EU buyer that usually means English. The currency matters less than consistency: the proposal and the contract must show the same amount. My contracts are in euros, and UK clients also see an approximate sterling figure at a fixed rate in the proposal.


If you have two or three proposals and can't tell which one is fair, send them to me. In a consulting session we go through what each one actually offers and where the gaps are. Consulting is €60 an hour, deducted from the proposal if we later work on the project together, and if one of the proposals is good, I'll tell you to take it.

About the author

Jurica Stublić

Jurica Stublić

Web designer and developer · 4 years · 50+ projects

I build custom web and mobile apps, web shops and websites, and I stay on the project after launch. Alongside client work I develop my own product: ai.webica.hr.

Read next

One slot open right now, get in touch about working together

If you have an idea worth doing properly, the first step is a 30 minute conversation.

No proposal and no pressure. You tell me what you're building, I ask the questions nobody has asked you yet, and by the end you know whether it's feasible, roughly what it costs and what the next step is. Whether or not we end up working together.

Jurica Stublić u radu na projektu