Adam McFarland

We’re growing fast right now, very fast.  It’s exciting stuff.  In 2007 we spent the majority of our time assimilating as a team, determining which projects could drive the most revenue, and looking for a warehouse.  We had a very good year, but 2008 has been a whole new story.  Everyone knows what to do and all four of us have just been executing all day long.  The result has been a 2-3 times growth in revenue every single month this year so far - pretty impressive in my opinion considering we have no employees and didn’t take any outside funding.

However we have had an increasing communication problem.  Everyone was accomplishing stuff so fast that the remaining three partners had a hard time keeping up on everyone else’s progress.  Minor things would slip through the cracks because of a lack of communication.  We only have one day where we are all in the warehouse (Monday) so we only have one full team meeting per week.  The rest of the time we’re on our own.  It was becoming clear that weekly updates weren’t quick enough.

For example, we started a big sale on Detailed Image during a 1 hour down time for our credit card processing service.  George and Mike were running the sale, Greg and I were the ones aware of the downtime posting.  Consequently, I posted a message on the site that our credit card processing was down just as the sale was going off.  Not a huge deal - the sale ended up being a success - but it highlighted an increasing communication problem that was coming from the fact that everyone was just accomplishing so much every day and didn’t have an effective way to communicate what they did to everyone else.

We needed a way to quickly communicate simple things such as “we’re out of Flex Buffers” or “a shipment of Chin Up Bars came in today” or “I made a minor fix to the shipping system”.  Instantly I thought of the micro-blogging phenomenon Twitter, which allows you to post mini blog posts of 140 characters or less from your phone, the web, or a slew of other places and then others can read them on your twitter page, get updates on their phone, or subscribe to your RSS feed.

Unfortunately there are two problems I saw right away with Twitter:  it isn’t secure and it doesn’t allow multiple people to post to a singular feed.  When I checked the list of API apps I couldn’t find one that solved those two issues.  I ultimately decided against it because of the fact that our confidential company information would be stored in their database and we just can’t have that.  I wanted more control, but I didn’t want to build something from scratch.  A solution needed to be something I could throw together in hours, not days or weeks.

When we met about it we talked about our other options:  Skype or email.   Skype doesn’t work because it interrupts you.  A response is expected when you receive an instant message.  I don’t need to be interrupted with a message from George telling me we’re out of a product.  I just need to know within the next day or so in case I’m interacting with a customer or processing an order with that product.  Skype also relies on all of us being on our computers all day long to receive messages, which we’re not.  So we turned to email.  It worked OK for a couple of weeks, but my biggest problem is that most of us only check our email 1-2 times per day.  I don’t want to open my email every time I want to notify them of something I accomplished.  I also don’t want all of us clogging inboxes up with these updates.  On a basic level, email messages should be items you need to take action on, and these updates are updates that do not need a reply.

Our Solution

Then I had an idea:  customize a version of WordPress to make a micro-blogging system to meet our needs.  In addition to the multi-user and security issues, I needed to create something that integrated into everyone’s existing routine.  If the solution required a new application to be open or a new web page to visit, it wouldn’t work.  The only thing that really fit the criteria is our Google Apps page that we all have set as our default home page on our browser for our shared task lists, wiki, documents, and email.

Here are some pictures of the completed product.  The Google Apps page:

The login page that displays when trying to access the blog:

The blog home page:

Step By Step Instructions

These instructions assume you have a domain, hosting, and a working knowledge of WordPress and development with PHP/MySQL.

