Web and app development quotes: the definitive guide for agencies and freelancers

You build websites and apps that work. Your clients are happy with the result. But before starting the project, you go through the same ordeal as always: how much do I charge for this?

The web development quote is one of the hardest documents to put together in the world of digital services. The scope is fuzzy, the client doesn't know exactly what they want, timelines stretch out and there's always “one more thing” at the end. If you don't have a clear system, every project becomes a box of surprises — usually unpleasant ones.

This guide is for web development agencies, freelancers and digital studios who want to quote better: faster, with more clarity and with a higher chance of closing the project at a good price.

The fundamental problem with web development quotes

Unlike selling a physical product, quoting a web development project means selling something that doesn't exist yet. The client has an idea — sometimes vague — and you have to estimate how much time and resources are needed to make it real without having done the full technical analysis.

This mismatch produces three common problems:

Scope creep: the original project grows endlessly because the client keeps adding features that are “no big deal”
Quotes that are too low: to win the project you estimate tight and then work at a loss
Expectation mismatches: the client expected one thing and you delivered another (both valid, but different)

The solution isn't to be more expensive or cheaper. It's to quote better.

The four pricing models in web development

Before putting together any quote, you must decide which pricing model you're going to apply. Not all projects are the same, and the model you choose will determine how you calculate the price and how you present it.

Fixed price

The client pays a fixed amount for a defined scope. It's the model most clients ask for because it gives them certainty over the total cost. It's also the riskiest for the developer if the scope isn't perfectly defined.

When to use it: projects with very clear, closed requirements. A five-page corporate website with a predefined design. A landing page. A specific module of concrete functionality.

The most common mistake: accepting a fixed price when the scope is ambiguous. If the client says “I want a customer portal with custom features”, that's not a scope. It's an idea. Don't quote a fixed price until you have the concrete requirements.

Time & materials

The client pays for the actual hours worked at an agreed rate. The risk is shared: if the project grows, the cost grows proportionally.

When to use it: maintenance and evolution of existing systems. Projects with changing requirements. Initial technical exploration phases.

The problem: many clients are afraid of the hourly model because they feel they lose control of the cost. The solution: set an estimated maximum budget and track it transparently. “We work by the hour with a cap of $20,000. If we see we're getting close, we'll let you know before continuing.”

Monthly retainer

The client pays a fixed monthly fee for a reserved bank of hours. Ideal for clients who need continuous evolution of their digital product.

When to use it: clients with a digital product in production who need constant improvements, technical support and new features on a recurring basis.

Advantage: recurring, predictable income for your agency or freelance business. One of the healthiest metrics you can have in a digital services business.

By sprint or phase

The project is divided into phases or sprints of two to four weeks, each with a concrete deliverable and a closed price. At the end of each sprint the client decides whether to continue.

When to use it: medium or large projects where the client wants visibility and control. It's the most balanced model for complex projects.

Advantage: you reduce your risk because you bill by phase, the client sees real progress and the project can be adjusted based on the learnings of each iteration.

How to calculate the price of a web project

Whether you use fixed price or by sprint, you need to estimate the effort as accurately as possible. This is the process that works.

Step 1: break the project down into tasks

Don't quote the project as a whole. Break it down into functional modules and concrete tasks. For a corporate website with a blog and contact form, the list might be:

Requirements analysis and wireframing — 4 hours
UI design in Figma: home + interior pages — 12 hours
Frontend build and development: home — 6 hours
Build: interior pages (×4) — 8 hours
Blog integration with CMS — 8 hours
Contact form with email notification — 3 hours
Basic on-page SEO: robots.txt, sitemap, metas — 3 hours
Deploy and hosting configuration — 2 hours
Client training — 2 hours
Revisions and QA — 4 hours

Estimated total: 52 hours. At a rate of $60/hour, the base price would be $3,120.

Step 2: apply a contingency factor

Projects always take longer than estimated. Unforeseen meetings, last-minute changes, unexpected bugs, the extra training that wasn't in the plan. The contingency factor covers all that.

Well-defined projects: add 15–20% on top of your base estimate
Projects with less clear requirements: add 25–35%
Projects with technology new to you: add up to 40–50%

