Whenever someone reaches out saying something like "I need a system for X", the temptation is to reply immediately with a timeline and a price.
I used to do that, but over time I realized that fast answers are not necessarily accurate answers.
In software development, estimates are only as reliable as the information available. When the problem is still poorly understood, any number you provide carries a high degree of uncertainty.
The initial brief is always incomplete
Even when a client provides a detailed description, there are usually many unanswered questions.
Some of the information that is often missing includes:
- How many people will use the system;
- Whether different permission levels are required;
- Which features are truly essential;
- Whether integrations with APIs or third-party systems are needed;
- Whether existing data must be migrated;
- If the solution needs to work on desktop, mobile, or both;
- Which reports or metrics are important;
- Whether there are any schedule constraints;
- Whether there is an expected budget range.
None of these points seems particularly complicated on its own, but together they can completely change the complexity of the project.
A simple inventory application for five users is very different from a platform with multiple roles, financial modules, document generation, and external integrations.
Because of that, I've learned not to treat the first message as the complete scope.
What I do today
Instead of immediately sending a quote, I first confirm that I understood the problem correctly.
Then I usually ask only a few questions. Two or three are often enough to clarify the aspects that have the biggest impact on complexity.
I try to avoid turning the first conversation into a twenty-question interview, because that tends to overwhelm people.
This approach usually provides three benefits:
- The client knows I actually read the request;
- It prevents both sides from imagining different solutions;
- It gives me enough context to prepare a more reliable estimate.
In practice, spending a few extra minutes understanding the problem often saves many hours of rework later.
Estimates are not predictions
One thing I've learned is that estimates are not promises.
They are forecasts based on the information available at a given moment.
That's why I prefer spending more time understanding the problem before discussing timelines and pricing.
Most of the time, this leads to more realistic proposals and fewer surprises during development.
In the end, a good estimate starts long before the spreadsheet.
It starts with understanding.