It’s customary for service providers to offer a “free estimate” in an effort to draw in customers. This makes sense because in many service industries, building an estimate is a quick and simple process and providing it to the prospect brings them one step closer to closing the sale.  In the case of custom software development, in fact, an on the spot free estimate is most likely going to be inaccurate or even completely wrong. Here’s why:

Software development has too many moving parts.

As you can see by looking at a relative simple website development RFP process, there are a lot of variables involved in a full-blown development project, many of which are difficult to address up front without thoroughly exploring all the possibilities.  That’s one of the reasons we’re very selective as to whether or not we will even respond to an RFP.

Now, we can provide on the spot very rough general ballpark figures with limited details, but the estimate will come with a ton of caveats:

• This is based on what I’ve typically seen produce for the minimum set of features that would be viable to become a live application
• This represents a limited number of design revisions
• Integrating with 3rd party software like Quickbooks, Salesforce and other services can vary greatly because their are so many facets to it
• This assumes you would be able to identify and commit to a set of features in the software
• It doesn’t include any capabilities that are not currently outlined in the project parameters.
• … and on and on and on.

Because custom development projects involve so many variables and each one is truly, well, customized, even the most experienced developer will only be able to make a vague, educated guess as to what all will be involved in the final project.

Providing a quick estimate would be similar to a home builder trying to do the same.  Prices could vary tremendously in home building based on quality of construction and materials, location of property, size of home, finishing, etc.  Would you expect a home builder’s quote to be accurate after one conversation?  I would hope not.

A much better alternative: the paid analysis period.

Rather than forcing your developer to hazard a guess that you know is unlikely to be accurate, we’ve found the much better alternative is to hire the developer to produce a thorough analysis and development plan during an initial analysis period for which they are paid.

The typical deliverables that are part of the paid analysis period are listed below:

• Spec document – details how everything in the application will function, what options are available, and that limits scope
• Wireframe – layout of application screens without design (just black and white generic controls and data fields)
• User stories (use cases) – describing how the application will be used and by whom
• Mock Ups – the exact design (look and feel) of the application
• Workflow diagram – graphical diagrammed representation of the business processes that the application will adhere to
• Project plan – outlining the phases, development order and timeframes required

This initial analysis period could range anywhere from 12 to 120 or more hours, depending on the complexity of the project. Generally, it will cost between 7% and 15% of the full cost of the project. So, in relation to the full project, it’s a fairly small investment. But why is this paid analysis period such a good idea?

1. The paid analysis period offers both the client and the developer an excellent opportunity to “try each other out” without the commitment of a full development project at stake.
2. It allows the developer the time and resources to dive in and provide a thoroughly researched analysis of the client’s needs and desires (including identifying risks and risk mitigation techniques), resulting in a concrete fixed fee quote for the full project.
3. It provides that fixed fee to the client, which actually has budgetary value since it’s based on enough research to be relied upon as long as project parameters don’t change.
4. It allows the developer and client the opportunity to collaborate on fully documenting the project parameters, analyzing every available option, and agreeing on exactly what will be expected of the software to be considered satisfactorily complete, including a workflow.  Elements that are beyond the scope of the project (and will not be provided) will also be identified.
5. It allows the developer to provide a wireframe and/or visual mock-up of the design that can be vetted by the client.
6. It minimizes miscommunications and misunderstandings regarding project scope, features, integration, and design, saving time and money over the long term.

In short, it allows both parties to enter into the development phase of the project with eyes wide open, both fully onboard and committed to a successful outcome.

But what if, after the paid analysis period, the client decides to move on?

As noted above, the paid analysis period provides an excellent opportunity for the client to gauge their working relationship with the developer and decide if they want to move forward with the full project with that team.

One of the truly beautiful benefits of the paid analysis period is the fact that, when it’s over, the client has a fully-documented report and mock-ups in hand that can be transferred to any other developer so they can hit the ground running. Since no actual coding has been done, the transition will be smooth. And since everything is fully documented, there should be no need for the new developer to spend time or money reanalyzing the entire situation.

Instead, they can jump right into development at a cost between 7 and 15% lower than they would have had to quote if the analysis had not already been completed.

Really, offering a paid analysis period offers the best option to everyone involved.  It provides both the client and developer an opportunity to work together and explore and document the various facets and complete depth of the entire project.