Why do two proposals for the same project describe completely different amounts of work?
Because they are quietly assuming different projects. The variance almost never comes from developer speed. It comes from unstated assumptions about data quality, integration depth, how many roles and exceptions exist, and whether testing, monitoring and documentation are included. Compare assumption lists, not totals — if a proposal has no assumption list, it has not been scoped.
The differences are in what was not written
When two experienced teams look at the same brief and produce wildly different plans, the usual cause is that the brief left room for interpretation and each filled the gaps differently.
One assumed your data is clean and the API access already exists. The other assumed a discovery phase, historical data cleanup, and a migration. Both may be honest. Only one is going to match reality, and the brief did not say which.
The five assumptions that create most of the gap
- Data condition. Is history usable as-is, or does it need normalization before anything can be built on it?
- Integration depth. Read-only versus two-way sync with conflict handling is a completely different project.
- Exception coverage. Does the plan cover the happy path only, or the variations your business actually runs?
- Non-feature work. Testing, monitoring, permissions, audit trail, documentation. These are frequently omitted to appear leaner.
- Who does the unglamorous work. Data cleanup, vendor coordination, user training. If a proposal is silent, it is assuming you will.
How to make proposals comparable
Do not send a description and wait. Send a specification of the decision the system must make, the systems it must touch, the roles that will use it, and the exceptions you already know about. Then ask every bidder to return a written assumption list and an explicit exclusion list.
Comparing assumption lists is far more informative than comparing totals. Where two teams assume different things, you have found the real uncertainty in your project — and that is worth resolving before anyone starts building. The same principle applies to integration work, where the unknowns are usually in somebody else's system rather than in yours.
Treat discovery as the deliverable
When uncertainty is genuinely high, the honest structure is a small, bounded first engagement whose output is a specification: confirmed API access, a sample of real data examined, the exception list documented, and a scoped plan for the build.
That gives you something useful whether or not you continue, and it lets you compare partners on work you have actually seen rather than on how confident their proposal sounded. It is how we prefer to start custom projects, and it is a reasonable thing to ask of anyone. If you would rather describe the problem than write a specification, tell us what you are trying to solve and the specification can be part of the work.
Topics: estimation · proposals · vendor selection · scoping
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.