How we estimate a project: scope, cost, timeline — and why there are no surprises

One of the most common sources of frustration in IT projects is when the final cost and timeline don't match what was discussed at the start. We've built our process to prevent exactly that. Here's how it works.

Discovery and brief

Every project starts with a deep dive. We ask questions: what problem needs solving, who will use the system, which processes it will affect, what is already in place. This isn't a formality — without a clear understanding of the task, any estimate is essentially a guess and will almost certainly be inaccurate.

The output of discovery is a document describing the task, constraints, and the criteria for a finished result. That document becomes the foundation for the estimate.

Prototype and solution structure

Before we put numbers on the table, we sketch the architecture: which modules are needed, how they interact, which integrations will be required. For products with a user interface we draw a screen flow or a simplified prototype — so both sides have a shared picture of exactly what will be built.

This step eliminates most misunderstandings before work begins.

Locking scope, cost and timeline

Before development starts, we fix three things:

• What is in scope — a concrete list of features and screens, no vague language
• What it costs — broken down by module or phase
• When it will be ready — realistic dates that account for our current workload

The client signs off on this before the first line of code is written. No verbal agreements.

Iterations and weekly demos

We work in one-to-two-week iterations. At the end of each iteration we show a working result — not slides, but a real product in a browser or on a device. The client sees progress and can adjust priorities while changes are still inexpensive.

When the estimate changes — and how we communicate it

An estimate may change if:

• New requirements emerge during the work that weren't in the brief
• An integration with an external system turns out to be more complex than expected
• The client wants to add or change functionality

In such cases we first communicate the scope change, agree on a new price and timeline — and only then continue. The client never discovers an overrun after the fact.

Transparency instead of surprises

Our principle is simple: anything that affects the budget or timeline must be discussed before it becomes a reality. This demands discipline on both sides, but it's the only way to build a long-term working relationship.

If you have an idea or a task — tell us. The first conversation is free, and by the end of it you'll know exactly what needs to be done and what it costs.