1. Install WordPress on your domain, making sure to uncheck the box that says “I would like my blog to appear in search engines like Google and Technorati”. This ensures that WordPress doesn’t ping search engines and blog directories with updates of your latest posts.  Even though we will password protect everything, we need to make sure that none of the blog gets indexed, including the RSS feed that WordPress produces.
2. Install and customize a simple WordPress theme.  My choice was uTheme.  The idea here being to have something simple and easy that people can use to read the updates, post a new update, and access the secure RSS feed.  Everything else in my opinion is a waste.  I went in to the template files and removed code for comments, categories, and other miscellaneous stuff on the sidebar.  Our posts only include the title, the body, and the date posted.  Our sidebar only has a search box, a link to post, a link to the secure RSS feed, and the archives.  For the link to post, I linked directly to the wp-post.php page so that logged in users are only a click away from posting.  In addition, WordPress returns you to the last viewed page after a post, so if you come from the home page of your blog you’ll be returned to the home page after a post, minimizing the clicks your users need to write a post.  I also changed some of the colors in the CSS to match our company colors.
3. Create user accounts for all potential users and modify WordPress to display who posted in the title.   I created accounts for all four of us with our first name as the name on the account.  I then called the <?php the_author(); ?> function to display the author of each post everywhere the title is displayed (home page, permalink page, and feed).  This way I can make a post and my partners can instantly know that I wrote it.  For example, if I wrote a quick post entitled “Inventory updated” WordPress would display it as “Adam:  Inventory updated”.
4. Install the WordPress Password Plugin.  This password protects each page of the blog, preventing unwanted visitors or spiders from viewing the site.  In the configuration file you can set your password and can identify specific pages to not be password protected.  You should disable the password protection for the RSS feed (we’ll password protect this in a different way).   I also customized the login.php page of the plugin to look a bit better aesthetically.
5. Use FeedBurner to create a password protected feed.  “Burn” your unprotected feed and go to Publicize -> Password Protector to password protect the feed.  Use this feed for everything related to your blog.  DO NOT give anyone the URL to the original unprotected WordPress feed.  That is not password protected and is most definitely the weak point of this system.  I’d also advise against putting the URL of this blog in your robots.txt file - it isn’t going to be indexed if you follow these steps, but by putting it in there hackers could potentially find the location of your feed.
6. Use FreeMyFeed to securely pull your feed.  Most (almost all) feed readers do not support password protected feeds like the one we just created.  Enter FreeMyFeed.  They provide you a unique URL for your feed.  As long as you don’t give this URL away, you should be safe to use this feed in any manner that you use a normal feed.  According to their site: “Usernames, passwords, feed URLs and feeds are never stored on the server. Usernames, passwords and feed URLs are only parsed from the alternate URL to retrieve your RSS feed on the fly from the original source and then are discarded.”
7. Install the CustomRSS Google Gadget.  This ties it all together for us.   Use the feed from Step 5 to securely pull the headlines from your micro blog.  You can click on a link and the gadget will drop down and display the full post, meaning you do not need to leave the Google Apps page unless you want to post.  I customized the gadged by linking the “Pure Adapt Micro Blog” title to our micro blog home page and then modified the aesthetics to match our colors.

Other optional enhancements - I developed this for our needs, but there’s a lot more that can be done.  You can post via email to WordPress.  Since you can send email from a mobile phone, you could post from your phone.  You can also display the RSS feed in your feed reader or Vista desktop RSS widget (I do both).  WordPress plugins like the SMS Text Message plugin could be configured with a few hours of work to send text message updates to all users after every post.  I’m sure there’s more that I haven’t thought of - the possibilities are really endless.

—

Now I feel like we have a communication system for everything.  We still use meetings, phone, email and Skype, but the void left by those is now filled.  A few weeks in we’re all loving it.  Problem solved!

Several months back I built an email follow-up system for Detailed Image that sends an email to our customers two weeks after their purchase.  In addition to checking in with them to see if they received their products in a timely manner, it also asks them to write a product review for each product they ordered.  The email provides direct links to the product review pages for the specific products.

However, the reviews were intentionally buried a bit on the site.  We wanted to have a substantial amount before making them part of the buying process, as so many successful e-commerce sites do these days.  In addition to the reviews, we also needed a way to convey any detailing packages we sell that included the item the customer was looking at.  For example, if you’re buying a wax it’s helpful to know the various packages we offer that include that wax and other supplementary items.  It makes the customer more aware of what we have available in relation to the product they’re looking for, which hopefully leads to them making a better purchasing decision.

So we mimicked the “tab” format that sites like CircuitCity.com and Newegg use so well:

We’re hoping that changes like this improve the buying process for the customer and in turn increase our conversion rate.  I’ll be implementing the same feature - with a few modifications - tomorrow on Tastefully Driven.

Certainly not a major overhaul, but just another example of micro-innovating, constantly improving our sites and our business.   It also helps lay the groundwork for the complete shopping cart overhaul that we’re looking to do at some point in ‘09.

Like anything else, once you get good at programming a large part of your improvement comes in your ability to be more efficient.  Can you get the same results with less code, fewer files, less queries to execute, etc.  If you don’t, any inefficiencies really become magnified as a project scales and your hand gets forced.

When I whipped up Music-Alerts over a weekend last fall I really just wanted something that worked for ME.  I didn’t exactly plan it to scale.  I also wasn’t as good of a programmer as I am now.  When I made a database caching system for feeds, I figured I’d done everything I needed to for it to scale.

However, once I moved it over to our new server we started having issues.  Even after an upgrade to 4GB of RAM the script to generate the feeds was killing our MySQL server in terms of number of connections and number of queries.  While the caching system limited the number of times the web service connected to Amazon, it didn’t minimize the number of database connections.  For most sites this wouldn’t be a big deal, but RSS feeds get checked by feed readers several times per hour.  With 4,000+ feeds - and some subscribed to in multiple feed readers - you can do the math and see that our MySQL server was getting crushed.

So yesterday I spent a few hours building a static caching system that literally creates the feed as a file on the server and only connects to the database once every 3 days just to sync up with Amazon for new releases.  I also trimmed the core code from about 1,000 lines down to just over 100, eliminating a few unnecessary queries each time it does connect to the database. In less than 24 hours our bandwidth consumption, server load, and MySQL usage on the server have all plummeted.

Lesson learned: any RSS service I build in the future will be built with static feeds and minimal database connections.

Last month we struck a deal for Detailed Image to sponsor Autopia.org, definitively the largest online community of auto detailers.  Clearly our target market for DI - a community that can exponentially increase our foothold in the detailing community.  The potential is very large.

