A Familiar Story
Marta, a SaaS founder in the pre‑seed stage, got the green light from an investor with one condition: deliver the first version of the product for no more than 120 k PLN. Before even speaking to a developer, the budget was nailed to the wall.
She started gathering offers. One software house quoted 100 k, another 150 k, a third 200 k. The 100 k offer won the contract because it fit the budget. After three months it turned out that the 100 k project delivered only half the required features, code without tests, and an architecture that needed a rewrite in the next two months.
The budget that was supposed to protect her became a trap.
Why “How Much Does It Cost?” Is the Worst Question to Ask
At first glance the question seems innocent, but it assumes cost is an intrinsic property of the product—like colour or weight. In IT it’s the opposite.
Cost is the result of three variables:
- Scope – what exactly will be built.
- Quality – how well it will be built.
- Risk – what we still don’t know.
If you ask “how much does it cost?” without defining these three, any number you hear is a lie—either deliberately low to win the deal or artificially high to cover unknowns.
The correct order is the reverse: first scope, then estimate, finally budget.
Consequences of Guess‑Work Budgeting
Low Budget = Negative Selection of Vendors
If you tell a software house, “I have 80 k,” two things happen. A reputable vendor who realistically estimates the project at 150 k will simply decline—they know they can’t deliver quality within that budget. What remains are desperate or incompetent providers who say “yes” to anything just to sign a contract.
This phenomenon is called negative selection. The lower the budget, the poorer the average quality of vendors willing to accept it. The upfront saving turns into technical debt, delays, and a blown‑out budget for fixes.
High Budget = Overpaying
Conversely, if you have a 300 k budget but the real cost is 150 k, without a transparent estimate you’ll still pay the full 300 k. The vendor has no incentive to lower the price because you have already dictated the amount.
No Benchmark = Chaos
The worst scenario: you have no budget and no scope. Every proposal is compared to a different proposal, not to the reality of the project. The winner is the one who tells the most compelling story, not the one who accurately estimates the work.
Correct Process: From Scope to Budget
Here’s a step‑by‑step process that protects both the client and the vendor:
- Define the scope, even loosely – You don’t need a 50‑page requirements document. Just a list of what the system should do, key integrations, and who the users are. Even bullet points in a Google Doc are better than “just build me an app”.
- Run a discovery phase (or explicitly skip it) – If the scope is vague, commission a separate discovery sprint. It costs 5–15 k but pays off many times over. Discovery turns “build me an app” into a concrete backlog with estimated user stories.
- Ask for an estimate with assumptions – A good estimate isn’t a single number. It includes:
- Work broken down into phases.
- Assumptions that must hold.
- A list of risks and unknowns.
- Variants: MVP, extended version, full version.
- Decide on the budget – Only now do you have enough data to choose. You’ll know, for example, that the MVP costs 100 k, the full product 180 k, and a risky accounting‑system integration may add 20 k. You can then pick a variant or negotiate scope.
How to Read a Software House Offer – Red Flags
A trustworthy offer looks like this:
- Phase breakdown – discovery, design, development, QA, deployment.
- Assumptions – what the client must provide, what the vendor will handle.
- Risk buffers – explicit notes that a certain area is uncertain and may affect cost.
- Scope description – clearly states what will be delivered and what is out of scope.
Red flags:
- A single lump‑sum amount with no breakdown.
- No assumptions or boundary conditions.
- “Guaranteed price” with no scope description.
- No mention of quality standards, testing, documentation.
- Time pressure tactics (e.g., “offer valid until Friday”).
If the offer doesn’t tell you exactly what you’ll get for the price, it isn’t an offer – it’s a guess.
Transparent Pricing Builds Trust
Pricing is more than a number; it’s a communication tool. When a vendor presents a phased breakdown with assumptions and risk buffers, they demonstrate that they understand the project and think about it realistically, not wishfully.
As a client, you have the right to expect transparency. You should see not only “200 hours” but also what will be produced in those hours, what assumptions were made, and what risks were accounted for.
Transparent pricing lets you make an informed decision. You don’t need to be a CTO to understand what you’re paying for; the offer should be written in plain language, not technical jargon.
Checklist: Preparing for a Conversation with a Software House
Before you send an RFP, run through this list:
- I have a written scope – even bullet points. I know what the system should do.
- I have priorities – I know what is must‑have vs nice‑to‑have.
- I have examples – screenshots, competitor references, descriptions. This helps the developer grasp context.
- I understand the risks – I know which integrations are complex, which data is dirty.
- I did not state a budget – I talk about scope, not price. I set the budget after the estimate.
- I plan a discovery phase – if the scope is unclear, I reserve budget for a separate analysis sprint.
- I check references – not just portfolio, but client feedback on collaboration.
Summary
An IT project budget should be the result of estimation, not its starting point. Setting a price before you know the scope guarantees a bad decision: you either overpay, get sub‑par quality, or hire the wrong vendor. Follow the process of defining scope, running discovery, requesting an estimate with assumptions, and only then fixing the budget. If a software house cannot provide a transparent, phased estimate with risk buffers, treat that as a red flag.