Cost of acquisition

One of biggest the factors that decides which technology is used in the application stack is the cost of acquisition. I've seen many application architectures drawn on a whiteboard where the technical team was embarrassed to show them, but they justified the design by trying to keep software licensing costs down. When it comes to the database environment, the usual suspects are Oracle, SQL Server, MySQL, and PostgreSQL. Oracle, the dominant player in the database space, is also the most costly. At the low end, Oracle does have reasonably priced offerings and even a free Express Edition, but they are limited. Most people have needs beyond the low-priced offerings and fall into the enterprise sales machine of Oracle. This usually results in a high-price quote that makes your CFO fall out of his/her chair, and you're back to designing your solution in order to keep your licensing costs down.

Then comes Microsoft SQL Server. This is your first reasonably viable option. The pricing is listed on the Microsoft website. I will not reproduce it here because the pricing schedule is too volatile for a book that will remain in print for a longer time. Nonetheless, an experienced thumb value of the purchase cost for SQL Server will get you running with a web-capable model for about $5,000. This does not include a service contract. In the grand scheme of development costs, this is reasonable and not too high of a barrier to enter.

Then, we have the open source offerings such as MySQL and PostgreSQL. They cost nothing and the service contracts cost—wait for it—nothing. This is a very hard cost of acquisition to beat.

Remember, in the beginning of the chapter, when I was talking about all the things that you don't know when the project starts? Here's where the real win comes in. You can afford to fail.

There, I said it!

Low cost of acquisition is a synonym for low cost of failure. When we add up all of the unknowns for the project, we find out that we have a fairly good chance that the first iteration will not meet the market needs, and we need to find a way to jettison it quickly without long-term contracts and the additional costs of spinning up a new project.

This allows the project manager to move on to the next version using lessons learned from the consumer after the first version. Hopefully, this lesson in user acceptance will come at a very low cost and the project will then begin to thrive in the following versions. Don't let the success of the project hang on getting the first version perfect. You won't!