How to price your software projects

We are faced with a very complex assignment written on many pages, but also with a vague assignment of two or three sentences.

Two approaches to creating assignments

In an ideal world for software developers, we work together with the client on the initial brief, start the project, continuously modify the project according to the new requirements, invoice every month the hours of the developers and consultants, and progress in this way to the grand finale.

But that's not how it works. The client usually asks for a total price for a precise scope of work and with a specific deadline.

In order to be able to produce such a offer, we could spend many months working with the client to create a complex brief of dozens of pages. All thought out in advance, in complete detail. According to such a brief, the price and the deadline can already be estimated quite accurately. The trap is that even if we spend a year on creating the brief, we still won't capture everything and we won't avoid "Eureka effect" when the client realizes other needs or wants to solve the functionality differently.

So how do you get a relevant idea of the scope of the final product, its price and deadline?

Most of the time, when pricing software projects, we are somewhere in the middle of these boundaries.

Before a company embarks on custom software development, it may send an inquiry to multiple parties. How is it possible that different vendors generate bids with such diferent prices?

It's not just about the hourly rate of developers. The price of the development itself is just one aspect. A lot depends on what all is included in the bid price, and perhaps most importantly the quality of the bid itself, which is where the experience is written into it.

Particularly with novice programmers, we can see the attitude "The less you know, the more you think you know." It's relevant; everyone has to start as a junior. Often these cheapest offers don't work with anticipated obstacles and risks, possible functionality extensions or don't include everything.

A software project starts with understanding the client's intent. Why they want what they want and how it will help them in their business.

It continues with an analysis, which should be done well, in depth and with overlaps. Only then comes the actual development. Often underestimated is the testing phase, pilot deployment and user support in the first months of use. And almost always the price offer does not take into account the subsequent development of the product.

Many customers make the mistake of commissioning a developer rather than someone who can meet their needs.

This then leads to frustration with the result of the work.

So how do we usually proceed? We provide a rough price estimate for which the required solution covering the defined business needs can be delivered. The customer may not be able to define the exact brief, but he can tell you exactly what his needs and problems are.

Analysis - development - testing - deployment - support - development

We refine this estimate by processing the analysis. We always do this. We ask why the customer actually wants what he wants, why like this way, whether it could not be invented differently, simpler, more complex. We check whether our work trully solves the problems and will lead to the delivery of what the client needs. We use the know-how gained over the years. That's why we don't do analysis for free.

We set boundaries within which the price offered is valid. We develop, communicate continuously and play with "open cards" with the client. Our philosophy is to stick to the price offered. In a situation where we have really missed hard, we will ask the client to revise the budget. However, it is up to the client to decide whether to allow us to do so.

The agile way of development would of course appeal to us the most. Working in shorter iterations and continuously delivering and invoicing in batches and constantly refining the brief is the ideal approach to software development. Even the best analysis at the beginning always has unfinished details and always runs into unexpected obstacles. So far, however, we haven't come across a client who agrees with this approach.