Why does the same project cost SEK 200,000 at one agency and SEK 2 million at another?
The price gap is rarely about the hourly rate and almost always about how much vendors read into the assignment. A low bid often prices a subset of the work, assumes finished specifications, and skips testing, security, and maintenance. A high bid accounts for the full ambition level. You're not actually comparing the same project.
You send the same request to three agencies and get back SEK 200,000, SEK 700,000, and SEK 2 million. Your first reaction is that someone’s trying to cheat you. Almost always, the explanation is more mundane: the three priced three different projects, even though they read the same brief. The price gap is a scope gap disguised as a pricing question.
The hourly rate is rarely the explanation
Swedish agencies mostly charge between SEK 900 and 1,400 an hour. That range doesn’t explain a tenfold difference in the total. What differs is the number of hours – and the number of hours is driven by how much the vendor reads into the assignment. A loose set of requirements is like a blurry photograph: everyone sees the same image but fills in the details differently. The optimist sees the simplest possible solution; the experienced one sees everything it takes to hold up in production.
What a low bid usually leaves out
A suspiciously low price is rarely a gift. Usually, it’s missing items that still need to be done – they just show up later, as extras. What most often gets left out:
- Testing and stabilization. Getting something to work in a demo is a fraction of getting it to hold up under real use.
- Design worth the name. “We use a template” can mean your product looks like a thousand others.
- Error handling and edge cases. What happens when the connection drops mid-payment? That’s where the hours hide.
- Security and GDPR. If personal data is handled, requirements apply that don’t show up in a glossy quote.
- Maintenance after launch. The price covers the build – then a recurring cost begins that no one mentioned.
A serious vendor lays out its assumptions. If they’re missing, it’s not because the assignment is simple – it’s because the uncertainty is being hidden, whether deliberately or out of sheer haste.
Ambition level is the other half
Even with everything included, two honest quotes can still differ substantially, because “an app that does X” can be built at wildly different ambition levels. Three areas drive most of it:
UX and design. A functional but soulless product costs a fraction of a polished experience with its own visual language, micro-interactions, and tested flows. The difference doesn’t show up in the requirements list, but it decides whether users stick around.
Testing and quality. Automated tests, code review, and a real QA process cost hours now and save expensive mistakes later. A low bid often skips them – the bill arrives as instability after launch.
Scalability. A solution built for a hundred users differs architecturally from one built for a hundred thousand. Build it cheap and lean, and you’ll have to rebuild once things start going well, which ends up costlier than doing it right from the start.
A worked example
Say quote A, at SEK 250,000, assumes finished design, counts testing as “part of development,” and ends at delivery. Normalize it – add real design for maybe SEK 150,000, proper testing for SEK 90,000, and three months of maintenance for SEK 60,000 – and it lands around SEK 550,000. Suddenly it looks like quote B. The price gap was never a price gap. The point: force every quote into the same structure before you compare a single number.
The questions that reveal what’s actually included
Send the same list to every vendor and compare the answers rather than the totals:
- What is not included in the price?
- What assumptions is the price based on, and what happens if they don’t hold?
- Does it include design, testing, launch, and post-launch bug fixes?
- Who owns the code, design, and accounts once the project is finished?
- What does maintenance and further development cost per year?
- Who staffs the project, and how senior are they?
Whoever answers all of this clearly and in writing has thought their commitment through. Whoever gets vague has either not analyzed the assignment or doesn’t want to show where the uncertainty lies.
At Weapp we’d rather submit a quote with ten stated assumptions than a tidied-up total. Want to test your requirements against a structured review? Take a look at our services or get in touch with a short description.
Frequently asked questions
Is the expensive quote always more serious?
Not automatically. A high price can reflect real ambition on UX, testing, and scalability – or just overhead and an expensive sales organization. What matters is whether the quote lays out what the money goes toward. An expensive quote without a breakdown is just as hard to trust as a suspiciously cheap one.
Can I ask a cheap vendor to match an expensive quote?
You can ask them to price the same scope and assumptions, but don't just push the number down. Price pressure without changed content gets recovered somewhere else – in more junior staffing, leaner interpretations, or later add-on invoices. Instead, have everyone price the exact same list.
What's the most common hidden item in a low bid?
Testing and stabilization after launch. An app can look finished in a demo but need weeks of bug fixing before it can withstand real users. If that's not included, it arrives as an add-on – or as a product that never quite works.
How many quotes should I compare?
Two to four is enough for most projects. Fewer gives you no reference point, more becomes hard to evaluate seriously. Spend your energy on a good brief for a few chosen vendors rather than a broad request to many.
Who owns the code if I choose the cheapest option?
That has to be in the contract, regardless of price. Some cheap setups keep code or accounts with the vendor, which locks you in. Confirm that you get full ownership of the code, design, and all logins once the project is finished.