When a vendor estimates a software project, one persistent problem always arises: part of the work lies in the unknown.
New integrations, unfamiliar APIs, architectures the team has never touched before — all these create uncertainty that makes precise estimation difficult.
Clients expect concrete numbers, while developers simply do not have enough data to justify them.
As a result, there’s a temptation either to add a generous buffer “just in case” or to underestimate the work to remain competitive.
Yet uncertainty does not mean incompetence.
It simply means missing information.
The task of a mature engineering team is not to guess how long something will take but to systematically fill the gaps in knowledge so that the estimate becomes credible and realistic.
When a Spike Comes Too Late
Many engineering practices recommend tackling uncertainty through exploratory tasks — so-called spike stories.
That approach works well when a project is already under way and the team can afford a short sprint to test a hypothesis.
But at the presale stage, when a client only outlines an idea or a future system, a spike becomes an investment with no guarantee of return.
So, at presale, the goal is not to develop — it’s to understand.
The job is to turn the unknown into something predictable, without spending days or weeks on deep research.
Types of Uncertainty
If you break down the problem, it becomes clear that uncertainty is not monolithic. It takes several forms:
- Technical. A new library, an ERP platform, or an undocumented API.
- Domain. The client’s business logic is not yet fully defined or only partly described.
- Communication. Decision-making roles and response speed are unclear.
Each type requires its own mitigation strategy.
Technical uncertainty can be reduced through analogy with previous projects; domain uncertainty — through range-based estimates (“from” and “to”); and communication uncertainty — through adjustment factors that reflect how quickly the client provides feedback.
Estimating Without Knowing for Sure
Mature teams are not afraid of ranges.
Saying “two to four weeks, depending on API clarification” sounds every bit as professional as “exactly three weeks.”
In fact, it builds trust: the client can see where the uncertainty lies.
Sometimes a parametric estimate helps — when measurable parameters are known (number of screens, integrations, or user roles) and historical project data can be applied.
If no analogue exists, an expert estimate still works: a small internal review by experienced engineers can define upper and lower boundaries, together with risk factors.
The key is not to hide uncertainty behind arbitrary buffers.
A transparent estimation model always beats pretty but meaningless numbers.
When the Lack of Expertise Is Not a Problem
The absence of in-house expertise is no longer critical.
After all, what is expertise?
It is not simply a person with ten years of SAP experience; it is structured knowledge about how a system, process, or technology works.
Previously, gaining that knowledge required consultants or lengthy research.
Today, it is instantly accessible.
Modern large language models (LLMs) can reconstruct the context:
they “know” how SAP modules are organised, how Salesforce is configured, what constraints exist within the NetSuite API, and how OAuth integration is typically implemented.
This doesn’t remove the role of engineers — it dramatically lowers the barrier to entry.
Expertise is no longer the monopoly of people who “have done it once before.”
It can now be recreated from global knowledge, quickly and systematically, right within the presale stage.
A Two-Phase Process Instead of Guesswork
The traditional sequence looked something like this:
- Receive the task.
- Try to estimate by analogy.
- Add a safety buffer “just in case.”
A modern approach is different:
- Phase 1 – Reconstruct the expertise.
Using an LLM, the team builds an understanding of the technology — its architecture, constraints, and standard integration patterns. This is the knowledge reconstruction stage. - Phase 2 – Produce the actual estimate.
Once the context is clear, the task can be decomposed and evaluated using standard methods.
The uncertainty range narrows — not by luck, but through systematic understanding.
This process is not only more accurate but also more efficient.
Presale turns from guesswork into a managed research effort, without the cost of a full spike.
What It Means for the Client
- The estimate is based on knowledge, not assumption.
- The process is transparent — assumptions and boundaries are clear.
- The vendor demonstrates engineering thinking rather than mere commercial reflexes.
- Even in new domains, the team can rapidly restore the necessary expertise.
Competence as the Ability to Rebuild Knowledge
An LLM does not replace an expert — it makes expertise reproducible.
True maturity in 2025 is measured not by the years of experience a team has, but by how quickly it can rebuild context and make sound decisions.
Estimating uncertainty is therefore not a risk or a weakness.
It is a sign of engineering culture — the ability to manage knowledge instead of guessing time.
If your project involves complex or unfamiliar components, don’t wait for the “right expert” to appear. Find a partner who can turn the unknown into a system. Let’s talk about how to do that for your project.