The alchemy of pricing software development or what lies behind six-digit rates

It’s commonly known that software development (including mobile applications) is expensive and complicated, but many people ask why? And that's why we’ve decided to be transparent about our system of price making and explain the rationale we follow, from the moment we receive the request for a Fixed time fixed price (FTFP) to when we send off the finished offer, which can eventually be millions of crowns. What exactly is the methodology behind all of this?

How does our pricing work, if it is a FTFP project?

(In this article, we will only talk about pricing fixed time fixed price projects, which still represent most of the projects we work on. Agile development has its own unique methodology, which we will present next.)

When pricing a project, the nature of the proposal must always be individualized. Each and every application is always tailored to the needs and wishes of the client. When a request arrives, it is impossible to provide an accurate price just by reading the email, quite the opposite.The right pricing of a mobile application, website, or system, is a job that takes a minimum of 3 senior members of Synetech (a project manager, senior developer and solution architect) several days.

Specifications

The Ideal situation leading to accurate pricing is if the client comes with a brief, which includes wireframes and text. That is usually only 1 case out of 10. Most often, only a basic list of functions arrives, or conversely, 80 pages of text… And there are also cases when the client comes up with vague ideas like they want an e- shop, and is only interested in the general price, ideally as low as possible. This without any other specifications is like trying to solve a puzzle without some of the pieces.

A single sentence brief is ok as long as…

We are also ok with asituation when the client approaches us with areal problem, even if they have not figured out yet, how to solve it.As long as the client is open to suggestions and is not restricted by a small budget, development in this situation is not impossible, and most importantly not expensive either. (This is how we developed with Oriflame , Next Level or Jablotron ).

In this case we are analysing the ideal technological solutions, showing possible variations including their pricing. The client chooses between them and we are continuously moving forward.

50-700 thousand

This can be the difference between analysing a problem and the proposal of a suitable technological solution,but as the subheadline (hopefully) suggests, a lot depends on what problem the client wants to solve.If there is a budget for analysing technological solutions, the advantage is that we can be much more accurate in estimating the cost.

Estimation

The moment when the specification arrives, it goes from the sales department to our project managers.One of them will look into it with detail and divide the order into smaller functional parts, most often single screens, repositories, firebases, maps, videos or AR…It is always better to price an app by these smaller parts, rather than as a whole. Afterwards the cost estimate goes to other project managers who add their own feedback.

Then comes the “estimation meeting”, at which at least three senior developers go through the specification item by item, they look into the design and ask questions about things they don't understand and assumptions of the functionality. This is a part that is very tricky, because it involves a lot of conjecture, without a detailed brief it is very difficult to estimate the clients expectations. (for example, if the client wants augmented reality, should it be triggered by an object, a flyer, or something different?). After that once our developers come up with a solution proposal, they divide the application up into smaller parts and apply the “three figure estimate”.

Expert estimation of application development in practice

In reality, this methodology looks like3 estimates are created for each screen or function - minimum, maximum and the best (from this we do not take the average). If we are expecting development of an unknown function or feature, we have to estimate how much time it’s going to take when everything goes smoothly, everything is pre-prepared and we choose the easiest technology. In this case it is the minimum price estimate that applies. If everything goes downhill, the API doesn't work andthe client does not specify their preferred technology then the maximum cost will apply. The best estimate then applies for ideal situations when we have already worked on a similar thing, there is an existing library (which means we will most likely spend minimum time and money), this type is the most realistic estimate.

Parts of this methodology are prioritised, with the best estimate being the highest in value, with minimum and maximum estimates being the limits. The more unknown the requested feature is for us, the larger the variance between minimum and maximum. For example a client requests registration features, which we have done a hundred times, the variance will only be 1 MD (Man Day) But if we are doing something brand new, such as making optimisation for deaf people, the variance can be as much as 20 MDs.

That’s the theory.In practice 3 senior developers split the brief in the estimation meeting, where one acts as an optimist, one as a pessimist and the last tries to make the most precise estimate. Afterwards we have discussions on whether we have developed anything similar, why the feature should or shouldn't be this expensive, etc. Until we get to the ideal 3 figure estimate. We never leave this meeting until we all agree.

What do we approach the client with?

We barely ever present the “three figure estimate” to a client (unless the client asks for it) This process serves us to estimate the time of development, to which we add management, testing, fixed items such as project creation and this gives us the overall cost estimate which we then present to the client. Different people have different preferences, which is why some people only require an overall cost estimate and some require a more detailed description.

For example, to one of our current clients, we presented a detailed price specification 500 lines long. We are happy to prepare both versions for our clients and patiently explain why each item costs what it costs. However, we have never been in a situation where the client would doubt the price, which is a positive sign that education within the industry is working and no one in the Czech republic thinks that a mobile application can be developed for 40 thousand crowns and in one day.

It is because we devote so much time to the analysis and pricing of the order, the collaboration with a client is much more pleasant, because realistic expectations are set from both sides from the beginning. And in a nice atmosphere, the best mobile apps are created. Maybe the next one, we will create with you and we will start the whole process by providing you with the right cost estimate.

Are you thinking of developing a mobile app? Get in touch we would love to talk to you.