A logistics company in Manchester sent the same project brief to three software providers. They needed a platform to track shipments, manage drivers, and let clients see delivery status live. The custom software development cost they were quoted came back as $8,000, $45,000, and $180,000.
The operations director stared at the three numbers and assumed the market had gone mad. It had not. He had simply asked for a price before anyone agreed on what exactly they were pricing.
By the time you finish reading, you will know why those numbers were all meaningless, how a proper scoping process produces a figure you can actually budget against, and what to ask before you accept any software quote.
Why do software quotes for the same project vary so much?
A software quote is not a price tag. It is a set of hidden assumptions about what you need, how it will be built, and what happens after it launches. The logistics company's $8,000 quote assumed they would get a template-driven website with a simple database and no live tracking. It was a static admin panel, not a functioning logistics platform.
The $180,000 quote came from a firm that assumed they needed to build a real-time fleet management system with native mobile apps for drivers, automated dispatching, and the same security architecture a bank would require. That might have been overengineered for a company running 12 trucks. But the brief never stated the fleet size, so the vendor priced for the worst case.
The $45,000 quote landed in the middle because that vendor asked the questions the other two skipped. They learned the company had 12 trucks today but planned to reach 60 within 18 months, that drivers would use their own phones, and that the biggest pain point was dispatchers re-entering data across three separate tools. That context let them scope a web application that solved the immediate problem without building for a 2,000-truck enterprise on day one.
The gap between $8,000 and $180,000 was not a range of prices for the same thing. It was a range of guesses about entirely different things. No number in that spread was useful because no number was tied to a shared understanding of what would actually be built.
How can I tell if a software quote is honest or just a guess?
An honest quote does not arrive as a single number in an email. It arrives as a document that makes its thinking visible. A health-tech company we spoke to last year had received a quote for a patient scheduling system that read, "Complete portal: $62,000, 16 weeks." When they asked what "complete" meant, the vendor replied that they would figure out the details once the contract was signed.
That is a guess dressed as a quote. The vendor was not dishonest. They were pricing the unknown by adding enough padding to cover any surprise, then handing that risk back to the client without naming it.
An honest estimate will tell you what it includes, what it does not include, and which decisions are still open. It will break the work into pieces you can actually check, such as the patient booking flow, the clinic calendar view, the integration with an existing electronic health record system, and the admin panel for staff. If a line item says "third-party API integration" without naming which API, ask for the name. If they cannot name it, they cannot have priced it.
The health-tech company eventually worked with a team that spent two weeks on a paid scoping phase before quoting. That phase uncovered that the EHR system used HL7 FHIR, required a specific authentication pattern, and limited appointment slots per practitioner hour. The final quote was higher than the original $62,000. It was also the first number the founder trusted enough to approve.
What does a proper software scoping process actually look like?
Scoping is not a meeting where you describe your idea and someone writes a number on a napkin. It is a structured exercise that turns a business need into a technical specification that both sides can read, question, and agree on before a single line of production code is written.
Take a SaaS startup that needed a customer portal for a data analytics product. Their original brief said "dashboard with charts." In a scoping session that ran across three focused conversations, the team mapped out exactly who would use the dashboard — end customers, account managers, and internal analysts — and discovered that each group needed different data views, different export formats, and different permission levels. What began as a single feature became three distinct interfaces with shared backend logic.
A proper scoping process will give you a list of user roles and what each role can do, a map of the screens or views the software will contain, a record of every external system the software must talk to, and a list of the riskiest assumptions the team is making about your business. By the end, you do not have a price. You have a document that lets someone price the work honestly.
For the logistics company with the three quotes, a scoping phase would have answered the questions none of the vendors asked: how many dispatchers, how many drivers, which courier APIs are already in use, whether delivery photos are required, and who owns the data when a shipment is completed. Without those answers, multiplying an hourly rate by a guessed number of hours is not estimating. It is hoping.
Why a fixed-price quote without scope is more expensive than you think
A fixed-price quote feels safe. You pay one number and the vendor carries the risk. The problem is that when scope is missing, the risk is undefined. A sensible vendor will either inflate the price to cover what they do not know, or they will not inflate it, deliver exactly what is written, and charge you for every missing piece as a change request.
An e-commerce company learned this the hard way with a fixed-price build of a product configurator. The spec said "product recommendations." The vendor built a simple algorithm that suggested items from the same category. The founder had meant a cross-sell engine that analysed customer purchase history, margin data, and inventory levels to surface the highest-value add-on. That discrepancy was not in the spec because neither side realised it needed to be. The change request added 40% to the project cost and delayed launch by six weeks.
Fixed price without fixed scope is not a financial plan. It is a negotiation waiting to happen. The honest alternative is a phased budget built on a scoped specification, with a fixed price for the discovery phase and a clear range for the build that narrows as the specification sharpens.
How Cresbyte approaches custom software development cost
We do not send a price when you first contact us. We send a list of questions. Before we talk about custom software development cost, we need to understand the business process your software will support, the people who will use it, and the operational metrics that actually matter to your team.
Our scoping process begins with a structured conversation, typically 90 minutes, where we map the highest-risk assumptions in your requirements. If you mention real-time driver tracking, we will ask what "real-time" means to your dispatch team — a 30-second delay or an instant geofence alert. If you mention an integration with a payment processor, we will look up the API's rate limits while you are still on the call and tell you if your projected transaction volume will require a different architectural approach.
The output of that conversation is not a price. It is a set of options. A focused first phase that solves your most expensive operational problem in 8 to 10 weeks. A phased roadmap that layers in customer-facing features once the internal tooling is stable. A full platform scope when the business case and the capital are aligned. Each option is presented with a price range that reflects the remaining unknowns, and each range narrows as the specification hardens through a paid discovery engagement. [INTERNAL: see how we structure scoping engagements that produce honest timelines and budgets → /scoping-process]
We build enterprise-grade applications from Nairobi for businesses across Africa, the UK, the US, and Europe. Our engineers have delivered systems that process millions of transactions for fintech firms, manage real-time logistics for courier networks, and power SaaS products used by mid-market companies daily. That experience means we know which five questions turn a vague brief into a buildable plan. That plan is what produces a number you can take to your board, your investors, or your own spreadsheet with confidence.
You will not hear us promise a fixed all-in price on the first call. You will hear us say: "Here is what we need to clarify before anyone can give you a real number, and here is what it costs to clarify it." That is not evasiveness. It is the only honest answer in an industry where guessing is easy and delivering is hard.
Get a real cost breakdown built around your actual project
If the quotes on your desk feel too far apart to trust any of them, book a free scoping call with our engineering team. We will map out exactly what your project needs and what it will cost before you commit to anything. No obligation.
Schedule your free scoping call →
Frequently Asked Questions
How long does scoping a software project take?
For a mid-complexity business application, a proper scoping phase typically takes one to three weeks. That includes stakeholder interviews, technical research on third-party integrations, and the production of a specification document both sides can review. The timeline depends on how many user roles and external systems are involved. Rushing this phase is the most expensive shortcut in software.
What should I prepare before a scoping call?
Bring a clear description of the business problem you are trying to solve, not a feature wishlist. Know who will use the software, how many people that is today and in two years, and which existing tools the new system must connect to. If you have a hard deadline driven by a contract, a launch commitment, or a regulatory change, state it upfront. Deadlines shape phasing decisions and cost trade-offs.
Is a higher quote always more trustworthy?
No. A high quote that arrived without a scoping process is just an expensive guess. A vendor who quotes double what another quotes may be building for requirements that do not exist, or pricing in risk they never articulated. The trustworthiness of a quote comes from the clarity of the assumptions it lists, not the size of the number at the bottom. Always ask what a quote assumes before you ask why it costs what it does.