Money is such a stressor that it often keeps a business owner from jumping into the deep end of the pool to reach the potential that the business could become. Software development is even worse. It’s hard to evaluate something you don’t understand and even harder to know if you’re getting a good deal or hiring the right developer.

The first question is whether custom development and the associated costs are worth it. Without understanding the time and effort required to build an application, custom development prices may seem high compared to commercial application options. And frankly, they are. An off-the-shelf application has been developed with a general business model in mind so it doesn’t fit anyone eXactly, but is close enough for many. The creators of the application make back their investment through repeat sales so the cost per sale can potentially be fairly low. Customization may or may not be an option after the sale, so eXpect to adapt at least some business processes to match the features and workflow of a commercial application. That is the trade-off for a lower price tag.

Custom software is designed specifically for your business model and workflow. You are the only one with that product and all of the time and effort spent to create it is done on your behalf. The value of custom is that it handles all of the work requirements you decide should be included and is designed to make your business much more efficient. As the business grows, the custom app can be tweaked to accommodate that growth. That means less time doing manual procedures or using workarounds to meet your work requirements for years. The trade-off here is that it costs more up front to build the perfect app and it will take more time to get it up and running. The return on investment, however, can potentially be huge in reducing operating costs while allowing for business eXpansion as employees refocus their efforts in more productive directions. Because any licensing costs are usually dramatically less than with most commercial solutions, surprisingly, it can often be less eXpensive than a commercial option in just a few years.

Pricing

Before deciding which is the right direction for you, it is helpful to understand the pricing structures developers use and how they use them to try to charge a fair price for their services. Hopefully, by gaining a little insight about the different billing models the evaluation process will become clearer.
Most developers use one of three pricing scenarios — a fixed bid (quote), a fixed bid with change orders, or an estimate. All of these methods are based on developer estimates. None of them can guarantee how long the actual work will take and no developer can calculate the eXact amount of time a project will require. Therefore, all methods are formulated from a “best estimate” based on the known elements of the project.

A note about developer accuracy in estimating. If the price seems too good to be true, it probably is. A novice developer will generally underestimate the amount of time needed to complete the project and will offer an estimate or quote based on the eXact amount of work that’s projected to be done (with no allowances for the unknowns). A seasoned developer will do a better job of estimating the necessary time, both in hours and in calendar days. Their estimate may be higher but that’s because their eXperience allows them to anticipate, and account for, roadblocks that could pop up and cause additional development time and money.

Once the project is under way, the developer who underestimates the required time may walk away when they get to the point of diminishing returns — especially if they hit a development snag and realize they can’t turn a profit finishing the project with all of the requirements. That usually translates to cutting corners and omitting things that would make the finished product perfect. Some will stand by their word and take a financial hit to finish the work. The eXperienced developer, however, knows that a successful project always takes a bit longer than anticipated and has considered this when compiling the estimate.

Quotes, Bids and Estimates

• Quote: A quote is usually a fixed price that the developer gives to the client after going through a discovery phase to determine as many of the details of the project as possible. Generally, this employs a very rigid requirements document and a well-defined scope of work. Whether the development time required is more or less than the amount of time that price represents, it is what the client pays. Period. Developers who use quotes without change orders have to make a best guess about how much additional time will be required for the unknowns and inevitable changes and add that to the quote. You pay for that time, whether it is actually used or not.
• Fixed bid with change orders: Most often a quote comes with allowances for “change orders.” In this model, the same process is used to arrive at the initial bid as with a quote. However, if the project scope changes and new functionality is added after the scope document is approved by the client, the developer adds an up-charge for each change. In this model, it is possible for the initial quoted project price to be reasonably low and the final price to be many times higher. Keep in mind it is rare for a project scope to remain the same from start to finish so cost eXpectations should be adjusted accordingly. The changes and additions are commonly called “feature creep.” They happen because in the process of reviewing your workflow to create an app that accurately reflects it, you will re-evaluate and modify some processes along the way and you’ll want the completed application to incorporate these changes.
• Estimates: With this model, the developer and client go through a reasonable amount of discovery, which may be a little or a lot depending on the complexity of the project and the amount of known information. Based on the scope of the project determined in the discovery phase, the developer or project manager makes an accounting of the number and complexity of the features and gives a range of the eXpected hours it will take to build. This is not a hard and fast price but a best guess based on eXperience. The client is then billed for the actual amount of work time required. Many people are uncomfortable with what they view as an open-ended price, but they are generally presupposing that the project will go beyond the high end of the estimate. This is not necessarily the case, especially in the hands of a seasoned developer. With an estimate, the client pays for the actual amount of development time. The final cost may actually come in lower than the estimate.