In the previous example: 52h × 1.20 = 62.4 hours → $3,744. It's more honest than selling yourself short and then having to ask for more money or work at a loss.

Step 3: add external costs

Development quotes frequently forget the costs that aren't working hours:

Licences for commercial plugins, themes or libraries
Design tools (Figma, Adobe CC)
Third-party services: Stripe, SendGrid, payment APIs
First-year hosting and domain
Stock images and graphic resources

These costs should appear broken down in your quote, not mixed in with your hours. The client has to understand what they're paying and to whom.

Step 4: consider the cost of acquiring the client

How many meetings have you had to reach this quote? Have you put together a prior technical proposal? Have you travelled for an in-person meeting? That time has value too. If you invested six hours in the sales process for a $3,000 project, your real margin is no longer what you calculated.

Some freelancers and agencies charge for a paid “analysis and proposal” phase before presenting the final quote. If the project is complex — above $15,000 — this makes complete sense.

What a web development quote must include

A good quote isn't just a number. It's a document that manages expectations, sets the framework for the relationship and protects both parties.

1. Project description and context

Show that you've listened to and understood what the client needs. Don't copy and paste what they told you: synthesise it in your own words and include the business goal behind the project.

“The goal of this project is to replace the manual client registration process with a web platform that automates onboarding and document submission, reducing onboarding time from three days to under two hours.”

That shows you're not a task executor. You're a strategic partner.

2. Detailed scope: what's included and what's not

List all the concrete deliverables: screens, modules, features, integrations. And add an explicit “out of scope” section.

This section is your best defence against scope creep. If a new request comes up, you can point to the contract: “That wasn't in the original scope. We can add it with an additional change quote.”

3. Technology and stack

State the main language, framework and tools you'll use. This isn't just for the technical client: it reassures them that you've thought about the solution, not just the price.

4. Phases and timeline

Divide the project into phases with approximate dates. If the project has dependencies on the client — providing you with text, images or access — include them explicitly in the timeline. If the client is late, the deadline moves.

5. Itemised price

Present the price by phase or by functional module, not as a single block. This has several advantages: the client understands where the price comes from and perceives it as fairer; if they need to adjust the budget, they can negotiate by removing modules instead of pressuring you to lower the overall rate; and on large projects, it makes internal approvals easier.

6. Payment terms

For web development projects, the industry standard is:

30–50% at the start of the project (deposit)
30–40% at an intermediate milestone (design delivery or first working version)
20–30% on final delivery

Don't start any project without a deposit. It doesn't matter how big the client is or how convincing the relationship seems. The deposit is the proof that the project is real.

7. Intellectual property

Specify when ownership of the code transfers to the client. The norm: on receiving the final payment. While there are outstanding invoices, the code remains yours.

8. Post-delivery maintenance and support

State what happens after delivery: is there a warranty period? What does it cover (bugs in the delivered code, yes; new features, no)? Do you offer a monthly maintenance plan? If so, include it as an option in the quote. Maintenance is one of the most profitable and predictable revenue lines for any agency or freelancer.

9. Number of revisions included

Define how many rounds of revisions are included in the price and what happens if the client requests more. Without this clause, a project can turn into an infinite loop of “one more thing.”

10. Quote validity

State how long the offer is valid for. Thirty days is standard. After that, prices may change.

Scope creep: how to prevent it from the quote

Scope creep — the unplanned growth of the scope — is the number one cause of negative profitability in web development projects. And it starts before writing a line of code: it starts in the quote.

These are the clauses you should always include:

Explicit change order: any feature not included in the original scope requires a written change order with an agreed price before being executed
Definition of bug vs. new feature: a bug is something that doesn't work as agreed; a change to how something already implemented works is a new feature and is billed separately
Limit on included meetings: in fixed-price projects, define how many meeting hours are included; meetings cost money and should be in the price

You don't have to be inflexible. You have to be clear. A client who understands the rules of the game from the start respects them. A client you never told the rules to will keep asking for “small things” indefinitely.

How to present the quote to win more projects

Always present three options

Instead of a single proposal, present three versions of the project:

Basic option: the essential features for the project to meet its minimum goal
Standard option: the one you actually recommend (usually the middle one)
Premium option: all of the above plus additional features or a higher level of finish

