Anyone comparing several offers for the same IT project quickly runs into a challenge: the numbers can't simply be placed side by side. One offer states a fixed price, another a daily rate with an estimated number of days, a third only a non-binding price range. Anyone who doesn't correctly classify these models ends up comparing apples to oranges — and making a decision on the wrong basis. This guide explains the common offer types and shows what really matters when comparing them.
The offer types at a glance
Fixed price
The total amount for the agreed scope is fixed from the start. That gives planning certainty, but assumes the scope was already described clearly enough when the offer was made. If the request stayed vague, the provider either builds in a generous risk margin, or you'll face costly add-ons later for anything not clearly stated in the offer. A fixed price therefore works best for clearly bounded, well-described undertakings.
Hourly or daily rate
Here the effort is compensated, not the outcome: a fixed rate per hour or day, multiplied by actual time spent. This model suits work whose scope can't be fully fixed in advance, such as exploratory consulting or ongoing support. The downside: total cost is only known at the end, not beforehand. A serious hourly or daily-rate offer should therefore still include at least an estimate of expected effort, even if it's non-binding.
Non-binding price range (estimate)
A price range gives rough orientation — "between X and Y" — without the provider committing to a specific figure yet. This is typical in early project phases where neither scope nor effort is clear enough to seriously state a fixed price or an exact number of hours. A price range is not a substitute for a binding offer; it's an initial reference point on the basis of which scope and approach can be further narrowed down.
Separately priced discovery or assessment
Some providers offer a separately priced initial consultation or analysis phase before quoting the actual project at all. This is worthwhile especially for more complex or technically unclear undertakings, where only a closer analysis reveals what actually needs to be done. The cost of this phase stands on its own and isn't automatically part of the later project price.
Comparison table
| Offer type | Cost certainty | Fits well with |
|---|---|---|
| Fixed price | High, if scope is clearly described | Clearly bounded, well-described projects |
| Hourly or daily rate | Low to medium, depends on effort estimate | Exploratory consulting, ongoing support |
| Non-binding price range | Low, an initial reference point | Early project phase, scope still unclear |
| Separately priced discovery | High for the analysis phase itself | Complex, technically unclear projects |
Which pricing model providers choose in the first place
Which pricing model you end up seeing doesn't just depend on the provider — it also depends on how clear your own request was. A well-described, clearly bounded task encourages providers toward a fixed price, because the risk stays calculable for them. An open, still-unclear request almost inevitably leads to hourly or daily-rate offers or a non-binding price range, because the provider has to protect themselves against unknown extra effort. If you notice a striking number of different pricing models side by side in a comparison, it's therefore also worth taking a look at your own request: it may have been phrased too openly at decisive points, so that each provider priced in their own risk differently.
Why pricing models and currencies aren't automatically comparable
A fixed-price offer for a given amount isn't automatically cheaper or more expensive than a day-rate offer with an estimated effort — the two figures rest on different assumptions and different risk, carried either by you or by the provider. Offers in different currencies, such as euros and Swiss francs, can't simply be converted into each other and weighed against each other either: exchange rates fluctuate, and an automatic conversion would suggest a precision that doesn't actually exist at the time of comparison. On Projektlotse, there is therefore deliberately no automatic equating or ranking of different pricing models or currencies — that judgment remains a business decision you make based on your own risk tolerance and need for planning certainty.
What else to compare besides price
Price is only one building block of the decision. Also take into account:
- Scope: Does the offer actually cover what you need, or were parts quietly left out? A narrow scope at a low price is rarely a good deal if the missing parts have to be commissioned separately anyway.
- Exclusions: What's explicitly not included, and what extra costs could that create later? An offer without stated exclusions isn't automatically more complete — usually it just means that question is still open.
- Timeline: Is the offered availability and project duration realistic for your needs, or does it look strikingly optimistic compared to the other offers?
- References and relevant experience: Has the provider already delivered comparable projects, or is it more general industry experience with no direct link to your undertaking?
- Verified business identity: Was the provider's business identity verified, or is it an unchecked claim? This says nothing about the quality of their work, but something about how reliable the business relationship is.
A structured side-by-side of these points — not just the bottom line — ultimately shows which offer actually fits your project. The decision about which offer is the right one always stays with you: on Projektlotse too, there is no automatic best-offer selection, only the basis on which you can make an informed choice yourself.
How to proceed practically when comparing
Before comparing, set up a simple overview that describes every offer using the same criteria — scope, exclusions, pricing basis, timeline, references and verified business identity as fixed columns. That forces you to actually place offers side by side point by point, instead of being guided by the first number you see. Pay particular attention to differing scope boundaries: two offers at a similar price can cover completely different scopes if one includes more services and the other excludes much of it as a chargeable extra. If questions remain open after this comparison, it's worth asking the relevant provider directly instead of making assumptions — a provider who answers promptly and concretely thereby delivers a further data point for the later collaboration.
If you're unsure about an offer
If doubts remain about a specific offer after your own comparison — for instance because a price looks unusually low or high, or the technical approach is hard to assess — you can request a technical and price-plausibility assessment for that offer from the Projektlotse team. This is a professional opinion within stated limits, not a guarantee and not an automated seal of approval; the normal offer process continues in parallel while it's pending. An assessment like this doesn't replace your own comparison, but it can provide additional certainty for a particularly hard-to-judge item.
A careful comparison takes somewhat more time overall than just glancing at the total, but it pays off: it prevents a low price from being mistaken too quickly for a genuinely fitting offer, and it creates the basis for a decision that continues to hold up as the project moves forward. Take deliberate time for this step before deciding on a provider — the effort usually pays off over the entire course of the project.