Part of the sponsorship agreement included a 120 x 600 banner ad thrown into the rotation on the homepage.   George came up with the idea of having the banner show our automated Daily Special.  Autopia (like most sites) will pull your ad from an image or from Javascript.  So he approached me and asked me if it was possible for me to create said banner that updated daily as our specials updated.  I said yes, but I hadn’t done it before so I’d have to do some research.

In my research I basically found nothing.  No examples of anyone with a similar issue.  I’ve seen the end result before, but couldn’t find a tutorial to help me or even point me in the right direction.  It’s been a few weeks, but I wanted to make sure I came back to this and posted about it because sometime, somewhere, someone will have the exact same problem and hopefully this post will help.  I’m sure there are other (possibly better) ways to do this, but the technique below was what I came up with.  Since it’s gone live we’ve yet to have any issues.

Step 1 - Create the static portion of the banner

I had George and Mike create a PNG graphic of the portion of the banner that would remain unchanged.  You can layer any type of image with PHP, but our product pics are PNGs so I kept uniformity by using only PNGs for this process.

Step 2 - Create a PHP script to overlay Daily Special Image

I take the 500 x 500 image of the Daily Special product, re-size it to 100 x 100 using PHP function imagecreatetruecolor, and then overlay it using the PHP function imagecopymerge.

Step 3 - Create a PHP script to write the HTML and CSS using Javascript

This might be a bit confusing.  I created a PHP script that retrieves the information for the current special.  Once I have that information, I can write the product title and price with Javascript using the document.write function.

Even though this is a PHP page, it needs to be viewed by a browser as a Javascript page so you should to declare the page as a Javascript application using the PHP header function prior to outputting any text:

header(’Content-type: application/javascript’);

Now within the document.write function you can write the HTML/CSS for the banner like you normally would.  I created a div with a size of 120 x 600 and the background image being the image above.  From there I wrote and styled the text using CSS/HTML in the div.  I put a link around the div so the entire thing links back to Detailed Image. The end result is the text overlayed on top of the banner.

Step 4 - URL rewrite Step 3 as a Javascript file

The file above creates the Javascript, but can’t be called remotely as a Javascript file since it has a .php extension.  Thankfully, URL rewriting allows you to “change” a file named autopia_banner_javascript.php to autopia_banner.js.

Step 5 - Set up a Cron Job for the image generation

We’re almost done.  The Javascript file updates the title and the price each time it’s called, but the picture remains the same unless the script from Step 2 is executed.  We have our Daily Special change at midnight EST each night with a cron job.  I set up a cron job to run immediately after, which executes the PHP script from Step 2 and updates the image with the current special.

Step 6 - Include Javascript on a page to display the banner ad

Assuming the location of the javascript is http://www.detailedimage.com/banners/autopia_scripts.js, you can give anyone the following code to include it on their site:

 <script src=”http://www.detailedimage.com/banners/autopia_scripts.js” type=”text/javascript”></script>

Which produces:

And finally, the banner on Autopia:

Wohoo - success!

Earlier this week we launched a feature called the Detailed Image Daily Special. It’s pretty much exactly what it sounds - each day one of our products is on sale for 24 hours. The Daily Special is featured on the homepage with a nifty little countdown clock:

A special message and countdown clock are also on the product page in case someone reaches the product from somewhere other than the home page:

Here’s how we do it: each night at midnight Eastern time our system automatically selects an item and places it on sale. The sale prices is determined from a formula that factors in our profit and cost of goods sold and reduces the price by a set percentage of profit. We did it this way - instead of a flat discount like 25% - because some products we make 200% on and others we make 10% on and we didn’t ever want to be selling an item for less than our cost. We have the option to exclude certain items from the formula. The formula also makes sure we have plenty in stock and that the item hasn’t been on sale recently before selecting it.

Once selected, all other discounts applying to that item are temporarily disabled. An email is then kicked out to anyone on our newsletter list who has opted in for these daily emails (by default current subscribers are opted out since we felt a daily email was too much unless you specifically asked for it). The script obviously also takes the previous days sale item off of sale.

I’ve stayed up the last two nights until after midnight to ensure everything works well and so far it’s worked flawlessly. The best part is that there’s no work involved, it’s 100% automated - my favorite type of feature.

How this feature came about is a really random story, and a testament to how flexible a small business owner can be. About a week ago George and I got into a discussion about updating the content on our home page a bit more frequently to try to get it indexed more often. Other pages on the site get crawled more frequently because they are updated more frequently. One thing led to another, and we remembered this idea George had about a year ago to run one item on special every day. The benefits are obvious (discussed below) so I said I’d program it. I figured it would take me a month or so to get it done around the rest of my work. Turns out I only needed about 10 hours in full to complete it, and here we are with it live a week later.

As I said, the benefits seem obvious but I’ll list them anyway. George wrote a great post yesterday that covered the main ones:

