Really interesting that these situations seem highly unacceptable to people, but we hear this kind of stuff all the time…check it out:

This is specifically focused on people who are building E-Commerce websites, however the advice does translate pretty well to most situations.  I think at times the pricing discussion goes a bit out of bounds in terms of the upper limits (wouldn’t we love to be charging those rates!?) but the lower to mid-range pricing discussed seems to fit with my view of the web development landscape.

On thing missing in this discussion is the concept of Intellectual Property and who owns the output created by the company you’ve hired.  Always make sure that is stipulated up front in all contracts because the answer to the question is often a surprise to the individual or organization paying the bill.

I’m sure by the end of the speech, they wish they had just asked me how business was and received the boilerplate “going well” response and moved on to the next topic.  To be really simplistic, in work that we do for clients that is project based, we need to make enough money to arrive at an hourly rate that delivers some measure of profit for us, and results in the client feeling they paid a fair price and receive what we hope is outstanding work and results.  Any less than that, and we start “chewing” through our own profit to the horrific point where work we’ve promised to complete in a given time and budget goes so over our expected time that we’re into actually paying to get this work off of our plate.  So…you win some, you lose some I guess, hopefully resulting in a profitable company overall.

Working on a fixed price presents many challenges that often lead to negative results.  What “fixing” a price means is that you’re gambling on your ability to deliver a completed project, with a vague sense of requirements, within often an arbitrary sense of time driven often by a client’s perceived need for the application.  If that sentence doesn’t drive fear into your heart, read it again recognizing that although there is a fixed number in the proposal, and a fixed time in which to deliver the work, nothing else is actually “fixed”!  Working on an open ended basis is equally scary to clients, and rightfully so.  What generally ends up happening is something somewhere in the middle where we’re fixing to a budget, but not necessarily guaranteeing the output given that it really never is truly “defined” early on in the work.

So…if you asked a builder to give you a fixed rate on a house, and to get it done in 3 months, and said that you need “3 bedrooms, maybe an open concept kitchen and family room, nice basement…yeah that’ll do it”  How do you think they’d react? Quite differently than if you presented them with detailed architectural drawings and materials specifications for all surfaces.  So certainly a web application with highly defined technical specifications presents a more likely chance that you’ll know what you’re getting into, but as we often say, building something technical like a web application isn’t like building a house.  We are often faced with technical challenges that can easily force work with a previously known timeline to bulge 50 percent or even more at times.  

In addition, the concept of Agile web development methods (popular approaches these days) suggests a more iterative and collaborative approach that emphasizes and implies minimal planning and definition.  The bottom line, is that forecasting an accurate fixed cost for even the most well defined application is a big challenge.  Even the best project managers can be challenged with resources and scope through these projects because the reality is that the initial vision and the final product are rarely identical and often are radically different.

So…How much does a web application cost? You’d think after reading this the best answer I’d be willing to give is “I don’t have a clue”!  However the best way to describe it may be that it needs to be based on the time and effort required to build the desired outcome…just that the desired outcome is harder to predict at the start than you’d like it to be.  Others are applying more innovative approaches to their work in this field which are very interesting and suggest that some creativity is required to truly meet the needs of the new consumer.

We’ve always taken the stance that we should treat every project as a new challenge and base the decision on a number of factors including the timeline, budget, available resources, likely future direction and others. In some cases, clients rely on us to select the platform, in others, they choose the direction. In either case, the factors to decide are not always the same for both the developer and for the client.

As a client, you need to decide what are the key factors for you. Some of them will no doubt include:

• budget – If I select platform A, will it be cheaper than platform B in development and maintenance costs
• available resources – in the case of the client, not what’s available at the chosen developer’s shop, but the ability to find people outside of that shop should the need arise
• longevity – is this platform new, old, maintained and advancing, or is it dead and with no future plans
• performance – is the selection of a particular platform going to impact the speed and reliability at which the application delivers information and services to its clients
• source – is this an open source project, a proprietary technology, or something else?

The last one is often one that requires further explanation. While it may be out of scope of this posting to discuss the concept of Open Source, these types of platforms are generally free and take advantage of a large pool of developers that participate in the development of the platform for the greater good of all involved. While many are strongly in favour of developing using Open Source tools, we have delivered successful projects and products in both worlds and have experienced victories and challenges in both cases.

As a client, in general, you need to make sure that you are getting the job done with a set of tools and technologies that are proven, have potential to gain advantage from future upgrades, and that there are people out there to help you should the developer become unavailable.

In addition, some platforms have great strengths that truly only begin to surface when the development project is large and/or long-term. Spending more on the initial development can be a worthwhile investment in these cases, and a wasteful spend in cases where the project is simple in nature.

What about the all important “scalability” factor? I find that clients are often in need of a solid dose of reality here. In many cases, the chance for a true problem of scale is extremely low. Does that mean one should ignore the issue? Of course not, we feel that one should prepare for an eventual problem of scale, but should not sacrifice short-term efficiencies and extend the budget for what “might” happen. We all want to believe that our application will be extremely popular and lead to great success; however, one should consider how to measure success so that a proper decision can be made on how much effort to devote initially to this issue. In many cases, one can deal with the problem later once the application has been proven and begins to show the potential to become a “scale” issue (often more money is available through greater revenue or investment at this point).

So where does that leave you as the client in search of answers and a development partner? In any business relationship, you need to work with someone you trust. As in all relationships however, you cannot trust blindly. Make sure you challenge your development partner on their recommended choice (or yours!) and make sure you are comfortable with the answers they are giving you. Each development shop will have their preferred ways and means of developing websites, but the developer needs to make sure they properly explain the pros and cons of each possible alternative so that you the client can be confident you are going in the right direction.