- A good technical proposal explains your problem before it sells you the solution.
- Be wary of buzzwords with no context, vague estimates and “and much more”.
- Anything that isn’t quantified or specified is something you can’t claim later, but they can certainly bill you for it as an extra.
The document that decides months of work
You’ve just received a technical proposal from a web agency. It’s 15 pages of diagrams, technology lists and a €12,000 price tag. You don’t understand half of it, but it sounds professional and the portfolio looks good.
Signing a proposal you don’t understand is like signing a lease without reading the fine print: what looks clear today can turn into a dispute 3 months from now.
This guide helps you tell a solid proposal from an inflated one and negotiate with real information. You don’t need to know how to code.
What a good proposal looks like
A decent technical proposal has 4 clear parts, almost always in this order:
1. Understanding the problem: the agency shows it understands your business and what you’re trying to solve. It starts with a diagnosis, not with solutions.
2. Proposed solution: what they’ll build, why that technology and how it ties back to your goals. Technology serving the business, not the other way around.
3. Work plan: phases, deliverables for each phase, estimated dates and who does what, with enough detail for you to know what to expect and when.
4. Investment and terms: an itemized price (or at least one broken down by phase), payment terms, what’s included and what isn’t, and warranty terms.
If the proposal jumps straight to technology without talking about your problem, or it’s an off-the-shelf package with nothing tailored, they’re selling you what they have, not what you need.
How to read the technical section without panicking
This is where the jargon piles up. Here’s a small translator for the most common terms:
“Scalable microservices-based architecture”
What it can mean: we’ll use a structure that lets you grow without rebuilding everything.
What it sometimes hides: we’ll charge you for complexity you don’t need, because your site is unlikely to ever see that kind of traffic.
Key question: “How many concurrent users do we expect, and when would we actually need to scale?” If they can’t answer, or the number is modest, you don’t need microservices.
“Headless CMS with a REST API”
What it means: separating content management from the visible part of the website.
Do you need it? Only if you have a technical team that can maintain 2 separate systems, or if you publish the same content on several platforms at once (website, app, screens). We go into more detail in when headless WordPress makes sense and when it’s overengineering. For a standard business website, it’s like buying a truck to pick up bread.
“Continuous integration and automated deployment”
What it means: a system that automatically tests and publishes code changes.
Do you need it? It’s good practice, and many serious agencies already work this way internally. The real question is whether they’re billing it as an extra: paying for it makes sense if there’s ongoing development every week, not if the site gets touched once a month.
“Modern JavaScript framework” (React, Vue, Angular)
What it means: the visible part of your site will be built with technologies designed for fast, interactive interfaces.
Ask: “How does this affect SEO and initial load speed? Is it more expensive to maintain?” Done well, a site like this works beautifully; done badly, it can be a problem for Google.
“AI-powered features”
What it can mean: a chatbot, a smarter search function or automatic text generation.
Ask: “What specific task does it handle, and how much will it cost per month?” These features usually depend on external services billed by usage. If the proposal doesn’t mention that recurring cost, information is missing.
The numbers that matter
In any proposal, look for these specific figures:
Breakdown by phase: a proposal with no breakdown is a black box. Ask how much (in hours, or at least in cost) goes to design, development, testing and project management.
Number of revision rounds included: ask for a specific number, for example “2 rounds of revisions included”.
Support and response times: if maintenance is included, how many support hours per month? How fast do they respond to an issue?
Post-launch warranty: for how long will they fix bugs at no extra cost? Between 1 and 3 months is common; if no period is mentioned, ask.
If a proposal avoids putting numbers on things, it leaves room for interpretations that rarely work in your favor.
Red flags in a proposal
“Comprehensive digital presence solution”
That’s empty marketing. A good proposal says exactly what will be built: “7-page business website, integrated blog, contact form connected to the CRM and on-page SEO optimization”.
“Implementation of agile methodologies”
It can be a good way to work, but on its own it isn’t a benefit. Ask what it means for you: how often you’ll see progress and how much of your time they’ll need. If they can’t spell it out, it’s filler.
An endless list of technologies
A proposal that names 15 different technologies is probably trying to impress rather than inform. Ask which ones are truly necessary and which are there because “we always use them”.
“And much more…” at the end of every section
This is dangerous: it means no limits have been defined. Anything not on the list is either not included (and you’ll be billed separately) or you’ll end up arguing about whether “that’s in scope”.
Deadlines with no buffer
“Delivery in 8 weeks”, with no explanation of what happens if there are delays on your side (missing content, slow approvals) or theirs. Every project hits surprises.
The budget: what to look for
Itemized or lump sum
Some agencies only give a total: “€12,000 for the website project”. That works for small, well-defined projects, less so for complex builds.
An itemized budget lets you negotiate by removing features, compare phase by phase and understand where the money goes. For a reference point, see how much a website costs in Spain.
What’s actually included?
Read the exclusions carefully. Commonly missing: hosting, domain, professional photography, copywriting, ongoing SEO, team training and complex integrations with external systems.
If something important to you doesn’t appear on either of the 2 lists, ask: anything left unspecified tends to end in conflict.
Payment terms
The usual approach is to split payment across 2 or 3 milestones, for example 40% upfront, 30% at an intermediate milestone and 30% on delivery. Be wary if they ask for 100% upfront on a project that runs for several months: if something goes wrong, you have no leverage left.
How to compare 2 proposals
One agency quotes €8,000 and another €15,000. Is the second one much better, or did the first one lowball to win the project?
Compare them on these points:
Functional scope: do they include exactly the same things? An €8,000 proposal that leaves out on-page SEO isn’t cheaper, it’s different.
Technology and maintenance: does one use current, widely adopted technology and the other something outdated or very niche? That decides who’ll be able to maintain the site and what it will cost (we explain it in what it really costs to keep a website running in production).
Assigned team: does one propose a senior designer and 2 developers, and the other a junior generalist? You’ll see it in the result.
Warranties: does one offer 6 months of post-launch support and the other 15 days? That difference is worth something.
Ownership and control: does one hand over the code and all the access credentials while the other “rents” you its platform? That determines your future freedom, and it’s worth putting in writing with these technical clauses your development contract should include.
The lowest price isn’t always the best deal.
Questions to ask after reading the proposal
- “Can you explain this section in business terms? What concrete result does it give me?”
- “What happens if I want to drop this feature? How much does the price go down?”
- “What’s the annual maintenance cost after launch?”
- “Can I talk to one of your clients who did a similar project?”
- “What happens if I need changes after the scope is signed off?”
The answers to these questions tell you more about the agency than the proposal itself.
Time to negotiate
A proposal is the start of a conversation, not a closed document. Almost everything is negotiable: scope, deadlines, payments, what goes in and what comes out.
Negotiate with information, not just on price. Instead of “€8,000 is too much, bring it down to €6,000”, try “What can we remove to get to €6,000 without losing quality?” or “What does the €7,000 difference between your proposal and the other one I have actually get me?”
Professional agencies appreciate clients who negotiate thoughtfully. The ones that only want to close the sale get offended or disappear.
When to turn down a proposal
You should say no when:
- You don’t understand what you’re going to get, even if you trust the agency.
- The price is well below other proposals with no clear explanation (they probably cut it to win the project, and the extras will come later).
- It’s a generic document that barely mentions your project.
- There are more pages about “about us” and “our services” than about your project.
- The payment or ownership terms are abusive.
Saying no isn’t an insult, it’s doing your job properly.
Wrapping up
Reading a technical proposal doesn’t require knowing how to code. It requires thinking like a business owner: what exactly am I buying, how much does it cost, what result do I expect and what risks am I taking on?
If you have a proposal on the table and want a second opinion before you sign, get in touch and we’ll go through it with you. Not to decide for you, but to help you see what you might be missing.