This has two effects: the client goes from deciding whether to hire to deciding which to hire. And the middle option — the one you most want to sell — is perceived as the most reasonable through the psychological anchoring effect.

Add the ROI when possible

A $15,000 quote can seem expensive until the client understands that the system you're going to build will save them $3,000 a month in manual work. In five months it's paid off. Put the figures on the table when you have them.

Send a professional PDF, not an email with prices

The way you present your proposal communicates your level of professionalism before the client has read a single line. A well-designed PDF with your brand identity, clear structure and careful language conveys trust. An email saying “the price would be about $8,000, more or less” does exactly the opposite.

Tools like DealForge let you generate proposals in PDF format with your branding, a phased pricing structure and legal terms, ready to send directly to the client from the platform — with status tracking included so you know when they've opened it and when to follow up.

Common mistakes when quoting web development projects

Quoting without clear requirements

If the client doesn't know exactly what they want, you can't know how much it will cost. In that case, the solution is to charge for the analysis phase before giving the final quote. Many agencies offer a one-week “discovery sprint” at a fixed price that includes interviews, wireframes and technical specification. At the end of that sprint, the quote is much more precise and the client understands the scope better.

Not charging for management time

Meetings, clarification emails, change management, coordination with external suppliers... all of that is billable work. If you don't include it in the price, you're giving it away. A project with weekly meetings over three months has more than twenty hours of management that someone has to pay for.

Lowering the price to win the project

Reducing your rate to compete with cheaper proposals is a trap. You attract the most price-sensitive client in the market, work with a lower margin and have less budget to do a good job. Price competition in development services is a race to the bottom that no one wins. Better to lose that project and devote that time to clients who value what you offer.

Not defining payment milestones

If you charge everything at the end, your cash flow suffers and you increase the risk of the client haggling over the last invoice or disappearing. Payment milestones distribute the risk across the project.

Forgetting licences and external tools

A $200 plugin can seem irrelevant on a large project, but if you have five projects like that a month, that's $1,000 coming out of your pocket. Every external cost should be in the quote, with its real or estimated amount.

Structure of a web development quote

So you don't start from scratch on every proposal, this is the structure you should use as a base:

Cover: your logo, project name, date, client details
Executive summary: project goal and proposed approach in two or three paragraphs
Proposed solution: technical description, tech stack, architecture decisions
Project scope: included modules and features, broken down
Out of scope: what the quote explicitly does not include
Work plan and timeline: phases, milestones and delivery dates
Investment: price broken down by phase or module, VAT, payment terms and deposit
Maintenance and support: what happens after delivery and maintenance contract options
About us: a brief description of your agency or profile, relevant projects, technologies mastered
Next steps: what to do to get started (signature, deposit, kick-off meeting)

With DealForge you can save this structure as a template and reuse it on every new proposal, customising only the content specific to each client. What used to take you three hours you have in thirty minutes, with a more professional result.

How to follow up without being a pain

You sent the quote. The client said “I'll look at it and get back to you.” Four days have passed. What do you do?

A reasonable follow-up sequence for web development proposals:

Day 1–2 after sending: a brief email to confirm receipt and ask if they have questions
Day 5–7: a value-added follow-up: a relevant insight for the project, a question about their priorities, something that shows you're still thinking about their case
Day 12–15: last contact before the proposal expires; mention the expiry date naturally, without pressure

If after fifteen days there's no reply, the client isn't ready or has already chosen someone else. Close the loop and move on. There's no worse investment of time than chasing someone who doesn't want to buy.

Conclusion: quote like a partner, not a supplier

The difference between a quote that wins the project and one that doesn't is usually in the details: in how you understand the client's problem, in how you define the scope, in how you protect your time and in how you present the value of what you offer.

A good web development quote isn't just a pricing document. It's the project's first real delivery: it demonstrates your analytical capacity, your mental order and your professionalism. If the quote already impresses, the project is off to a great start.

Work on your template, define your rates clearly, always apply the contingency factor and be explicit with the scope. Those four things alone will improve your close rate and your profitability more than any price cut.

Want to create web development proposals in a professional format, with your branding and sent directly to the client? Try DealForge and stop wasting hours on Word documents so you can spend them on what really matters: building projects that work.