azyware
Business

How to compare AI proposals when nobody quotes hourly

EZ
Eazyware
· 7 min read
Quick answer

How do you compare AI proposals when none of them quote an hourly rate?

Compare AI proposals by normalising them before you compare totals: same deliverable list, same acceptance criteria, same twelve-month running cost, same ownership terms. An hourly rate was never the useful number anyway, because it prices effort rather than the outcome you are buying.

You compare AI proposals with no hourly rate by rewriting all of them onto one sheet first: the same deliverable list, the same acceptance criteria, the same twelve-month running cost and the same ownership terms. Only then compare totals. An hourly rate never told you what you were buying; it told you how someone bills.

This article gives you the normalisation sheet, the questions that make an ambiguous proposal comparable, the lines that are almost always missing, and an honest note on where our own published prices sit in that comparison.

Why the hourly rate disappeared

Hourly pricing answers the question how much does an hour of your time cost. That was a useful proxy when the work was predictable and the risk sat with the buyer. AI work is not predictable in that way: the same feature can take four days or four weeks depending on data quality, and the buyer who takes that risk pays for every wrong turn.

So suppliers moved to fixed-price programmes, retainers and dedicated pods, each of which shifts risk differently. Eazyware prices fixed-price, fixed-date programmes because we think the supplier should carry estimation risk, and the reasoning is in Fixed price, fixed date: how we make it work. That is a position, not a universal truth, and the trade-offs are argued fairly in fixed price vs time and materials.

The practical consequence is that three proposals for the same project can be structured so differently that comparing the numbers on the last page is meaningless. One quotes a fixed build and omits running costs. One quotes a monthly pod and is silent on what finished means. One quotes a low headline figure and prices every integration as a change request. The totals differ by a factor of three and none of them is lying.

The normalisation sheet

Build one table with a row per line below and a column per supplier. Fill it from the proposals, then go back with questions for every blank cell. The blanks are the useful part: they show you what each supplier assumed you would not ask.

Line to normaliseWhat to write in the cellWhat a weak answer looks like
Scope in one sentenceThe outcome, not the technologyA list of features with no user outcome
Acceptance criteriaA number, measured on a named datasetThe client will confirm satisfaction
Integrations includedNamed systems, read or writeStandard integrations included
Evaluation approachSet size, who labels it, when it runsTesting throughout the project
Change request rateThe published figure or the mechanismBlank, or discussed case by case
Model and API costsWhose account pays, estimated monthlyNot mentioned at all
Post-launch supportTier, response time, included hoursThree months of free support
OwnershipCode, prompts, eval data, infrastructureClient receives a licence to use
ExitHandover contents and notice periodSilence
Twelve-month totalBuild plus running plus supportBuild cost only, presented as the price

The last row is the comparison. A build that costs less and runs on an architecture that triples your monthly inference bill is not cheaper, and you will discover that in month five rather than at signature. The argument in full is in Why the cheapest AI quote usually costs more.

The six questions that make proposals comparable

Send these to every supplier at once, with the same deadline, and share the answers with your own team rather than your evaluation committee only. They take a supplier an hour to answer honestly and are very hard to answer plausibly if the proposal was written optimistically.

  • What number, measured how, means this is finished? A supplier who cannot answer has not scoped the project; they have described it.
  • Which of these integrations have you built before, and what broke? You are testing whether the integration estimate is experience or arithmetic.
  • What is in the change request list already? Every fixed-price proposal has boundaries. A supplier who names them is being straight with you; a supplier who says everything is included has either padded the price or is planning a difficult conversation in week six.
  • What will this cost to run per month at our volume, and who pays the provider? At Eazyware you pay model usage through your own accounts, with budgets and dashboards we set up, so the figure is visible rather than marked up.
  • What do we own on the last day, and how long is handover? The answer should include code, prompts, prompt history, evaluation data, infrastructure definitions and documentation.
  • What would you refuse to do in this project, and why? The most informative question on the list. A supplier with no refusals has not thought about your problem.

Use the estimate tool to get a rough independent figure before the proposals arrive, so you have a reference point that is not anchored by whichever supplier replied first.

How do you compare different engagement shapes?