• Customers are more likely to visit the site daily.
• Getting daily emails keeps Detailed Image in your mind EVERY DAY - not just a few times a year when you make large detailing purchases.
• It gives George and Greg extra content to post about daily in the forums we sponsor. Initial feedback has been great - look at what some of the people over on E90Post had to say.
• It creates a gap between our competitors and us. They all run off-the-shelf shopping carts, so this feature that cost me 10 hours of work might cost a competitor thousands of dollars and take months to implement.
• For that day, we’ll get a ton of Google Product Search traffic/sales because we’ll have the lowest price…by far.
• It enables us to cycle through inventory faster.
• Customers initially attracted to the site to buy the Daily Special will be subjected to our upsells. We’ve already seen several orders that came from forum posts about the Daily Special but resulted in large sales.

Like everything else, this is one more micro-innovation that makes us just a little bit better as a company. I expect that at some point in the near future we will roll this out on Tastefully Driven as well. TD has been getting a good amount of sales considering it’s been getting almost no attention lately. The busy season (Spring/Summer) for DI has really locked up all four of us - we want to capitalize on it as best we can. I want to do more for TD, but I realize that come Fall and Winter we’ll flip our attention to TD marketing and spend the majority of our time growing the site. For now, it’s just good to have it up and slowly but surely growing. There’s no doubt in my mind that the best business move is to capitalize as much as possible on DI while we can.

Since the launch of Tastefully Driven I’ve been intending to do a post similar to the DI Features and Lessons Learned. But since this project had less “unknowns” there weren’t a lot of “lessons learned” from the programming side. We knew what we needed to do, and it was more about execution than figuring out a way to get stuff to work.

Nonetheless, there’s still a lot of cool stuff on TD that isn’t completely obvious if you just scan the site for a few minutes. So below are my Top 10 favorite things about the site:

10. One Account
When you have a forum on an e-commerce site, I think it’s utterly important to tie the two accounts together. Instead of just throwing up a copy of vBulletin and making the colors match, we took a bare bones copy of bbPress and hacked it apart until we were able to mesh it seamlessly with the shopping cart. Right now the only benefits of this are that you log in once (at the top of any page…another cool feature) and that you have the same username/password across the board. In the future - assuming the forum becomes somewhat popular - this opens itself up to all sorts of interesting social-networking-type opportunities: for example, imagine getting product suggestions (via PM, email, or displayed inline on the site) based upon your previous purchases and the threads you participate on the forum. In 2-3 years this could be how we make that jump from large e-commerce site to “social shopping” platform. It’s a ways away, but we laid the foundation now.

9. Integrated Affiliate Program
A lot of affiliate programs make it ridiculously difficult to sign up and create links. Using a 3rd party affiliate software is something we didn’t want to do for Detailed Image and we brought the same system over to TD. Our payout rates are posted for everyone to see, and signing up is really easy: in your My Account page there is a message enticing people to sign up:

If you click ‘Apply Now’ you only have to choose a payment type, click ‘Apply’ and you’re good to go. We also make it super-simple to create links. In addition to a tutorial page, we now display an affiliate link on every single product page for that specific product when you’re logged in:

8. Forum Product Recommendations
When you are viewing a forum topic we display a banner ad of up to five related products at the top of the page. So if you’re in a discussion about caffeine it will “recommend” the caffeine capsules for sale in our nutritional supplements section. Again, this has large potential to be highly customized in the future based upon more than just the forum topic.

7. Personalized RSS Feeds
This is one of the few features that came with bbPress that we kept in tact. Every user can mark their favorite forum threads and then subscribe to a custom RSS feed to track the progress of the conversations they’re interested in.

6. Blog-Forum Sync
One of the other things I saw as absolutely necessary was merging the blog comments with the forum. Each time we post in WordPress, a corresponding thread is opened in the forum. If you click to comment on the post, you are redirected to the forum. Blog posts also pull the conversation from the forum and display under the post just like normal comments.

5. Upsells
Inline upsells offering a 5% discount was one of the most fruitful moves we made with Detailed Image. Average order value went through the roof. With TD we changed the page structure around and moved the upsells up “above the fold”. This may or may not be better - we’ll see.

4. Image Upload System
One of the most time consuming aspects of Detailed Image was uploading pictures. Each picture needed to be re-sized several times, watermarked, and then linked to in the database. For TD, I built an image upload system to automate all of this. After we’ve entered the product info in the database, we can log in to our admin section and upload a 500 x 500 png file and the script automatically re-sizes it, saves it, watermarks the images, and creates the appropriate database relationship. Big, big time saver.

3. Shipping System
Sure, this is basically the same as DI, but it’s the backbone of our company. This system is the single most efficient process we’ve put into place. If we didn’t have it we would have a full time employee processing and shipping orders right now. Each morning we click “Process Orders” in our admin section: the PDF receipts pop up to print and save, along with a text file to import to FedEx Ship Manager, which prints the shipping labels and gives us a text file back with tracking numbers, which we upload to auto-email each customer their tracking info. It’s a 2 minute process whether there are 5 orders or 25 orders (or 250 orders down the road).

