The cheapest of your three agency quotes may simply be the one that never mentions testing. Another might price a launch but say nothing about who deploys it. A third might look expensive because it quietly includes everything the others left out.
You cannot compare those documents as they stand. Rebuild them on the same baseline first, then judge them. This guide gives you a normalisation table, a pricing-model comparison, a weighted scoring sheet and a list of questions to send every vendor.
A dev.to checklist on choosing a UK development partner makes the core point briefly: one company may include testing, deployment and documentation, while another charges for them separately (source). It offers no method for resolving that, and it gives no price figures. This article does not supply UK price benchmarks either, because it has no reliable source for them. Your own quotes are the data that matters.
Step 1: Normalise the scope before you look at price
Create one table. Put the scope items down the left and one column per vendor across the top. In each cell, write I (included), X (excluded) or E (extra cost, with the amount if given).
Where a proposal is silent, write X until the vendor confirms otherwise. Silence is where unexpected costs tend to appear.
| Scope item | What to look for | Vendor A | Vendor B | Vendor C | |---|---|---|---|---| | Planning and discovery | Workshops, requirements write-up, estimate assumptions, a prioritised feature list | I / X / E £__ | I / X / E £__ | I / X / E £__ | | UX and UI design | Wireframes, clickable prototype, visual design, number of revision rounds | I / X / E £__ | I / X / E £__ | I / X / E £__ | | Development | Named features, platforms, integrations, admin tooling, user roles | I / X / E £__ | I / X / E £__ | I / X / E £__ | | QA and testing | Manual testing, automated tests, browser and device coverage, who does user acceptance testing | I / X / E £__ | I / X / E £__ | I / X / E £__ | | Hosting and third-party services | Who sets up and pays for cloud hosting, email, payments, maps, analytics, licences | I / X / E £__ | I / X / E £__ | I / X / E £__ | | Deployment | Staging and production environments, release process, domain and SSL setup, data migration | I / X / E £__ | I / X / E £__ | I / X / E £__ | | Documentation | Technical docs, setup instructions, API docs, admin guides | I / X / E £__ | I / X / E £__ | I / X / E £__ | | Maintenance and support | Warranty period for bugs, support hours, security updates, response times | I / X / E £__ | I / X / E £__ | I / X / E £__ | | Change-request handling | How changes are estimated, approved and charged, and whether rates are stated | I / X / E £__ | I / X / E £__ | I / X / E £__ |
Once the table is filled in, add the E amounts to each vendor's headline price. For every X on something you need, ask that vendor for a written price. The result is your normalised total, and it is the only figure you should compare.
Two omissions deserve extra attention. Hosting and third-party costs are often recurring, so they keep arriving after launch. Testing is the other: if a quote does not state it, assume it is not included until the vendor confirms in writing.
Step 2: Choose the pricing model that fits your uncertainty
The checklist says fixed-price contracts suit clearly defined requirements, while time-and-materials arrangements offer more flexibility when requirements are likely to evolve. That is a fair start. The practical question is how much of your product you can describe today.
| | Fixed price | Time and materials | |---|---|---| | Best fit | Well-defined scope, such as a small MVP with agreed screens, or a fixed integration | Evolving scope, such as a SaaS product where user feedback will shape the roadmap | | Budget risk | Sits mostly with the vendor inside the agreed scope, but you carry the cost of any changes | Sits mostly with you, since cost follows the hours spent | | Flexibility | Low. Scope is locked to the specification | High. Priorities can shift sprint by sprint | | Change handling | Formal change requests, usually priced separately | Reprioritise within the budget, or increase it knowingly | | What to watch for | A thin specification that makes every later request a chargeable change; a price padded for risk | No budget cap, vague reporting, and unclear rates per role |
Fixed price works best when you can write acceptance criteria. If you cannot say what "done" looks like for each feature, a fixed price only moves the argument to the change-request stage. A quote that looked cheap then becomes expensive through variations. This pairs well with go http server graceful shutdown: fix the common bugs.
Time and materials suits discovery-heavy builds, but only with controls. Ask for a monthly or sprint-level cap, regular burn reports and a named team with stated day rates. Without those, flexibility turns into open-ended spend.
A hybrid can be a sensible middle for an early SaaS product. This is an inference, not a sourced finding. Pay a fixed fee for a short discovery phase, then decide whether the resulting specification justifies a fixed-price build or a capped time-and-materials one.
Whichever route you take, compare vendors on the same model. If one quotes fixed and another quotes hourly, ask both to price the same defined scope under the same model before you compare.
Step 3: Confirm ownership, documentation and handover before signing
A price comparison means little if you cannot take the code elsewhere. The checklist lists the key questions: who maintains the application, what support exists, who owns the source code, whether you receive technical documentation, and whether another team can take over. Turn each into a written answer rather than a verbal assurance.
Check these points in the contract itself:
- Who owns the custom code, and when does ownership transfer: on payment of each invoice, or only at final payment?
- Which third-party and open-source components are used, and under what licences?
- Will you get access to the repository, hosting accounts, domain and design files, in your own name?
- What documentation is delivered, and in what format?
- What happens if the relationship ends part-way through?
Intellectual property and data-protection terms are legal matters. Take legal advice on IP assignment, licences and any data processing terms, especially if the vendor will handle personal data. The checklist notes that applicable data protection and regulatory requirements depend on the industry, product and information involved, so a generic template will not settle it.
Step 4: Score vendors so price does not dominate
Once the quotes are normalised, score each vendor from 1 to 5 against the same criteria. The weights below are suggestions that total 100. Adjust them to your project, but fix them before you read the proposals so a polished pitch cannot nudge them. For more on this, see a closer look at migrate vpc peering to transit gateway: when it pays off.
| Criterion | Suggested weight | Vendor A (1-5) | Vendor B (1-5) | Vendor C (1-5) | |---|---|---|---|---| | Scope completeness and transparency | 20 | | | | | Price against normalised scope | 15 | | | | | Relevant technical experience | 15 | | | | | Evidence of outcomes and references | 10 | | | | | Testing, security and quality approach | 10 | | | | | Communication and project process | 10 | | | | | Ownership, documentation and handover terms | 10 | | | | | Post-launch support | 10 | | | |
For the price row, one workable method is to score each vendor as 5 × (lowest normalised total ÷ that vendor's normalised total). The cheapest normalised quote gets 5, and the others scale down in proportion. Use the normalised totals from Step 1, never the headline prices.
The weighted result out of 100 is each score multiplied by its weight, summed, then divided by 5. In a spreadsheet with weights in B2:B9 and one vendor's scores in C2:C9, the formula is:
=SUMPRODUCT($B$2:$B$9, C2:C9) / 5
Test it on a dummy column before relying on it.
Also read: related topic: best webdav mount tool for windows: pick and test one
Do not treat a gap of a few points as decisive. Use the score to shortlist and to expose disagreement, then check references and ask the follow-up questions below. The checklist's advice to evaluate every company against the same questions applies here: identical criteria make it harder to drift towards the lowest price or the most convincing sales presentation.
Questions to send every vendor
Send the same message to every vendor so the answers line up with your table. Copy and paste this list:
- Please list what your quote includes and excludes for planning, UX design, development, QA, hosting, deployment, documentation and maintenance.
- Which assumptions underpin your estimate, and what would cause the price or timeline to change?
- What is your process for change requests, and what are your rates by role?
- Which hosting, licence and third-party service costs will we pay, and which are recurring?
- How do you test the product, and how are bugs found after launch handled and priced?
- How do you handle secure coding, access controls, backups and data protection?
- Who will be our day-to-day contact, and how often will we get progress updates?
- Who owns the source code, designs and accounts, and when does ownership transfer?
- What documentation will we receive, and could another team take over from it?
- What support and maintenance options exist after launch, and what do they cost?
- Can you share two relevant case studies and put us in touch with client references?
- How would the team and approach change if we need to scale users, data or integrations?
Clear, consistent answers show how a vendor is likely to work with you. Evasive answers to questions 1, 2 or 8 tell you something too.
In short: if your scope is well defined and you want cost certainty, favour fixed-price quotes and invest your effort in the specification and acceptance criteria. If you expect to learn from users and change direction, favour a capped time-and-materials arrangement, or a fixed discovery phase followed by a build decision. In both cases, choose the vendor with the best weighted score on a normalised scope, not the lowest number on the front page.