Feature Creep

The danger in all billing methods is the previously mentioned feature creep. One of the great advantages of custom software development is that you often recognize potential improvements to your workflow as a result of defining it in detail for the developer. Being able to modify the application while it is in development can improve your overall business efficiency. You want to take advantage of that as long as the feature creep doesn’t overwhelm the development process. If left unchecked, it can easily cause the project scope to get out of control and/or eXceed the budget.

This is why an “open-ended” estimate feels like a black hole and a quote feels like a tidy box. Time management all depends on how modifications are handled. A strategy for dealing with modifications should be determined at the outset so that it is a benefit and not a hindrance. Feature creep can be easily controlled by focusing on the priorities first and saving bonus items for later in the development process. A good developer will help you identify and manage feature creep, ensuring that core priorities don’t fall to the wayside in favor of more eXciting new features. Your developer should categorize features in terms of needs vs. wants and tackle the needs right out of the gate to ensure they get done.

Rates

Two concepts are worth mentioning here. The first is the rates developers charge. Software development may feel like the Wild West but developers by and large tend to charge what they feel their skill is worth. Low-priced developers are often young (in the sense of time in developing their skill), inexperienced (with the technologies) or slow (haven’t mastered the techniques efficiently). The price seems right, but the work may be subpar or a lot of hours end up being billed because of slow development. More eXperienced and skilled developers are more thorough, quick to resolve development challenges and faster to produce the final product. They charge more per hour but bill fewer hours. The overall cost often works out about the same but can come with a noticeable difference in quality.

The second concept is the three intertwined factors of any service: good, fast and cheap. The rule of thumb is that you can choose two of the three, but you can’t have all three. If the product is good and done fast it will be eXpensive. If it’s done fast and cheap it will not meet eXpectations. If it is good and cheap the developer has to spend time on other paying work to afford the time to make it good at a low price, which requires eXtra calendar time. You choose which two are the most important factors.

Billing

• Fixed: The quote proposal defines both the scope of work and the final price, as well as the billing increments. Commonly, the agreement will be for some form of half down and half on delivery or payment in thirds with 100% paid before the finished app is delivered. Payment before delivery protects the developer from disgruntled clients refusing to pay for time and effort on their behalf.
• Hourly: This usually means some method of hourly pricing based on the actual hours worked. This could be billed at a straight hourly rate or even by the day, week or month. It can be handled as a pre-pay retainer or invoiced at regular intervals during development. In this scenario, the developer may deliver several intermediate builds and a finished product when the work is complete. Because this is a pay-as-you-go arrangement, developers tend to feel more free to share the work as it unfolds because they have been compensated for their time along the way.

Now that we’ve established how to approach the prospect of custom software development with the right mind-set and eXpectations, it’s time to dig into proper planning. In the next installment, we will discuss the planning and organization of development, including how to define the scope of the project, gather the necessary information for your developer, and delegate responsibilities.

If you missed Part 2, find it here: What Should You Consider When Selecting a Development Partner? What Questions Might You Ask a Potential Developer?

Read Part 4 of 7: Coming soon — Making the Plan for Planning Your Plan of the Project Plan