2. Design
The design of the logo and the site was all Mike. I think he did an A+ job aesthetically conveying exactly the image that we want our customers to see….especially by differentiating each store with it’s own unique color scheme. The Games store, for example, has an orange color scheme but you still know that you are part of TD:

1. Commerce with Conscience
The icing on the cake for me: we’re donating 5% of our pre-tax profit from the site to local charities with our Commerce with Conscience program. Sure, 5% isn’t much now, but it will be as we grow. We’re choosing new charities quarterly, and the first charity - The Regional Food Bank of Northeastern NY - has been very supportive (I got an email back from the Executive Director, which is pretty cool). Along with participating in events like the Climbing UAlbany Event, we hope this program is how we funnel some of the money we pull in online from all over the country/world back to our community. I anticipate that as we grow we will spend more time personally working with each of our charities so that we give back more than our money - our time and expertise can do equal amounts of good. My favorite part about this program is that it ensures that no matter how big we grow we are giving a corresponding amount back to the community. Target does the exact same program and you see the immense social impact they are able to have because of it. If we can even have a fraction of the impact locally that they do nationally, it will be a huge success.

We’re also all rocking Commerce with Conscience wrist bands:

The bands are included with any order over $100 for free, or can be ordered for $4.99 on the site (with all of the profit from the wrist band being donated).

———

What’s next? I’m a firm believer in letting things settle for a bit before diving back into more development. Aside from a necessary focus on marketing, I’ve learned (the hard way) that you need to provide ample time for data/feedback to accrue before jumping to any conclusions about what you do and don’t need. By the end of 2009 I hope to have expanded the forum functionality with the aforementioned social-shopping stuff and to also integrate some AJAX into the cart in places it can really help (coupon codes and add/update cart come to mind), but other than that changes will be dictated by our users and the data.

All in all, we couldn’t be happier with the site we put out. We’re a small team and we did it on an extremely tight time schedule. I’m ridiculously excited to see where this cart takes us over the coming years.

I don’t much mention SportsLizard or the Price Guide anymore, but it is still alive and kicking.  I’ve got it down to a science where I probably only spend less than 5 hours a week to maintain the site.  The Price Guide is at about 30,000 users but - because of our inline help and FAQ - requires very little customer service.  Premium accounts are only a small fraction of that, but we still make over $1k/month on them for doing essentially nothing.

However, this morning my biggest SL nightmare became reality - the Price Guide software mysteriously stopped working.  A bunch of cancellations followed, as did an email from a loyal user who has priced 11,238 items using our Price Guide (yup - he’s run 11,238 searches!).

This was at about 8:30 AM while I was sitting in a Starbucks.  I had planned to do some relaxing work and then meet my cousin for lunch…but all of a sudden I was in panic mode.  The application relies on a lot of things to be working right, most notably our syncing with Google Base, and I had no clue where to start.

I thought Google might have disabled our API keys…nope.

I thought someone might have hacked the SL database and screwed with the integration of SL and Base results….nope.

I thought that eBay, NAXCOM, and Beckett could have all stopped listing items on Google Base (essentially killing the service)….nope.

Then I tried a pre-launch beta version that I made that spits out results as a text file without any graphs or a fancy UI.  Amazingly that worked.  So I went line-by-line through my code and compared the beta version  to the live version.  After about an hour I figured out that a filter I had put in to weed out items returned with a $0 price was no longer supported (correctly at least) by Google Base and was throwing the results off.  The same search would go from 30 legit results to 500 with the filter removed.  Very rarely are items listed at $0 anyway - I just put that in there as a redundancy - so I removed it and everything began to work fine again.

The last time I successfully used the Price Guide was a week ago, so it looks like it was in bad shape anywhere from 36 hours to 1 week.

Now the hard part - damage control:

• At 8:30 I had immediately placed a notification in red on the Price Guide page saying something to the effect of “We’re experiencing technical difficulties, we’re working to resolve them ASAP, we apologize for the inconvenience”.   I took that down once I was certain I had solved the problem.
• I emailed that uber-loyal user back who initially alerted me of the error. I refunded his most recent payment and offered him a free premium account for life.
• I emailed everyone who had canceled in the past week apologizing for the inaccurate results and offering them the same free premium account for life.
• I wrote a post on the SL blog (which is auto-emailed to newsletter subscribers as well) notifying everyone that the issue had been resolved and extending the same free premium account for life offer to anyone who I did not email that also experienced troubles with the Price Guide during the past week.

Whew.  That was a stressful morning.

As much as it sucked, it allowed me to re-familiarize myself with the app I built almost a year ago.  More importantly, it created an opportunity for me to show my customers how much I care about them and their experience with the Price Guide.   It also gave me a chance to show that we address our issues rapidly - within hours of being notified of them…even on a Saturday - and with a candid, honest, and genuinely remorseful attitude.

No one wants to have technical snafu’s like this, but when presented with one you’ve got to make the best of a bad situation.

