Why quotes vary so much
Send the same two-page brief to five development companies and the range of responses will be wide enough to be unhelpful. That variation is rarely dishonesty. It is that a two-page brief does not contain enough information to be priced, so each team fills the gaps with its own assumptions — about integrations, about user roles, about who handles data migration, about whether 'reporting' means three fixed reports or a query builder.
The most useful thing in a proposal is therefore not the number. It is the list of assumptions next to it.
What actually drives cost
Integrations
The single largest and most underestimated factor. Connecting to a well-documented modern API is routine. Connecting to a legacy system with no documentation, no test environment and a gatekeeper who answers emails weekly can consume more time than the rest of the build. Every integration should be priced separately and honestly.
Roles and permissions
One user type is simple. Five user types with overlapping permissions, delegated approvals and record-level visibility rules multiply the logic and the test surface. This is where 'it is basically a CRUD app' stops being true.
Data migration
Moving twelve years of inconsistent records out of an old system is a project, not a task. Duplicates, missing fields, encoding problems and rules that changed in 2019 all surface during migration. If a quote does not mention migration, ask where it is.
Compliance and audit requirements
Audit trails, retention policies, access logging and data residency requirements are engineering work. They are also much cheaper designed in than retrofitted, which is why they belong in the first conversation.
Design fidelity
A functional internal tool and a polished customer-facing product are different budgets. Both are legitimate; choosing the wrong one for the context wastes money in one direction or credibility in the other.
The costs that get left out
Four recur often enough to name. Hosting and third-party services, which are ongoing rather than one-off. Maintenance, realistically fifteen to twenty-five percent of build cost per year for security patching, dependency updates and small fixes. Your own team's time in discovery, review and user acceptance testing — usually more hours than clients expect. And the post-launch period, where real usage always produces a list of adjustments; budget for it rather than treating it as a failure.
How to compare proposals properly
Read the assumptions, not the total. Check whether the scope boundary is explicit — what is deliberately excluded matters as much as what is included. Ask how change requests are priced. Confirm who owns the code and the infrastructure accounts. And ask what the first two weeks produce; a team that cannot describe an early checkpoint is planning to disappear until a demo.
Reducing cost without regretting it
Cut scope, not quality. Ship one workflow properly rather than five partially. Use proven components for solved problems — authentication, payments, file storage — instead of building them. Defer the admin panel until you know what needs administering. And keep the design system small; ten well-made components will build thirty screens.
What not to cut: testing, documentation, and the architecture stage. Each of those is borrowing against next year at a poor interest rate.