How to compare software development quotes
Never compare development quotes on the bottom line – compare scope and assumptions. Check what's included and excluded, who owns the code, what maintenance costs, and which assumptions the price rests on. Red flags include missing assumptions, prices far below the rest, and fixed price without a prior discovery phase.
Three vendors, the same request – and quotes of SEK 400,000, 650,000, and 900,000. Which is cheapest? Wrong question. The right question is what each quote actually includes, because the price difference almost always comes from vendors having priced different things.
Compare scope and assumptions, not the bottom line
The bottom line is the result of two things you don’t see on the last line: what’s included and what the vendor has assumed. Is design included? Testing? Project management? Launch and deployment? Bug fixes after launch? Is it assumed that you deliver finished copy, a finished visual identity, test data, and fast decisions?
Before you compare anything: make a list of scope items and assumptions, and force every quote into the same structure. Only then are you comparing prices – before that, you’re comparing apples to fruit.
Scenario: three quotes for the same booking system
Quote A at SEK 400,000 assumes design already exists, counts testing as “part of development,” and ends at delivery. Quote B at SEK 650,000 includes design and system testing plus one month of bug fixes. Quote C at SEK 900,000 starts with a preliminary study and includes design, testing, launch, and three months of support.
If you normalize A – adding design for maybe SEK 120,000, real testing for SEK 80,000, and post-launch support for SEK 60,000 – it lands at SEK 660,000. Suddenly the price picture looks different: A and B cost roughly the same, and C’s premium is essentially the preliminary study and the longer support period. The price difference was never a price difference. It was a scope difference.
The question list for every vendor
- What is not included in the price?
- What assumptions does the price rest on – and what happens if they don’t hold?
- Who owns the code, design, and all accounts once the project is done?
- What does maintenance and further development cost per year after launch?
- Who are the people staffing the project, and how senior is the team actually doing the work?
- How are changes during the project handled, and how are they priced?
- What happens in the event of a delay – on your side and on ours?
- What third-party costs come on top: licenses, hosting, payment services?
The answers are often more revealing than the quote itself. Whoever answers all eight clearly and in writing has thought their commitment through.
Red flags
- No assumptions disclosed. The price looks clean but doesn’t define anything.
- Price far below the rest with no explanation. Someone has priced a different, smaller assignment – deliberately or not.
- Fixed price on a loose requirements picture without discovery. Either a large hidden risk premium or scope conflicts down the road.
- “Everything included” with no specification. What’s included is what’s in the contract, nothing else.
- Unclear ownership of code, design, or accounts.
- No questions coming back to you. Serious vendors ask questions before they price – silence means guessing.
Also compare what isn’t in the quote
Price is one of three dimensions. The second is the team: who do you get, how senior are they, and have they built something similar before? Ask to meet the people who will actually do the work, not just the one selling it. The third is the way of working: how often do you get demos, how are time and progress reported, how are decisions made when something’s unclear?
Two quotes at the same price can mean living through entirely different projects. Also call at least one reference per vendor and ask a single question: did the estimate hold – and if not, why?
Build the comparison on total cost
Make a simple table at home: the same scope lines for every vendor, plus the year-one lines for maintenance, hosting, and licenses. Compare the total cost for the first few years – not just the build. It takes an hour and is the best-paid hour in the entire procurement process.
At Weapp, we’d rather submit a quote with ten disclosed assumptions than a polished bottom line – that’s how we’d want to buy ourselves. Want to test your requirements against a structured quote? Get in touch.
Frequently asked questions
Should I always choose the cheapest quote?
No – choose the quote that gives the lowest total cost for what you actually need, from a vendor you trust. The lowest bottom line often rests on the smallest scope or the most optimistic assumptions, and the difference comes back as change orders.
How many quotes should I get?
Two to four is almost always enough. Fewer gives you no point of comparison, more becomes hard to evaluate seriously and costs both you and the vendors' time. Better to put the effort into giving a few selected vendors a good brief than sending a broad request to many.
What does it mean if a quote has no assumptions listed?
Either the vendor hasn't analyzed the assignment in depth, or the uncertainty is being deliberately hidden. Both are bad news: the assumptions are where you see what the price actually covers. Ask for a complete list – a serious vendor already has one.
Is it okay to pit vendors against each other's prices?
You're free to, but it rarely gets you a better deal. Price pressure without a changed scope gets clawed back somewhere else: more junior staffing, stingier interpretations, or lower priority. Better to ask each vendor to justify their scope and assumptions – that's where the real differences are.
What is a discovery phase, and why do agencies want to start there?
A short, bounded preliminary study that defines requirements, priorities, and technical choices before the main quote is delivered. It costs a fraction of the project and makes the price accurate instead of guessed. A vendor wanting to start there is a good sign, not a sales trick.