Convert every shape into a twelve-month cash figure with the same deliverable attached. A fixed-price build plus a care plan, a monthly pod, and a discovery-then-build sequence can all be expressed that way, and once they are, the comparison is ordinary.

For a fixed-price programme, add the build price, the expected change requests, the twelve months of support and the twelve months of model usage. For a pod, multiply the monthly rate by your honest estimate of how many months it takes, and note that nobody has committed to a completion date, which is the trade you are making for flexibility. For a phased sequence, add the discovery fee, checking whether it is credited against the build, as Eazyware's discovery fees are.

Then compare on three axes rather than one: twelve-month cost, who carries the risk if the estimate is wrong, and what you own at the end. The shapes are compared properly in AI development pricing models compared.

Where our own numbers sit

We publish starting prices so they can be put into a sheet like this without a sales call. An AI Discovery Sprint is $3,250 or ₹2,00,000, fixed and credited to the next build. An AI POC Sprint is $6,250 to $10,500, or ₹4,00,000 to ₹6,80,000. Multi-agent systems start at $24,500 or ₹16,00,000, and an AI-accelerated MVP starts at $26,500 or ₹17,60,000. Care Plans run from $1,000 or ₹68,000 a month, with an AI add-on at $750 or ₹40,000. Everything is on the pricing page, and we work in INR with GST invoicing for Indian clients and USD internationally.

A published range is not the same as a quote, and a supplier whose range is wide is not being evasive; the difference between a single-intent agent and a multi-system orchestration is genuinely that large. What you should insist on is knowing which end of the range your project sits at and why, before you sign.

When this comparison process is the wrong effort

Running a full normalisation exercise takes a week of somebody's time, and there are cases where it is not worth it.

The project is small. For a two to four week piece of work, the process costs more than the difference between the proposals. Pick the supplier whose first conversation was the most honest and start.

You have not decided what you want. Comparing proposals for an undefined project produces a very tidy comparison of three different guesses. Buy a paid discovery first, from one supplier, and run the comparison on the resulting specification. The trade-off between paid discovery and a free scoping call is set out in paid discovery vs a free scoping call.

You are comparing on price alone. If the sheet is only being used to drive a number down, the supplier who wins will make it back through change requests, and the project will be adversarial from week two. Compare to understand, then negotiate on scope rather than on rate.

A note on governance requirements

If your organisation has risk or compliance review, add a row to the sheet for how each supplier handles model risk, data residency and audit. Asking suppliers to map their approach to a public framework, such as the NIST AI Risk Management Framework, gives you a common vocabulary and makes three very different answers comparable. It also surfaces quickly who has done this before.

A short checklist

  • Write your own success criterion before any proposal arrives
  • Send the same brief and the same six questions to every supplier
  • Normalise onto one sheet before looking at any total
  • Compute a twelve-month figure including model usage and support
  • Check ownership and handover terms in the contract, not the proposal
  • Ask each supplier what they would refuse to build
  • Decide on scope, risk and ownership; use price to break a tie

What a fixed-price AI quote should contain lists the sections a complete quote has, Questions to ask before hiring an AI agency covers the shortlist conversation, and the AI agent ROI calculator gives you the benefit side of the comparison so the cost side has something to sit against.

The proposal you can compare is worth more than the proposal with the lowest number, because only one of those two tells you what you are actually buying.

Frequently asked questions

Why do AI development companies not quote hourly rates?

▾

Because hours price effort rather than outcome, and AI work varies widely depending on data quality and integration reality. Fixed-price programmes move estimation risk to the supplier; retainers and pods keep flexibility with the buyer. Each shape is defensible, but none of them is comparable to another until you normalise on deliverables and a twelve-month total.

What should every AI proposal contain?

▾

A one-sentence outcome, measurable acceptance criteria on a named dataset, the exact integrations included, the evaluation approach, the change request mechanism, estimated monthly model costs and who pays them, post-launch support terms, and ownership of code, prompts, evaluation data and infrastructure. Anything missing is a question, not an omission to ignore.

Is the cheapest AI proposal ever the right one?

▾

Sometimes, when it is cheapest because the scope is genuinely tighter or the supplier has built the same thing before. It is the wrong choice when the price is low because running costs, integrations, evaluation work or support were left out. Compare twelve-month totals rather than build prices to tell the two apart.