Development is one part of the cost
Imagine two proposals with the same initial price. One includes documentation and a defined support period. The other requires separate service subscriptions and does not explain who handles an incident. Comparing only the total can hide meaningful differences.
Separate the work needed to build the solution from what will continue after launch. Each item should have an owner and a way to calculate or review its cost.
Organize the discussion into three parts
Development: what will be designed, connected, tested and delivered. Clarify assumptions about available information, access and the team's involvement. A feature description alone may leave that supporting work undefined.
Third party services: hosting, storage, models and other tools the solution needs. Ask who owns each account and how consumption changes with usage. Check the provider's current terms before assigning amounts.
Operations: monitoring, maintenance, incident handling and improvements. Define what is included, what requires a separate quote and how work is prioritized. Both parties need to understand what support means in practice.
Compare the same usage scenario
Use a common example for both proposals: the task, how often it is expected to run and the information it requires. When those quantities are unknown, label scenarios as assumptions rather than confirmed spending.
Include the team's time preparing information, reviewing outputs and handling exceptions. That involvement may change during adoption and should be observed.
Ask how unexpected consumption will be detected and how actions can be limited or stopped. The exact controls depend on the tools and need to be verified during implementation.
For your next discussion, prepare a table with the item, owner, frequency and reason its cost might change. Leave unconfirmed fields blank. A clear proposal should help fill those gaps without promising savings or returns that have not been measured.