I’m going to take a step back from our pre-launch marketing for Tastefully Driven to go over our overall launch plan - from conception to where we are now to what we have left to do. I’m not saying that there aren’t different or even better ways to deploy a site, just that this process is how we do things, in large part based upon prior failures, successes, and other professional experiences (I’d be lying if I said my engineering background didn’t play a large role in the way I structure a project).

None the less, I’ve never in my life missed a due date on a project and a large part of that is my meticulous planning so hopefully this post will help other young entrepreneurs better formulate their business plan.

Conceptualization

You have that “ah ha” moment where your entire perspective on the world changes and you think to yourself  “I’ve got to do that“. This is the start of what I call the conceptualization stage. For us, after the Detailed Image shopping cart far exceeded our expectations, we naturally asked ourselves how we could repeat the DI model in another industry. That led to us considering several similar high-end niches, and eventually the light bulb moment where we could combine those stores and a community into one large site - hence Tastefully Driven.

When I’m at this stage with a project, I’m so excited that I put a self-imposed waiting period on myself before acting (similar to my 24 hour rule). During this stage you’re likely to be so certain that you have just come up with the next big thing that you’ll ignore reality and down play very real road blocks. There’s no set time period, but I’d say wait at least a week before taking any action beyond registering a domain name.

In the case of Tastefully Driven, we conceived of the idea sometime around Thanksgiving of ‘07. For the next month we discussed the pros and cons - the features we’d want and those we wouldn’t, how we would market it, how it would impact the rest of the company, and how much of our resources could be devoted to it.

Aside from preventing you from doing anything stupid, it allows you (and your team, if you have one) to refine your vision. By the end of this period for us, everyone usually shares the same vision and knows what’s going through everyone else’s head. When you finally do start the project, you start it on the same page with the same vision for success.

Making it an Official Project

By late December we had decided Tastefully Driven would be our future. At that point I consider the project an official project. During this phase we started to get more serious: would we keep client work (ultimately, no)? how would this impact Detailed Image (we would finish all DI development work for 2008 before starting TD)? when could we realistically launch with several product lines (initially, we said 8/1/2008 at the earliest).

This is where I really shine. We have a MONSTER project and we need to figure out how to start tackling it. This is also where I think a lot of people get paralysis by simply being overwhelmed with what to do next. As Theodore Roosevelt once said: “In a moment of decision the best thing you can do is the right thing. The worst thing you can do is nothing.” In this case, the right thing to do is come up with a plan.

Up to this point, we had literally written nothing down and neither should you. Don’t get caught up in the minutia when you’re conceptualizing. However, once it’s an official project there has to be extreme attention to every single detail.

We tend to convene around our company wiki, so I like to write my project plans on the wiki. Since we had agreed to finish Detailed Image development before touching TD, I focused on that first. There were around 10 additions to the cart that needed to be completed (mostly stuff for me to do). I gave each an approximate completion time and I figured it would take until the end of February or early March to complete. Somehow I caught fire and wrapped it up on 1/12, which gave us an early indication that our 8/1 launch date for TD might have been too much of a time cushion.

Once complete with that I started an in depth plan for Tastefully Driven. The site will launch with 5 or 6 e-commerce stores, a community, a blog, and full integration of accounts between the three - by far the largest project we have tackled, and therefore the most daunting to plan. I started by breaking it up in to several key categories:

• Design (mostly Mike)
• Development, which essentially involved improving and scaling the DI cart (mostly me)
• Quality testing, which could fall under Development, but I like a whole section of tests to run prior to launch
• Product selection (mostly George)
• Content creation, including writing product descriptions
• Marketing ideas

Each category had a simple bulleted list, and each task that needed to be done to launch got an approximate completion time. The latter stuff - like marketing ideas - was more of a brain dump than anything else. Even though we create a marketing plan later on, it’s important that we have a place on the wiki to jot down an idea as we come across it in the development of the site.

Setting a Launch Date

Some people like to use Microsoft Project (or similar project manager tool) to plan out due dates and choose a launch date. I was forced into using these tools in college, and to be honest I just see them as complicating the matter. I like the freeness of one large blank wiki page. I am smart enough to know that keyword research needs to be done before launching a pay-per-click campaign, so I won’t assign a due date to the PPC campaign that doesn’t allot for that. With the entire project in front of me it became pretty obvious that we could finish it by 3/1 (a far cry from 8/1). We figured with the warehouse move and a little cushion time, that 4/1 would be perfect. Any later in the year is prime Detailed Image season so if we didn’t do April we’d probably have to wait until Fall…or launch with limited contribution from George and Greg.

As I touched on a bit in previous posts, the one key thing I grossly miscalculated was how long it takes to contact vendors. I figured a month would be sufficient time to contact a vendor, get samples, place our first order, and receive it. More realistically, that stuff takes several months and I’d like at least a 3 month cushion for that alone next time. Our final order just shipped, so miraculously we will have all of our products in the warehouse for weighing and photoing by 3/14, but we cut it waaaay too close in my book.

Developing the Site

