Two proposals can describe the same app, platform or AI workflow yet represent very different amounts of work. Put the prices side by side and you may be comparing a complete delivery plan with a hopeful estimate wearing a smart jacket.
Before choosing a software development company in the UK, look beyond the total at the bottom of the page. A useful comparison should show what each supplier plans to deliver, what they need from you and what happens when reality introduces itself.
Start by normalising the proposals
Suppliers structure proposals differently. One may include discovery, design and post-launch support in a single figure. Another may quote development alone, with everything else listed separately—or left unstated.
Create a comparison sheet with one column per supplier and rows for:
- Discovery and requirements
- User experience and interface design
- Technical architecture
- Development
- Data migration and integrations
- Testing and quality assurance
- Security and accessibility
- Deployment and app store submission, if relevant
- Training and documentation
- Project management
- Hosting and third-party services
- Warranty and ongoing support
- VAT
Mark each item as included, excluded, optional or unclear. Don’t treat a blank cell as included. Ask.
This first pass often explains a surprising price gap without requiring any detective music.
Compare the scope, not just the feature list
A feature name rarely defines enough work to price it accurately. “User accounts”, for example, could mean a basic email login or a fuller system covering multi-factor authentication, social sign-in, roles, account recovery, audit records and administrator controls.
For every important feature, check whether the proposal describes:
- Who will use it and what they need to do
- Supported devices, browsers and operating systems
- User roles and permissions
- Data to be created, viewed or changed
- Integrations with existing systems
- Important edge cases and error behaviour
- Relevant performance, security and accessibility requirements
- Acceptance criteria—how you’ll agree that it works
Mock-ups, user stories and workflow diagrams can reduce ambiguity. They don’t need to answer every question before work starts, but the proposal should explain how unresolved details will be investigated and agreed.
Put assumptions and exclusions under a bright light
Assumptions keep estimates manageable, but they also move risk between you and the supplier. Common examples include the availability of an API, the quality of existing data, the number of design revisions or the time your team can give to decisions and testing.
Read exclusions with equal care. Content entry, data cleaning, penetration testing, accessibility audits, device testing, hosting configuration and third-party licence costs may sit outside the quoted price.
Ask each supplier:
- Which assumptions have the greatest effect on cost or timing?
- What happens if an assumption proves false?
- Which work will we need to arrange separately?
- What information could improve the estimate before we commit?
A candid answer is more useful than artificial certainty.
Understand the commercial model
A fixed price offers budget certainty only when the scope and change process are clear. Time-and-materials work can suit evolving products, but you’ll need visibility of rates, progress and spending controls. Some projects use both: a fixed-price discovery stage followed by phased delivery estimates.
Check:
- Whether prices include VAT
- Day rates or role-based rates for additional work
- Payment stages and deposit requirements
- What triggers an invoice
- How changes are estimated and approved
- Whether unused contingency remains yours
- Whether estimates are ranges, caps or commitments
- Third-party and recurring costs
Compare the likely total cost of reaching a usable, supported release—not merely the initial build figure.
Examine the delivery stages
A credible plan should show how the team moves from uncertainty to working software. The labels may vary, but you should be able to identify discovery, design, development, testing, launch and support.
Look for tangible outputs at each stage, such as a prioritised backlog, prototype, architecture decision, tested release or deployment plan. Check when you’ll see working software and how often you’ll review progress.
If the proposal uses agile software development, ask what that means in practice. How long are iterations? Who prioritises the backlog? How are budget and scope monitored? “Agile” should describe a working method, not excuse an absent plan.
Also identify decision points. A staged engagement may let you review evidence after discovery or a prototype before committing the full build budget.
Map the dependencies
Software projects rarely operate alone. Delivery may depend on your internal specialists, a legacy supplier, payment provider, app store, hosting platform or another system’s API.
Record each dependency with:
- Its owner
- The date it is needed
- Any access or approval required
- The effect of delay
- A possible alternative
For mobile app development, include Apple and Google accounts, review processes, device support and store assets. For web app development, consider domains, hosting, analytics, identity providers and browser support.
Dependencies cannot always be controlled, but they can be made visible.
Give AI claims an extra check
“AI integration” can cover anything from calling a hosted model to building a reviewed workflow with retrieval, permissions, evaluation and human oversight. Ask what work the phrase actually includes.
A sound proposal should address:
- The task AI will perform and how success will be assessed
- What data is sent to a model or external provider
- Security, privacy and retention considerations
- How unreliable or unsuitable outputs will be handled
- Whether a person reviews consequential results
- Model, hosting and usage costs
- Monitoring and evaluation after release
- Dependence on a particular model or vendor
No supplier can promise perfectly accurate generative output. What matters is how the workflow limits risk, measures usefulness and responds when the model gets something wrong.
Confirm ownership and access
Don’t wait until handover to discuss intellectual property. The contract should state who owns the bespoke source code, designs, documentation, data and configuration created for the project, and when ownership transfers.
Also check your rights to third-party and open-source components. These may remain under their own licences rather than becoming your property.
Ask whether you will receive:
- Access to source code repositories
- Deployment and hosting access
- Design source files
- Technical and user documentation
- Credentials held in an appropriate password manager
- Build and release instructions
- A record of third-party services and licences
Ownership on paper matters. Practical access matters too.
Look past launch day
A launch warranty usually covers defects in the agreed scope for a defined period. Ongoing support is broader: monitoring, updates, operational help, security maintenance and improvements.
Compare the support hours, response targets, severity definitions, communication channels and exclusions. Find out who handles hosting incidents, third-party failures and operating system or browser changes. Ask how urgent issues are prioritised and how non-urgent improvements enter the roadmap.
If support is optional, include its likely cost in your comparison.
Score evidence as well as promises
A tidy scoring model makes the decision easier to explain. Choose criteria that reflect your project, weight them by importance and score each proposal consistently.
Possible criteria include:
- Understanding of the problem
- Completeness and clarity of scope
- Delivery approach
- Technical judgement
- Management of risk and dependencies
- Relevant team capability
- Communication and governance
- Ownership and handover
- Support arrangements
- Total expected cost
Price should have a place, but not every place. Record the evidence behind each score and list questions that remain unanswered.
Make the uncertainties comparable
The best proposal isn’t necessarily the longest or cheapest. It is the one that gives you a sensible route to the outcome, makes uncertainty visible and allocates responsibility fairly.
Before deciding, give each supplier the same clarification questions and allow them to update their proposal. You’ll get a fairer comparison—and a useful preview of how they communicate when details matter.
If you’d like a second pair of eyes on a proposal or need to shape a clearer brief before approaching suppliers, talk to Atlas-James.