How to estimate and charge for software development

Hi Valentin,

For projects that are fairly open-ended, you can provide a fixed quote that takes into account enough buffer to ensure you are safe. The downside is that could mean losing the opportunity due to having a price that's not competitive. However, that's better than risking your business / layoffs on what could become a wildly unprofitable project.

There are plenty more ways to go about it, but in the end it's going to come down to either (1) determining the price where you feel you have derisked enough to make the potential reward worthwhile, or (2) seeing if someone with experience in the project area can give you a more accurate estimate.

Wish you well with this!
Ryan

Hi Valentin,

Adding more to Rayan’s point and also elaborating a bit. As a feasibility study you could check over internet if the problems are solved by others. Are there any clue/logic/open-source implementation of them? They could be your exact problems or similar to them. The respective developer can understand the ways. This will help you to identify the blockers if any. Because blockers are the ones which shoots you away out of your estimation. Once the logics are understood break the problem statements into various small demonstrable outputs and estimate them. For any Output there is always an easy part, average part, hard part and harder part. Easy or certain part which you can estimate correctly, because it done earlier, but add few buffers time to hard + harder part.

So, if you don’t have any expert to suggest & estimate, above is way you could approach.

As Rayan mentioned you should always balance between your good/exact estimated time-line and bagging the project. Sometime you need to estimate tight (effective/billable hours) in terms of providing cost but could stretch the calendar deadline through project management negotiations.

Thanks,
Sandeep

Hello. No one has experience in estimating unknown work. There is plenty of effort estimation methodologies and they all are not exactly correct. You can use one of the methodologies used with Agile. Like the one when the team gets together and each member has a card where he/she writes her estimate and puts card face down. Then when everyone is ready cards are opened and members with biggest and smallest estimates explain their numbers and team discuss. Then you repeat the cycle with cards, and repeat it until all numbers are the same or very close. There are other methodologies, but this one is very popular. You can Google for "agile effort estimation methodologies" or like this.