This is a really neat discussion that I’d love most clients to see. For some reason, the fact that we’re a “service” business working in a “knowledge” industry seems to give clients the impression that they can barter/bargain more than in other situations.
Really interesting that these situations seem highly unacceptable to people, but we hear this kind of stuff all the time…check it out:
Probably difficult to believe I can be impartial about this since we’re clearly trying to convince prospective clients that we’re a sound choice to be their web development partner…so rather than take too long myself here is an impartial third party’s viewpoint on “Selecting a Web Designer or Developer.”
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’ve been struggling with this for many years in this business, and I’m sure will continue to struggle with it for years to come…if I had the proverbial nickel for every time someone asked me “How much does a website cost?” I’d be a rich man. After being posed that question I launch into my semi-rehearsed diatribe of how we figure out what the heck to charge someone for the services and development which we intend to provide to them.
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.
You need a web project built…and you need to select a platform on which to base your new development project, and a partner to build it. So how do you do it? What are the key factors in the selection of the right platform? Is there a “right” platform? What are PHP, .NET, XML and all of these other acronyms anyway? These are all good questions and ones that need to be considered before making that all important decision.
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.