To clarify, I don’t run any ecommerce sites myself, this is just what I see from working with ecommerce clients daily.  The bar is being raised for ecommerce success.  You may not have to do all these listed above, but you will have to do most of them, and do them well to succeed.

By now, we all know that the website for the “Affordable Care Act” (aka Obamacare) is a mess.  Not “was a mess”, but still is, 3 weeks after it launched.  Here’s an article with screenshots, and comments on various errors encountered.

As programmer, a major lessons can be learned from this failed rollout:

1. Make it work – even though the initial failures were blamed on the high volume of users, it’s become clear that there are functional problems with the code and databases.  If it were purely a capacity issue, after a few days that would have subsided as the volume decreased.  Instead, problems have persisted.  Now we are hearing that the whole thing might have to be rewritten and insurers are complaining about getting mangled data from the system.  Luckily, the government has a monopoly here, and “customers” have no where else to go.  If you launched your website in this way, you’d be finished.  If the site isn’t ready, delay the launch until it is!
2. Make it simple – in order to see any pricing for the various plans, you need to give pretty much all your personal and family information.  That means many screens of data entry to get to the pricing.  Any e-tailer will tell you this is a kiss-of-death.  You need to show customers the pricing up front, including shipping, return policies, etc.  Nobody wants to go through a lot of hoops only to find out they don’t want to buy.  Again, in this case consumers don’t have a choice, but in the real world you can’t operate that way.
3. Settle on the design early – one complaint I heard (and I believe it) is that the programmers on this project were dealing with constant changes to the requirements – requiring whole sections of code to be rewritten or discarded.  While it’s important to be flexible on functionality, at some point (long before the launch date), you need to make solid decisions and stick with them.   Better to launch with an imperfect user interface, than to launch with something that is buggy or doesn’t work at all.
4. Beta test – big companies like google and facebook routinely “roll out” new features to a select group of users, usually by invitation only.  Then after a few weeks, they expand the rollout to everyone.  I didn’t hear about any such rollout plan for healthcare.gov.  Instead, they chose the “Big Bang” approach – and when the big day finally came, we got a big “thud” instead.
5. Don’t forget Security – I’m not sure the healthcare.gov site is “insecure”, but I worry that it is.  Why?  Because all the errors suggest that the programmers were scrambling to fix basic bugs, and functionality errors.  That means that any “security testing” that was done was incomplete.  It had to be, because the site was changing up until the last minute.  It’s like inspecting the wiring in a building while the electrician is still there working.  You can see what’s been done, but you can’t vouch for what is not complete or needs to be changed.

Many of these may seem like common sense, but it’s easy to lose sight of these when you are working on an exciting new opportunity.  It comes down to simple execution of the fundamentals.  The internet has matured to a point where user expectations are very high – so make sure your site meets them.

No matter what kind of website you run, it’s important to test it on a regular basis.  There are several reasons for this:

1. Hosting changes – your hosting provider could tweak settings, or make bigger changes without telling you.  Any of these could break the functioning of your site in some way.
2. Programming changes – any changes you and/or your programmer makes can have unintended consequences.  Something could break in an unrelated area.
3. 3rd Party changes – any 3rd party sites that you integrate with – Facebook, authorize.net (credit card processors), ad servers, etc. can modify how their API’s work.  If this happens, your site may break.

I often have clients notice an issue with their site and I ask “when did this first occur?” and they aren’t sure.  In some cases, I can tell the site has been like that for months, maybe years.  The client simply never noticed the problem, until a customer pointed it out.

So, how should you do this?  Come up with a plan for testing various and critical parts of your site.  If you are an ecommerce provider, this means actual transactions.  Set up a coupon that let’s you buy something for a few dollars, and put through a transaction using all payment types you accept.  Test all relevant components of your site.  The frequency of the test should be related to how important the site is to your business.

Doing this routine  testing has the side effect of giving you a chance to review your customer experience, noticing areas that might be improved.  But it is important to keep a close eye on how your site functions.

