How to compare web and app agency proposals

Start from the same brief

Proposals can only be compared if they answer the same question. Before you ask for them, write a short brief: who your customers are, what the website or app must help them do, the main pages or features you expect, what you already have (brand, texts, photos, an existing system), your deadline, and who decides on your side. Send the same brief to every agency.

If an agency's proposal answers a different project, ask them why. Sometimes they have spotted something you missed, which is valuable. Sometimes they are selling what they usually sell. Either way, you want to know before you compare.

Put them side by side

Make a simple table with one column per agency and one row per topic: scope, exclusions, stages and dates, revisions, ownership, payment schedule, support after launch, and who will work on the project. Fill it in from each document. Empty cells are the most useful part of the table: they show you what each agency did not say, and what to ask.

Scope lines you can check

A good scope is written so that, at the end, you can go through it line by line and tick each item. "Modern responsive website" cannot be checked. "Eight pages: home, about, four service pages, contact, privacy; booking form sent to two email addresses; French and Arabic versions" can.

For an app, look for the main screens and what a user can do on each, the types of user and their permissions, the integrations (payments, email, maps, messaging), and the platforms: web, iOS, Android. If two proposals describe the scope at very different levels of detail, the less detailed one is not necessarily cheaper in the end. It may simply have left the hard parts for later.

What is not included

Exclusions matter as much as inclusions. A serious proposal says clearly what it does not cover: writing the texts, photography, translation, entering content, paid advertising, third-party fees such as hosting, domain, app store accounts or paid plugins, and data migration from an old system. If a proposal lists no exclusions at all, assume they exist and ask for them in writing.

The cheapest proposal is often the one that excludes the most. Read the exclusions before you read the total.

Timeline and its assumptions

Every timeline rests on assumptions, usually about you: how quickly you send content, how quickly you approve each stage, how many people need to agree. Look for proposals that split the work into stages with dates, and that say what they need from you and when. A date with no stages behind it is a hope, not a plan.

Ask each agency what happens to the dates if you are late with content, and what happens if they are late. The answers tell you a lot about how they run projects.

Revision rounds

Check how many rounds of revisions are included at each stage and what counts as a revision. Changing the colour of a button is a revision. Adding a new section or a new feature is a change request, and should be quoted separately before any work starts. "Unlimited revisions" sounds generous, but it often means nobody has defined when a stage is finished.

Who owns the code, the domain and the accounts

This row in your table should be filled in plainly for every agency. The domain, hosting, app store accounts, analytics and Google Business Profile should be in your company's name. The proposal should say when the source code and design files become yours, usually on full payment. If an agency keeps the domain in its own name or will not hand over the code, you are renting, not buying.

Payment tied to milestones

A healthy payment schedule follows the work: a deposit to start, then payments as stages are delivered and approved. You pay for what you can see, and the agency is paid as it delivers. Be careful with proposals that ask for everything upfront on a large project, with nothing delivered before the end. A short, fixed discovery phase paid in advance is a different case: it is small, defined, and ends with something you can use.

Support after launch

Compare what each agency offers once the site or app is live: hosting, backups, security updates, uptime monitoring, small changes, and how you report a problem. Look for written response times rather than "we are always available". If support is not mentioned at all, ask, because every website and every app needs it.

Questions to ask on the call

Who exactly will work on my project, and who is my contact day to day?
What do I approve at each stage, and how?
Which part of this scope do you think is the riskiest?
What do you need from me, and by when, for the dates to hold?
How do you handle a change I ask for in the middle of the project?
Can I see a similar project and hear how it went, not only how it looks?
What happens in the first month after launch?

Red flags

A vague scope that you could not check at the end of the project.
Promised rankings, traffic, sales or a number of customers. Nobody controls those, and an honest agency measures them with you instead.
Full payment upfront for a large project.
The domain or accounts registered in the agency's name.
No stages, no dates, no exclusions.
Pressure to sign quickly, or a discount that expires tomorrow.

How we work at Qafza

Our proposals include a written scope you can check, a list of exclusions, stages with dates, two revision rounds per stage, payments tied to milestones, and the domain, accounts and code in your company's name on full payment. We promise the scope, the dates and the quality, not rankings or sales, and we measure enquiries, bookings and rankings with you after launch. If you are comparing proposals, send us the same brief you sent the others.