n this article, we present how our project estimation process works and how to best prepare for it — especially today, when AI tools make it possible to create concepts, prototypes, and even parts of solutions much faster, while at the same time often increasing the gap between the “vision” and the actual scope of work.
A few years ago, clients usually came with more or less detailed specifications. Today, we increasingly receive materials prepared with AI support: feature descriptions, mockups, and sometimes even generated code snippets. On one hand, this significantly speeds up the conceptual stage. On the other hand, it introduces a new source of risk. Such materials often appear complete, but in practice they frequently omit critical aspects: business logic, dependencies between features, integrations, or edge cases.
That is why estimation is no longer just about “pricing a document,” but about understanding what is actually hidden behind the provided description.
The Challenge: Limited Data, High Expectations
Project estimation is one of the biggest challenges in running a software house — especially when the input provided by the client is limited, while expectations remain very specific. A typical scenario looks like this: a few pages of documentation (often fairly general), followed by a single question:
“How much will it cost, and when will it be ready?”
A short project description rarely contains everything needed for a precise estimation. Technical details, user scenarios, edge cases, and integrations are often missing. In many cases, there is also no information about priorities — what is absolutely critical and what is simply a “nice-to-have.”
From the development team’s perspective, this means one thing: a high level of uncertainty. Every gap in the requirements becomes a potential risk — both in terms of timeline and budget. From the client’s perspective, however, the situation looks different: they need a quick and concrete answer that will allow them to make business decisions.
This tension between the need for precision and the need for speed is completely natural — and that is exactly why estimation is a process rather than a one-time action.
Two Main Estimation Methods
In practice, the best results usually come from combining two approaches: estimation by analogy and scope decomposition. Each of them addresses different needs and works better at different stages of discussions with the client.
1. Estimation by Analogy (History-Based Estimation)
This is the fastest method, especially in the early stages of discussions, when the amount of information is limited and decisions need to be made quickly.
The core question is:
“What previous project is this most similar to?”
In practice, this means analyzing:
- functional scope,
- technical complexity,
- number of integrations,
- delivery timelines of similar projects,
- final costs and actual deviations from original estimates.
Based on this, we prepare an approximate estimation — usually in the form of budget ranges.
This approach relies heavily on the team’s experience and “project memory.” The more projects we have delivered, the better our reference points become.
Advantages:
- very fast — allows us to provide an initial response within a few days,
- based on real project data rather than purely theoretical assumptions,
- works well during presales and initial discussions.
Disadvantages:
- lower precision for innovative or unusual projects,
- risk of underestimating differences between projects,
- harder to justify estimation details because it relies on analogy rather than detailed breakdowns.
That is why we treat this method as a starting point — a quick way to determine the approximate size of the project, but not as a final estimation.
2. Bottom-Up Estimation (Scope Decomposition)
The second approach involves breaking the project down into the smallest possible elements and estimating them individually. This method is much more time-consuming, but also significantly more accurate.
The process usually looks like this:
Initial estimation based on the project description
At this stage, we identify the main system modules and areas with the highest uncertainty. This is where the first project structure is created.
Clarification meeting with the client
The conversation is crucial. It allows us to verify assumptions, understand the business context, and identify elements that are not obvious in the documentation. In many cases, the most important information appears precisely at this stage.
Detailed analysis and documentation
We create a more precise solution description, including:
- screen lists,
- user scenarios,
- user flows,
- basic technology decisions.
Design and development
We estimate UX/UI work as well as development efforts — often divided into frontend, backend, and integrations.
Testing and deployment
We include QA, manual and automated testing, as well as publication and deployment processes (e.g., App Store, Google Play).
Post-launch support
We allocate time for stabilization, bug fixes, and further product development.
Each of these stages is estimated separately, allowing for much better control over the entire process.
Advantages:
- high precision,
- better project understanding on both sides,
- ability to identify risks and limitations early.
Disadvantages:
- requires time and engagement,
- often involves multiple meetings and iterations,
- difficult to execute without active client participation.
Combining Both Approaches — A Practical Model
The most effective approach is to combine both methods into one coherent process.
We usually start with a quick analogy-based estimation, which gives the client an approximate budget and helps determine whether the project fits within their business capabilities. Then, if the project moves forward, we proceed to a more detailed decomposition-based analysis.
In practice, this process looks like:
- the client receives initial budget ranges,
- we organize a workshop or a series of discovery meetings,
- we clarify the scope and eliminate the biggest uncertainties,
- we prepare a more detailed estimation and project timeline.
This approach helps avoid situations where detailed estimations are created based on incomplete information.
Fixed Price vs Time & Material
The cooperation model has a huge impact on the estimation process and the level of risk on both sides.
Fixed Price
In a fixed-price model, precision is critical. The project scope must be clearly defined and properly frozen for the duration of the implementation, because every change can affect both budget and timeline.
- greater responsibility on the vendor side,
- necessity of including buffers for unexpected situations,
- stronger focus on documentation and formal scope management.
This model works best for projects:
- with clearly defined requirements,
- with low variability,
- with a limited number of unknowns.
Time & Material
The Time & Material model assumes greater flexibility and iterative development.
- the client pays for the actual time spent by the team,
- easier change management,
- possibility to dynamically adjust the scope during development.
This model works particularly well for:
- projects developed in stages,
- long-term cooperation,
- situations where requirements evolve during implementation.
How Can Clients Better Prepare for Estimation?
From our perspective as a software house, the quality of estimation is directly related to the quality of the input materials. The more specifics we can define together at the beginning, the lower the risk of underestimating or overestimating the project.
The most helpful things are:
- a clearly defined business goal (why the product is being created and what problems it should solve),
- examples of similar solutions (market benchmarks, inspirations),
- initial user scenarios or descriptions of key features,
- clearly defined priorities (what is “must-have” and what can be developed later),
- awareness of constraints (budget, timeline, resources).
More and more often, we also recommend running workshops before the actual estimation phase. Although they are paid, they almost always pay off in the long run. They help:
- organize requirements,
- make the project scope more realistic,
- identify risks early,
- avoid costly changes during development.
Workshops act as an investment in decision quality — instead of guessing, both sides work based on jointly developed assumptions.
It is also worth remembering that AI-generated materials — such as mockups, feature descriptions, or even code snippets — are excellent starting points, but they often do not reflect the full complexity of a project. They may omit important dependencies or oversimplify problems that, in reality, require more advanced solutions.
That is why we treat AI-generated content as a conversation support tool rather than a finished specification.
Good estimation is the result of collaboration, not one-sided analysis. The more transparency and communication there is at the beginning, the fewer surprises appear during development.
Summary
Estimation is not mathematics — it is uncertainty management.
In a small software house, the key is finding the right balance between responsiveness and estimation quality. Using experience from previous projects combined with gradual scope clarification allows teams to create estimations that are both realistic and business-oriented.
Most importantly, however, it is worth remembering that a good estimation is not just a number — it is a shared understanding of the project, its goals, and its limitations.
