When buying custom software development you have two choices on how the project will be bid;  Hourly or by the project.  So what are the pros and cons for both choices as a consumer?  And which one is the right decision for you? 

I’m not going to spend too much time on hourly projects because they are fairly self explanatory.  10 seconds into a phone call with a software vendor and you should have the hourly rate.  It’s a simple number.  However, the problem with hourly projects is that you’re at the mercy of the programmer.  If your told it’s about 100 hours of work then that number really has no legitimacy.  After you have paid for 100 hours of labor and you find that the project is only halfway completed, then you have no recourse.  This is particularly a problem with overseas companies whose only competitive advantage is low cost. It becomes a price war to be the lowest bidder.

What we are really debating here is risk and who is going to assume it.  When a project runs long, someone has to pay for it.  In an hourly project, the buyer is assuming that risk.  With a fixed price, the programmer is assuming the risk.  With software development projects there is inherently huge risk with every project.

The arguments for per project bids.

1  There is a cap on what you’re going to spend.  Theoretically there will not be any surprises.

2  There is never a “meter running.”  Your not making an investment decision every time you communicate with your programmer. You won’t have to ask questions like, “is this issue worth a $100 phone call?” 

3  If the programmer finds additional work within the scope that was unanticipated but must be performed, they can do it without having to come to you for additional funds. In those instances, additional work would otherwise be viewed as an attempt to generate additional billable hours.

4  This is the most uncomplicated way to work together. From the programmers perspective, they can put all of their time into coding your project rather than logging their hours. 

The problems with per project bids

1  It takes research time to create an accurate quote.  Depending on the size of the project, it can take 100 hours just creating an accurate bid.  Someone has to pay for that research. 

2  Once you agree on a price, the programmers job becomes getting the project done with the least amount of work in order to maximize returns.    

3  Fixed bid projects mean that you’re going to pay for the worst case scenario.  If a company is going to issue a fixed bid price and assume the risk then they are going to padd the price - after all they don’t want to come out at a loss on a project .  So with a fixed bid price that means that your always paying for the worst case scenario. 

So as a buyer, what is the smart solution for me? 

The per project bid guarantees you that you have a ceiling on what your going to spend.  You will sign a contract and it will encompass everything that your project is going to include.  If the project goes long, that’s not your problem.  With a fixed bid contract, you can begin to trust your programmer as now they are your advocate in getting this project done as quickly as possible.   And you have that contract to fall back on in the event the company you hire starts trying to extort additional dollars from you (assuming that the laws of your country apply to the programmer which is not the case with offshore software development).

One other suggestion is before committing to a programmer, google them.  If they have been around for a while there will be some feedback on them - either good or bad.  If there is not any feedback then you’re still stuck relying on your gut instinct.  I can’t tell you how many potentially bad situations we have avoided just by googling companies before we started doing business with them. 

Everyday we’re contacted by companies who need to build a custom software application to automate their business, or perhaps upgrade an older existing software system. One of the most important decisions to make is what technology to leverage to create it. For most applications the decision comes down to whether to build the system as a desktop based application, like Microsoft Outlook or Microsoft Access, or to build the system as a web based application. Today, most new systems are being built as web applications. Here are a few of the major advantages of using a web based architecture to build your new custom software application:

1. Multi-location capability- By building a web based application, you immediately gain the benefit of having your application be available world-wide through the Internet (if you allow it). It can be accessed by multiple locations for your business, or perhaps from your home office. While you can obtain a similar result using a desktop application, it would rely any many more technologies which add great cost, for instance dedicated Internet lines or pricey VPN software. A web application is a natural fit for a multi-location requirement.
2. Instant Update Deployment - When using a desktop application, anytime an update is made to the application you typically must re-install the application on each computer. In the case of dozens or hundreds of computers in a typical organization, the time and effort to simply install the updates can be high. Contrast this with a web application, where to make an update all you need to do is upload the changes to the central web server and all users instantly have access to the new version.
3. Vendor/Client Access - If one of your requirements is that your vendors, customers, or other business partners need to access your data in some way, then building a custom web application is the definite way to go. You can seamlessly create the ability to allow your vendors to log in and access the data that you define. Later, if you need your customers to access day, say view invoices or submit orders, you can create an area of the web application for them as well.
4. Higher Security- This one may take many people by surprise, as web applications in the past have been viewed as less secure. But the fact is that with web applications all of the internal coding for the system is kept securely on a central server. With a desktop application, however, all the code for the system resides on the users computer which provides a point of access for unscrupulous users to decompile or otherwise hack a desktop application. Using SSL (Secure Sockets Layer) all the data being sent and received by a web application is secured through high powered data encryption.
5. Zero Installation Problems- A typical issue with desktop applications is that they must be installed on each computer. This often causes great problems as users may be using different version of Windows, or perhaps other operating systems such as Apple Mac, Linux, or maybe the new Google Chrome. With a web application there is no install required. The user simply accesses the application through the Internet via their web browser, which they already know how to use since they use it every day to surf the web.

Building your custom software system as a web application usually makes a lot of sense. It might not alway be a great fit though under certain circumstances, but that’s a topic for another article. Contact us today and we can help you make the decision on what type of system you should build.

I’m often called upon by clients to recommend to them a good company to use as the host for the applications and websites that we build. We do offer the service ourselves, but sometimes clients like to split up their services between vendors. I suppose it makes them feel like they have a bit more control this way. So, over time we’ve worked with various other company from small time hosting companies, to big ones like Godaddy, then to specialty dedicated server companies like RackSpace. I hear lots of reviews on hosting companies from our clients, and keep a general idea of why they were chosen and how it works out. So, I’m going to share with you a few ways to NOT choose a hosting provider.

Read the rest of this entry »