Pricing Ecommerce Web Design Projects
I would like an e-commerce site just like someothershop.com – how much would that cost me?
It’s a common enough question, and one that always leads your average freelance web designer to take a deep breath and sigh ‘Well, let me see …’. There are many factors that influence the cost of an ecommerce web project, but when you communicate the vagaries to clients, there tend to be three that can have a huge impact – and are often only dealt with summarily: products, postage and payments.
Obviously enough, both the nature of the products your client sells and the number of them will impact the amount of your time spent in development.
If they’re selling a widget that comes in one size, one color and you can only buy one of them… well, straightforward enough. However, most people aren’t selling such simple items. Products with multiple options (sizes, colors, etc.) will likely be more complex to set up. Similarly, products with a number of associated images might need to be handled differently.
Urge your client to take the time up front to properly organize their product database.
Then, the sheer number of products comes in to play. There’s not much technically different about an ecommerce site handling 100 products to one handling 10,000 products – they all need to be treated in the same way (searched for, displayed, added to a cart), but it can have a huge impact on the development time. If you’ve got 5,000 products each with 3 images, 2 paragraphs of text and a couple of options, well that’s going to take longer to configure than might otherwise be the case.
Urge your client to take the time up front to properly organize their product database. Create an excel template for them containing all the information you’re going to need from them on each product. They’ll need a column for any unique identifying codes, a column for image file names, a column for price, one for description, one for shipping cost (more on which in a moment), and so on.
If, at the time of generating your proposal, the client cannot send you a sample of their data or confirm that they have all their materials ready to go, then you’re going to need to factor that into your proposal. Get your client organizing themselves early – it’ll save you a ton of time later on.
Postage is such an overlooked aspect of pricing ecommerce websites. Often, it’s going to relate to the platform you’re developing with – off the shelf ecommerce packages will have their own predefined methods impacting how you can charge postage for orders. Magento, for instance, has a variety of options – flat rate, table rates, courier pricing, etc. Trading Eye offers postage estimates, postage by weight, free postage, fixed rate… and so forth.
These can be customized, but at what cost? If your client needs something unusual, be sure to factor in the cost of developing a new module/method for the platform you’re developing with. I recently worked on a project for an online florist where we had to factor in the driving distance (not straight line distance, driving distance) and local fuel prices in determining final delivery costs.
A thorough understanding of how the client is going to want to charge for delivery will impact whether you’re proposing an off the shelf solution or if you’re going to develop a bespoke ecommerce project for them – with obvious cost implications.
In order to take money online your client needs a means of securely processing a credit card. That usually means one of two things: taking money with a 3rd party payment provider, or using a standalone system like PayPal. Each have their advantages.
With a third party payment provider your client provides a seamless shopping experience for customers. It’s a good way of doing things if you’re after that integrated experience. But it will likely cost more of your time. Working with the payment gateway’s API may be new to you and if your client’s bank requires PCI compliance then be prepared to add in a number of developer hours in getting the site and hosting set up correctly.
PCI compliance is becoming increasingly necessary – but not any easier to get right. Using an off the shelf shopping cart system can help – securing URL’s and other holes so that you don’t have to worry about them. But your own code is going to be used to integrate the payment provider – so you’ll need to be on top of the latest security concerns. You’ll need to be more discerning when choosing a hosting plan too – typically either a dedicated box or dedicated virtual server will give you the level of server access you will require.
Using a standalone system removes a lot of that complication. PayPal, for instance, will handle all of the payment security concerns. As a developer, you never come close to a credit card number and since the transaction is processed entirely off of your site, you’ve no worries over SSL certificates or hosting requirements. It’ll take you much less time to set up for your client, and cost them less as a result. But although consumer trust for services like PayPal has increased over the last few years, at the end of the day, it’s nice to complete the whole transaction on the one website. PayPal’s not for everyone.
All ecommerce sites serve the same basic function: display products, have a shopping cart, allow checkout, and allow the client to make changes themselves. But not all ecommerce projects are created equally. In my experience, these three factors can have a significant bearing on final cost – and discussing them up front with your client will help establish with them how complex their project is, hopefully leading them to a better understanding of your cost.
What are your experiences? Any instances where one particular factor wasn’t considered and ended up costing you or the client more than anticipated? Please share.