Most conversations with a company that wants custom software open with the same two questions, how much it costs and how long it takes. They are fair questions. In the first meeting it has no honest answer, and any number someone gives before understanding the problem is a guess with good formatting.
What moves the price
Scope is the factor that weighs most. It is rarely measured in screens. A single approval screen with five roles, rules by amount and a full audit trail can cost more than several simple forms, because every rule multiplies the cases that have to be built and tested. Then come integrations with other systems, which depend on the quality of their APIs and on who picks up the phone when they fail. Security requirements, the number of concurrent users, migrating existing data and the level of polish the interface needs all count too.
The team and the decision speed close the list. A project where questions get answered in a day moves differently from one that waits two weeks for a single approval.
Why discovery improves the estimate
A short discovery phase, which can run from a few days to a few weeks depending on the size of the project, turns uncertainty into decisions. Processes get mapped as they really happen, features get prioritized and technical risks surface, such as an integration nobody has tested. At the end there is a written scope, a delivery order and an estimate with ranges and explicit assumptions, which is what makes a decision possible.
An honest range, like "six to nine weeks if the billing system exposes its API", tells the decision maker which assumption to watch. An exact number that depends on nothing misleads.
What a well-formed estimate looks like
A useful estimate fits on one page and always has the same parts. Here is an illustrative example:
- Scope included: order entry, approval by amount and a monthly report.
- Scope excluded: a mobile app and migration of data from before the start date.
- Assumptions: the billing system exposes a documented API and the approver answers within one business day.
- Risks: the billing integration has not been tested and the historical data comes in mixed formats.
- Range: six to nine weeks for the first delivery, with the most likely date set at the end of discovery.
When an assumption changes, the range changes with it, and everyone knows why.
How to ask for a useful estimate
Tell whoever is quoting what problem the software solves. Say who will use it, before listing features. Share the systems it has to connect to and the constraints you already know about, such as regulation or fixed deadlines. If you have a maximum budget, say so early, because it lets the scope adjust instead of the mismatch showing up once the project is well under way.
Ask what is left out as well. Proposals without exclusions tend to hide surprises.
Delivering in stages lowers the risk
Splitting the project into functional deliveries, each usable on its own, lets you measure real progress. If the business changes its priorities after the second delivery, you adjust course without having spent the whole budget on the old plan.
Send us the problem in a paragraph through the contact page and you get scope, assumptions and ranges back before anyone mentions figures. The custom software development service covers the work from start to finish, from design to continuous delivery.