A software quote with no questions should make you nervous

A software quote with no questions should make you nervous.

You describe the app. Someone gives you a price, a deadline and a confident promise to handle everything. Another developer wants to see the old spreadsheet, understand who can approve an order and find out what happens when a customer cancels.

The second conversation is more annoying. It may also be the first conversation about the system you actually need.

I would rather lose a project by questioning the brief than win it by pretending the brief answers everything. That is the standard I would want a buyer to hold me to.

“A customer portal” is not enough to compare two quotes

Consider a hypothetical business replacing email and spreadsheets with a customer portal. The request sounds straightforward: accounts, orders, documents and an admin screen.

One proposal includes a login, an order form and a list of uploaded files. Another includes those screens plus importing existing customers, restricting documents to the right company, recording approval changes and giving staff a way to correct a failed order.

Both proposals can honestly say “customer portal.” They describe different amounts of work.

Now imagine purchasing the first one while assuming the second one is included. A screen can be finished while the person who has to operate it still cannot do their job.

The missing questions were about the work behind the screen. Can two people from the same customer see the same documents? What happens to an order that was approved and then changed? Who fixes an imported record with the wrong account attached?

You can choose to leave some of that out of the first release. The choice needs to be visible before you compare prices.

A cheaper quote can be the better quote

A developer might already have suitable components, know your industry well or propose a sensible manual step instead of an unnecessary feature. That can produce a genuinely smaller bill. A higher price can also buy overengineering, meetings and an expensive version of the wrong thing.

So I would not use price as a shortcut for judging competence. I would ask each supplier to explain the boundaries behind the number.

For the portal example, I want to know what happens to existing data, which users can do what, how we will demonstrate that an order is complete, and what support is included after launch. I also want the exclusions written in language the business can understand.

“Data migration excluded” is clear. “Standard implementation” tells me very little unless someone explains what standard includes.

A useful proposal makes it possible to say, “Yes, we can operate that version.”

Faster development still needs a decision about what to build

There is a timely example in the tooling itself. Spec Kit, the open-source project hosted by GitHub, reached version 1.0 on August 21, 2026. Its current workflow carries a specification through planning, implementation and verification. Even tools built for coding agents make room for defining the work.

That does not prove that using Spec Kit lowers a project's cost. It does illustrate a distinction buyers should keep in mind: generating an implementation and agreeing on the required behavior are separate activities.

If AI helps a team build a well-defined feature more efficiently, the buyer should benefit. I use AI and want that improvement. But it cannot decide, on your behalf, whether a cancelled order should release stock immediately or wait for someone to approve the cancellation. Someone accountable for the business has to make that call.

A quick build of the wrong rule still needs correcting.

The developer does not get a blank cheque either

None of this excuses refusing to discuss a budget until a client buys an open-ended discovery exercise.

A rough range can be useful early. It should come with the assumptions that make the range plausible and the unknowns most likely to change it. A small, familiar job may need very little investigation, especially when the answers are already in a good brief.

For a larger project, a bounded first step can make sense: inspect the existing system, settle the important unknowns and produce a proposed first release with acceptance criteria. Agree on that step's price, outputs and stopping point. The buyer should leave with something useful even if they choose another developer.

Fixed pricing is also a perfectly reasonable conversation. Martin Fowler's longstanding explanation of fixed-price development distinguishes fixing a budget from fixing price, time and scope together. Buyers deserve to know which of those a proposal actually commits to.

Ask what happens when an assumption turns out to be wrong. Who explains the options? When do you approve extra work? What can be deferred while protecting the business outcome?

A supplier should be able to answer those questions without making you feel difficult.

Bring the awkward questions forward

Before choosing between proposals, put one real working day through each of them. Follow an order from creation to completion. Include a correction, a cancellation and a staff member who should not have access. Ask the developer to show where those needs are covered or explicitly deferred.

That conversation will tell you more than another page of confident promises.

At Rosecraft, technical consulting and project planning sit alongside implementation. If the brief needs work before the build makes sense, that is a useful place to start.

Ready to hear what your project needs, even if it changes the plan? Send us a message with what you are building, what already exists and the deadline you are working toward. Tell us which decision is holding you up. We can discuss a scoped review, a smaller first release or the build itself.