Exact Software Estimates Need Understood Scope

If an agency gives you an exact price and deadline after one short conversation, the apparent precision can feel reassuring.

The project has a number. The timeline has an ending. But if the team has not understood the product, that precision may be based on the version it imagined rather than the version you need.

A mechanic needs more than a strange noise

Imagine telling a mechanic that your car is making a strange noise and asking exactly what the repair will cost and when it will be finished.

A serious mechanic would ask when the noise happens and investigate. One small replacement and a larger problem involving several connected parts require different work. An immediate answer would not make me more confident unless the mechanic had enough information to support it.

Does “an app to sell things” mean a shop or a marketplace?

A customer may see products, add one to a basket, and pay in either version. That similar buying experience can hide a very different system.

For one company selling its own stock, the team needs to support that company’s products, orders, and operating rules.

If hundreds of independent businesses will sell through the application, each needs to manage its own stock and orders and get paid for its sales. The system also needs to keep each seller’s information and responsibilities separate.

Now the team has questions that were absent from the single-shop description. Who can change a seller’s products? Who handles an order involving more than one seller? How is each seller’s share of a sale determined, and what happens when an order is refunded?

Those answers change the journeys, permissions, payment handling, and checks the team must build. They cannot be inferred from the appearance of the customer’s checkout alone.

A quote based on a single shop might cover every promised screen and still exclude work essential to the marketplace. The extra cost appears when the missing requirement becomes clear, even if the supplier delivers everything it originally priced.

An early range can still support a decision

This does not mean beginning without a budget or leaving the deadline open indefinitely.

A professional team should explain the likely investment, delivery range, major assumptions, and decisions that could materially change them. For this example, the estimate should identify whether it covers one seller or independent sellers and which order and payout behavior is included.

If the client has not decided between those versions, the team can explain the difference, investigate the expensive unknowns, and estimate a bounded first release. It should not present one precise number as though both versions require the same work.

Discovery should settle the questions the estimate depends on

Useful discovery investigates the business rules and technical constraints that could materially change the work. It might show that the first release can serve one seller, with marketplace capabilities deliberately deferred. Or it may establish that independent sellers are essential from the beginning.

Neither outcome removes every unknown. Both give the estimate a clearer basis and make the cost of a later scope change easier to understand.

When reviewing the proposal, ask:

• Which version and complete user journeys are included?
• Which assumptions remain, and what work is excluded?
• What could change the price or timeline, and how will that change be agreed?

For the selling app, you should be able to point to where seller access, order ownership, and payouts are addressed or explicitly excluded. That is more useful evidence than the number of decimal places in the quotation.