How to satisfy client with project budget or happy guesstimating!

Project delivery cost is often the very first thing a potential client want to know from a service company. Yet unless you want to get a figure that is too ballpark, learn why estimation is complex.

June 15, 2015

Each time a new client knocks our door we are facing the dilemma: on the one hand we genuinely want him to be happy; on the other hand – all customers want to hear total project cost on the very first call.

Based on our experience, we know that all numbers provided before technical requirements are locked down – just spun out of thin air.

So, at this stage when talking to a new client about the budget on the very first call we can’t be precise, and it happens because the estimated cost can then rise during the project evolution – and all of these can make the customer unhappy and unsatisfied down the line.

Why this can happen?

We believe that precise estimates are those which don’t change dramatically especially upwards in the course of project development. And answer the question “how much” on the first stage of discussions with client, reproduces bad model approach to the challenge. Why we think so? Well, we will try to explain in this article.

How the cost can improve during the project development

There’re a lot of factors that can influence the cost. And a new client, who has never worked before in the sphere of IT and digital might not know about them. So our main goal is to explain how this business works, and apart from this, try to understand as deep as possible our client’s business, decide on objectives of the project and suggest the most effective ways of realization.

And at this stage we still can’t answer the question about project cost estimates: either we have gaps in the concept of the project or we don’t have locked down technical specifications or the client can move or shift goalposts. And besides, very often there are multiple questions which demand deeper research especially if we talk about start-ups.

So we’re in double-sided situation: bad news is that we can’t enumerate and estimate the whole list of works which are needed to be done, but good news is that  if we stick to phase approach we always can estimate how much will be cost to reach each step and how much time we need for it.

Moving from one phase to the other one we can gradually specify the cost of all project. And this is actually the best approach in software development as each complete phase can give answers for the further ones. We start each project with MVP (minimum viable product) stage during which we can create successful strategy in the long term; we already talk about this before in our post Key advantages why to start new app development with MVP, so now won’t pay a lot of attention to this topic.

Require precise estimates at the beginning of the project is a risk, a very big risk, firstly for a client himself

Let us open one of our professional secrets: every developer who is asked to estimate a project and give exact answers is also lacking in detailed information, and it means that we shouldn’t wait for truth from him anyway, as he either gives estimates including all possible and all impossible risks (in this way the budget may be too much inflated) or such estimates will not include risks at all, and in this case such estimates may not protect the client from false expectations.

Each project can’t be protected from everything and we can meet bumps on the road, and among them, for example:

Such issues may happen or may not, and it’s impossible to foresee all of them. But our mission is to try to inform the client about them and be loss-free about our plans as possible.

How we do it

Speaking about phase approach in terms of giving estimates we would like to stress that each phase is estimated and paid separately and here we’d like to describe what those steps of work are:

  1. Let’s start: during the first call with the client, we’re getting acquainted with the idea of a project. Our manager basing on the experience of the company can approximately discuss low and high ends of the similar project costs.
  2. Detailed discussions of technical requirements and start business processes planning: after the first call, we’re talking over requirements, and together with our client we try to find all available data which can help us to create project plan: research about competitor apps, dates of some conferences/presentations which can be target dates for the client and where he can promote his product. Also at this stage, the team needs to get the vision of business requirements and goals of the product which we need to create.
  3. Lock down technical specifications: from business goals to technical peculiarities. We want to stress that this stage becomes available for discussions only after the development team gets involved in all business processes within this sphere and in all technical pitfalls of project features.
  4. UI/UX development: often our clients want to start a project with discussions of design, which is hell-for-leather and not correct from the project management standpoint. At first, we need to make a research of the market and decide what we need to target for: in case of mobile development, we need to choose a mobile platform: iOS or Android (and of course we detailed this in requirements document). Only after, the whole team (managers, developers, designers and QA testers) and a client is on the same page about the features, and we can start to create wireframes and designs.
  5. Once we have design, let’s start coding! Only after designs are written in black and white and approved by a client, we get over to development and testing of functionality. At this stage, we already can be super precise about estimating time and costs.
  6. Publishing applications to Apps markets. This is the most predictable stage, but of course, let’s remember about such risks as waiting for review stage in case of App Store, and this we can’t influence anyway.
  7. Additional works on the project. In case we get new requirements for additional feature blocks, usually we sign a new contract with the client, and after those blocks go the same procedure from discussions to app markets releases.


As a conclusion, we want to stress that step-by-step or consecutive development is the best approach to use for software development, which allows us anticipate risks and prevent exceeding a budget by clear pre-planning and informing a client about issues we’re coming across with. And as a result, when all objectives, deadlines, deliverables are maintained, this is meat and drink to us when we see a happy and satisfied client with a product which serves the best for people.


More Articles

Back to blog