The development portion is different for everyone. Some people use open source software like WordPress or osCommerce with very little customization and this portion isn’t much more than design work to get the aesthetics right. Others hire an outside developer….which I’ve never really done so I have no clue how to integrate that into a project plan. We develop everything ourselves, so we were able to relatively accurately estimate our ~2 months of development work.

*side note - if you or your developer don’t develop with SEO in mind, this is the time to start building and structuring things properly. Do your homework - it will pay off.

When I do development work I do it with the understanding that we’re spending a few weeks solely on quality control testing at the end of the project. That means that while I’m developing I test every scenario and interaction I can think of, and once it works I move on.  I usually miss some stuff, but that’s OK. In most cases there will be other interactions created later on, some of which we won’t appropriately test - which is why having a QC testing phase is so important. I also encouraged Mike to think the same way with his design. Essentially - lay it all out and get it working most of the way and fix the nitty gritty shit at the end.

I always map out the entire site - every feature and function I can think of - before touching anything. Once that’s done, I create the database that should encapsulate every single possible scenario. This is pretty obvious: you need to be able to enter test data to see if what you’re trying is working.

All of this resulted in a more detailed list of features to develop, how long they’re going to take, and what order to do them in. By far the most challenging part of Tastefully Driven was to get our login and user information to work seamlessly between our forum (built upon bbPress), our blog (WordPress), and our custom built cart. Every project I’ve ever been a part of has those “if we can just get this to work, we’ll be fine” features and this was the one thing we were really uncertain of the difficulty going in. It’s important to identify these types of issues at the start and try to tackle them as soon as possible so you know where you stand. These are the things that will throw off a time line and screw a launch date.

Announcing the Launch Date

For the reason in the last sentence, we have an unwritten policy of not announcing a launch date until the development work is nearing completion. While internally we set 4.1.08 as the date, we always knew it could be delayed if need be. Once I announced the launch on my blog, I considered it set in stone and - short of an extreme emergency - will make sure it happens.

Every company has different pressures and a lot of times those pressures dictate premature launch dates, but if you can help it I encourage you to set a date and stick to it. A launch date really forces you to buckle down and focus on the task at hand. It forces the BS stuff out of your project plan and dictates that you work on only what is necessary. We’re in this phase now, and I’ve been knocking things off of our wiki list like crazy. Some get moved to “post launch” and others get canned because they just don’t matter.

I normally work a lot more hours prior to a launch. The past few days George and I have been doing a double shift (8 AM to 8 PM type of stuff) to ensure that we get everything done on time.

Creating a Marketing Plan

Up until this morning we just had our marketing list on the wiki. We created the splash page, the pre-launch blog, and the teaser business cards, but the plan wasn’t really formulated. Today I finally created our marketing plan. Some people like to do this sooner than now (a month before launch), but I encourage you to wait to create a marketing plan because so much changes in development that much of an earlier marketing plan would be rendered useless.

I’m not going to rehash all of my favorite web marketing tactics - my free e-book does that - but I will say that for an e-commerce site we’ve pretty much got a formula down pat that we are sticking to. The majority of our marketing will consist of:

• Content creation. Articles, forum posts, podcasts, and videos where we do product comparison, tests, and case studies. Since our site is perfectly SEO friendly and we will produce quality content, over time this will suck in a ton of targeted traffic. It will also become viral and hopefully spread through social bookmarking and social networking sites (we have a “share this” button on every product page, blog post, and forum post).
• Pay per click marketing. PPC is such a simple formula if executed properly: pay $x per click, y% of clicks turn in to purchases. As long as the number of clicks/sale is greater than your margin, you win. Split testing and refining ads can push your cost per click down and conversion rate up.
• Google product search. So many sellers don’t take advantage of this. It’s free, and in about 2 hours I automated the process so that we automatically create and submit an updated product feed daily to Google via FTP. DI gets a lot of sales this way.
• Email and RSS marketing. This is really just maximizing the sales we can get out of our existing members. I’d also include great customer service in this category - every customer service email is an opportunity to positively influence someone who could become an evangelist of your site. When you’re starting with zero members, email marketing can take a while to have an influence. We see it now with DI though: every newsletter results in a wave of sales. This is one of the reasons why the pre-launch splash page is important: the faster we can build an email list, the better.

There’s other stuff too, but these are what will drive sales. Obviously PPC and Google product search will help immediately, while the other two will take time to develop. We’ve launched so many sites that we understand that you don’t truly see the impact of great content for months and even years. With this project, we know that what we’re doing works and we’ll be as patient as we need to be to make it work correctly.

Quality Testing

Maybe it’s because I spent my engineering days as a QC engineer, but quality testing is a big deal to me.  Test every single page and every single possible function of your site.  Do it in every browser, every operating system, and under every condition you can think of.  Test your emails in every email program available.  Do REAL transactions and make sure they work.  Recruit a handful of BETA testers (i.e. friends and family) to try everything out.

You’ll never catch 100% of the errors, but the difference between 80% and 97% is huge.  I allot a minimum of one week for QC testing and it’s usually the week prior to launch.  That means that everything else should be done at least a week before launch day.

Launching

