Two quotes for the same brief are sitting in your inbox. One says 18,000 EUR, the other 54,000 EUR. The instinct is to assume someone is lying. Usually nobody is. Knowing how to evaluate software development proposals starts with accepting that a price means almost nothing until you know what it contains.
We publish our day rates, 150 to 450 EUR per day depending on the profile, so everything below can be checked against our own numbers instead of unverifiable market averages. Anyone learning how to evaluate software development proposals can run the full exercise in half a day. That half day, the week before you sign, decides more than anything that comes after.
This is the method we apply to ourselves when a client puts us in competition.
Why two honest quotes can differ by 3x
Three factors explain almost every gap. Seniority first: a mid-level developer at 300 EUR per day and an architect at 450 EUR do not produce the same work when there is an architecture to design. Scope second: one quote includes automated testing, deployment and a warranty period, the other stops at code handover. The production model last. A fully local team, a fully offshore team and a hybrid model like ours, with steering, quality and contracts in Belgium and an engineering center in Rabat, carry very different cost structures.
A 3x gap can be entirely honest. It becomes a problem when you cannot explain where it comes from.
How to evaluate software development proposals: normalize first
Ask each vendor for three things: days per work package, day rate per profile, and a written list of what is included and excluded. Refuse the opaque fixed price. Fixed price is a billing mode, not a reason to hide the math.
A worked example at our public rates. A 40-day build package with a senior profile at 400 EUR comes to 16,000 EUR. Add 12 days of testing and acceptance at 300 EUR, which is 3,600 EUR, and 5 days of architecture at 450 EUR, which is 2,250 EUR. Total: 21,850 EUR for 57 days, with the scope written down. Bring both of your quotes to this shape. If a vendor refuses the exercise, you just learned something important.
The padding detectors
Three line items give away an inflated quote, or worse, a hollow one.
- Vague lines: integration and miscellaneous, 15 days. A line that cannot be acceptance-tested will not be delivered.
- Missing testing: a quote with no explicit test days moves that cost onto you, after go-live.
- No run budget: who monitors, patches and updates after delivery? A quote that stops on launch day is incomplete, not cheaper.
Project management billed as a percentage with no attached deliverable deserves the same question: what do those days actually produce?
Ownership questions: code, repositories, environments, data
Ask these in writing before you sign, never after.
- Is the Git repository created inside our organization from day one?
- Do the cloud environments run on our accounts, billed directly to us?
- Which third-party licences does the project embed, and who pays for them in three years?
- Do we own the production data, with a documented export path?
- If we end the collaboration, what happens the next morning?
Our answer fits in one sentence: everything belongs to you from the first commit. A vendor who hesitates on any of these questions is engineering their own indispensability.
The reference call: a script that gets honest answers
Ask for two references and actually call them. Past clients answer factual questions honestly. They do not answer questions like were you satisfied. Our script:
- Did the initial budget hold? If not, by how much and why?
- Who picked up the phone when production broke?
- How long did a reported bug take to get fixed?
- What would you negotiate differently in the contract?
- Would you hire them again tomorrow for a new project?
Question four pays the most. Nobody refuses to answer it, and the answer almost always contains the vendor's real weakness.
Red flags that predict a stalled project
- A start date of tomorrow. Competent teams have a backlog. Our earliest start is the request date plus two weeks, precisely because good teams are not sitting idle.
- A 30 percent discount won in a single negotiation, with no scope reduction. If the margin absorbs that, the original quote was inflated.
- No questions about your business during pre-sales. A quote written without understanding the domain will be rewritten, at your expense.
- No work packages with testable milestones. You will discover the real state of the project on delivery day, which is too late.
What a transparent quote looks like
A transparent quote shows days, rates, profiles, included and excluded scope, assumptions, and what happens after delivery. That is what our quote builder on jadev-corp.com/quote produces: you describe your need, it structures an estimate in work packages and days at our public rates, then an engineer reviews it and sends back a formal quotation within one business day. For continuous engagements, our team pods run 15 to 40K EUR per month, itemized the same way.
We have shipped more than 17 projects for more than 10 clients in this format, including a booking platform for airport parking we operate and an industrial platform we engineer. The format has never scared off a serious client. It has scared off unfair comparisons, which was the point.
Where this method stops
Normalization compares numbers, not teams. Two quotes identical in days and rates can hide quality gaps that only the code and the references reveal. A low day rate can cost more through extra days. And the references a vendor hands you are, by construction, their best ones. The method reduces the risk. It does not remove it.
If you want to see what a normalized quote looks like on your own project, describe your scope on jadev-corp.com/quote. You get an estimate in days at public rates, reviewed by an engineer, within one business day. Then put it next to the quotes on your table. That is exactly the exercise this article describes.