If you want to sell online, there are many options, ranging from setting up your own shopping cart to using ebay.com or etsy.com to list your products.   I’ll examine the main pros and cons to each approach.

DIY – I’m calling the first approach DIY (do-it-yourself).  This is the approach where you either build or buy shopping cart software and run it on your own website.  You essentially pay once for the code / license, and then you are on your own.  One example of this that I have used extensively is Sunshop, which is php / mysql based.  Here are the pros and cons to this approach.

Pros:

1. Unlimited customization – if you get source code with the cart, you can customize (or pay a programmer to do it) the code to behave any way you want.  It can match your website in design and navigation.
2. Lower monthly costs – Usually you pay a one-time license fee, with optional yearly support and upgrades.  This cost can be drastically lower than paying a monthly fee and transaction fees imposed by hosted providers.
3. Stability – If you are happy with the product, you keep it the way it is.  You are not subjected to upgrades / modifications to how features work, or features you like being phased out.  If the original vendor goes out of business, you still can run the software since you own the license.
4. Data Ownership – You have access to all your data – products, customer information, orders, etc.  If you need to change carts in the future, or manipulate the data in some way, you have it all at your disposal.

Cons:

1. Up front costs – You’ll have to spend perhaps thousands of dollars to buy the license, install it, and get things up and running.  If you aren’t sure your products will sell, this can be a daunting investment.
2. Upgrades – As features are added to the product, you’ll need to upgrade your copy – this can be relatively easy, but if you have customized your version quite a bit, you’ll find upgrading to a challenge.
3. Security – Any security issues, PCI compliance, etc., are your responsibility.  This can be scary if there are any bugs in the code that hackers can exploit.

Hosted – third party – This approach consists of paying a monthly fee to use a hosted shopping cart solution.  Companies like volusion.com or 3dcart.com offer this type of platform.  Also ebay.com, etsy.com, and others fall into this category.  You set up your products and manage your store on their platform.  Here are the pros and cons:

Pros:

1. Easy setup – These systems often have wizards to walk you through setup, and you can have your store online literally in minutes.   There may be tools to quickly import your products as well.
2. Low entry fee – No need to pay for installation, or a license fee.  Some do not even have setup fees and may offer a free 30 day trial.
3. Traffic – Many solutions like etsy or ebay bring in traffic and allow searching across all merchants.  So you instantly will have people looking at your offerings, which can start bringing in sales quickly, with little advertising.  This can help prove out demand for your products without a huge investment.
4. Automatic upgrades and security – The hosted provider will be responsible for maintaining the security of the platform, and upgrading features on a continual basis.

Cons:

1. Fees – Generally, you will pay a monthly fee and/or a transaction fee based on the amount of sales you generate.   These fees can go up without much notice.
2. Dependence / Lock in – If fees go up, or a feature you need isn’t implemented, you are stuck, at least in the short term.  You would have to either live with the limitations / cost, or move your store to another platform altogether.  Moving to another platform means pulling your data (if the host allows a full export), and import it into another cart system.  This can be time consuming and expensive.
3. Security – Large cart systems which have many merchants are big targets for hackers, simply because of all the financial / customer data stored in one place.  Although these carts are generally pretty secure, you can be sure they are constantly targeted by hackers trying to find vulnerabilities.

In the end, there’s no easy answer to the original question.  Over the years I’ve seen (and encouraged) clients to go with one type of cart or another, based on their particular situation and budget.  I think option 2 (hosted solutions) are gaining in prevalence, at least for smaller merchants, who are selling small volume on the side.  However, if you have a high volume of sales, and want to build your brand, the DIY approach will probably yield better results over time.

It’s not the end of the week, but I’ve missed a few weeks now, so I thought I’d catch up.  Here’s what I’ve been doing:

CodeIgniter – A new client has a custom CMS written using CodeIgniter.  This is a fairly popular php framework that several of my clients use.  It’s pretty nice to use – follows the normal MVC architecture.

Sunshop – I did some custom work to tweak the way Sunshop makes its SEO friendly URL’s.

In addition, the normal php and perl work rounded out my schedule.