I always create a launch day checklist.  While you should pause to celebrate (for like five seconds), once you pull the trigger there’s a lot to do:  announce it on your blog (if you have one), submit your product feed to Google, submit a sitemap to Google/Yahoo/MSN,  activate your PPC campaign, email friends and family, etc.

You’ll likely start discovering some of those errors you missed in the QC testing phase as real people do stupid things to inadvertently challenge your software like it never was before.   The better job you did in QC, the more you can focus on your first order coming through and the less you have to worry about your first users getting pissed off and leaving.  When it comes to Tastefully Driven the platform is built upon Detailed Image, which we know is stable, so I’m more worried about minor integration issues than I am about all-out systems failure (which was definitely a concern of mine when we went live with DI….even if I never let my partners see it).

Bottom line:  it’s a fun day when you launch, but in reality it’s just the beginning.  Take a day to catch up on sleep and then get to the “real work” - getting people to actually pay you money.

Ongoing Development

I have a rule: other than fixing errors, don’t make any major development changes or additions for at least a month…three to be safe.  Why?  Because on the second day you’ll get an email from Aunt Betty telling you that she thinks the site would be better if it had feature xyz and you’ll think “if she thinks that, other people must be too” and then you’ll begin to hack up your code and try to rush xyz to market.  Not only could this make your site worse, it’s also a poor use of your time.  You’ll get emails like this all the time, and if you concede to all of them you won’t make much money and your site will suck.

If you have confidence in your project (and you should if you got this far), there’s a good chance that you launched with a pretty solid site.  That’s good enough for now.  Take in your customer feedback, study your analytics, and focus on sales right now:  in the grand scheme of things you’ll look back at the launch version of your site as a piece of shit but you need to let those things play out so that you’ll know what you should and shouldn’t do to improve upon it.

For Detailed Image, we waited from September to January before I started on the laundry list of features for 2008.  The result, however, was a million times better than if I kept programming in September.  Some features were deemed unimportant and scratched from the list, some were re-affirmed by our data….justifying our time expenditure, and some became simpler to program because of everyones more intricate knowledge of the cart.

One thing I think most developers look past:  just because you made the software, doesn’t mean you know it.  Often times, customers will use things vastly differently than you intended.  By letting those things play out naturally you save yourself a ton of headaches and ensure that the changes you do make are worthwhile.

Conclusion

Phew.  Can you say longest post ever?  I think I’ll get back to work now….after all, I’ve got a lot to get done to launch this site

When it comes to matters of web development and SEO, I’d like to think that more often than not I make the right decisions. When I am wrong, I’d also like to think I learn from the experience, minimize the damage, and apply it to the future.

Of course, that’s assuming that being wrong is a bad thing.

Last summer, when we first committed to developing the Detailed Image shopping cart ourselves, we had an array of potential features that we had to pear down before launching. If we didn’t, we’d have spent six months doing what we needed to take three. The majority of the most important features made the cut, and it was easy to wait upon the rest…except for one that really sparked some discussion: packages.

My rationale was that there was no need to have pre-made packages for people if we had our dynamic upsell system. So we launched in September without packages, and eventually added them in January. I spent less than a day programming the feature (the inventory management on the back end was what made it somewhat challenging), but for the most part I did it because George and Greg wanted it done…not because I really thought it would make a difference.

I was wrong. REALLY wrong. There isn’t a day that goes by where at least two packages don’t sell. That’s a big deal - take a look at the packages available: most are over $200, and some are close to $1k.

Kudos to my partners for pushing the feature. Hey, I guess if I’ve got to be wrong, it’s good to be wrong in a way that puts more money in our pockets.

In my post earlier this morning I mentioned that this was probably the most productive week of my life. It’s partly because I’ve become an early riser, but mostly because we’ve had such success with the Detailed Image shopping cart that it’s eliminated a lot of the questions we had about our company direction. The back-end automation, SEO friendliness, and built-in upsell system have more than doubled sales and we’ve recognized that continued efforts in e-commerce are probably our best chance at using our skills to thrive as a company.

Before doing much with the cart though, we needed to clean it up a lot and add several common features that it previously lacked. Since it’s 100% custom programmed, the end result is a seamless e-commerce experience for both us and our customers that - in our opinion - isn’t rivaled by any shopping cart.

For example, with our soon-to-launch affiliate program you can apply simply by clicking a button in your ‘My Account’ section. There’s not a second registration like most sites require, and you can manage everything DI related by visiting that single ‘My Account’ page.

Anyway, in addition to Mike’s redesign and his blog redesign, I was able to complete the programming (with the aid and advice of our entire team of course) for the following features in this past week:

• Improved upsell system javascript to be more efficient and more visually appealing (example product page)
• Created the aforementioned affiliate program
• Integrated wholesale pricing tiers
• Created phone order system
• Added the ability for us to offer packages of items (and still have our inventory system updated correctly)
• Added gift certificates
• Product review system for every one of our products
• Fixed a pesky SSL problem that was causing a warning in IE7

Far and away my most accomplished week ever. Hell, if we can do all that in a week, what can we do in a few more months?