Holla! I just flipped the switch on Every Single Shot 1.0! If it’s on Twitter it must be a fact:

This has been the culmination of a lot of work! Oh sure, it’s still a little rough around the edges for now, but isn’t that part of the charm? I’ve got big, big plans for the future of ESS, and I’m super excited that I’ve gotten this far. I don’t know how else to say it: it’s been a lot of work. Worth it? Definitely!

Technical stuff

What’s ESS built on? What technologies does it use? What methodologies did I use to build it?

The tech

Grails

First and foremost, I used Grails for pretty much everything. I was a Spring MVC veteran for a long time, and let me tell you, I knew my way around that stack inside and out. There was nothing I couldn’t accomplish with it, albeit with a bit of elbow grease usually. I decided to move to Grails for this application b/c it was so similar to Spring MVC in so many ways (it’s built on top of Spring MVC for one), but different where it really counted (i.e. it made the simple stuff really simple, and the tough stuff, well, less tough). I have no regrets and I don’t see myself ever going back.

Grails report card: A++

Amazon EC2 and S3

Can I get another holla! I love love love working on EC2 and S3. Let me put it this way: have you ever used a technology or toolset that just works? I mean, one that always does exactly what it’s supposed to without fail? Well, I hadn’t either until I used EC2 and S3. They are so damn reliable, so rock solid, so well documented and supported. Basically, they’re awesome. I know there are other services out there with more bells and whistles, and I’ll be honest, I had to build a lot of infrastructure in EC2 myself that I wish I hadn’t needed to, but AWS’s stability and predictability more than make up for it. For 10 cents an hour I get a dedicated (virtual) server with lots of RAM, a huge disk, and some crazy fast connectivity. Scripting set up and configuration of servers couldn’t be much easier than with good ol’ runurl. Management of servers is super easy with the command line tools. Rawk on.

Amazon AWS report card: A++

Other tech

Here are some of the other technologies that various parts of Every Single Shot use in no particular order: apt (this is one reason that Linux rocks), Apache 2, apticron, awstools, ec2-consistent-snapshot (Eric Hammond is the man when it comes to EC2 and Ubuntu), Groovy, ImageMagick, Java, Jquery, MySQL, postfix, Subversion (I know, I know…), and Tomcat. All in all you can see there’s not a lot of glamour tools in there, just a bunch of stuff that works.

Methodologies

Gosh, I wish I could be more specific, but I pretty much just had a big list of issues, loosely divided into versions, organized in Jira (I got my Jira license for $10). That’s it. No agile, no scrum, no scragile or whatever. Just cranked through issues.

Here’s something interesting: I used to do a lot of TDD (test driven development). I’ve abandoned that lately in favor of writing tests…never. Actually, since I’ve started with Grails I’ve written a lot fewer tests that I used to with Spring MVC. Part of this is due to the fact that there’s a lot less that needs testing in Grails, and part of it is due to the fact that tests in Grails can be a little tough to write (there’s a lot of meta programming magic happening, and I miss Java autocomplete), and a lot of the tests run kinda slow (the entire container has to start up a lot of the time). Enough about testing though (let the flame wars begin).

I could go on…

Believe me, I have lots more to talk about, lots more I want to say about the 1.0 release of Every Single Shot. But that’ll have to wait. I need to get back to work! 2.0 is calling me…

I didn’t mean to learn anything about customer support – I was just researching the competition.

More precisely, I was researching some indirect competitors for Every Single Shot and I found myself at SmugMug. Although I was looking to learn about the specific features of SmugMug, what I found myself really impressed with was their customer support. I mean, it was good enough that it actually jumped out at me. How often do you find a site and your first thought is, "Wow, they must have great customer support!"? Almost never.

Customer support tips

SmugMug’s approach to support made an impression on me. Here are the observations that I took away from my ‘mugging. I’ll be looking for ways to integrate these into Every Single Shot in the future.

• Be friendly – This seems like commonsense, but for some inexplicable reason businesses feel a need to sound "professional" when talking with customers. Sure, make your website and literature professional. But when you’re talking one on one with customers, be friendly. People don’t want to talk to companies, they want to talk to people. Use down to earth, conversational English. How about this from the SmugMug welcome email: "Need a real person? We’re family-run and love to hear your gushes, gripes and questions so we know what to work on next." That tone sets me at ease and lets me know that these people are here to help. Little touches like these can make all the difference. SmugMug uses this tone throughout their site to great effect.
• Humanize your support team – I really like this touch. I found pictures of the SmugMug team in a couple of different places: the 5 minute getting started video and, my favorite, the super hero pictures shown when sending in a support request.
• Let customers know you enjoy helping them (and actually mean it) – This has to do with the general attitude taken toward customers and support. If you respect and value your customers, it will show. If not, customers will soon become ex-customers. I felt the SmugMug team was genuinely concerned about my experience on their site, and because of this I subconsciously started thinking "I like these guys".
• Let customers feel like part of a group – Watch the 5 minute getting started video. This is how intro videos should be done. It’s narrated by one of SmugMug’s owners in a very casual tone and it has photos of the entire SmugMug team. It made me feel like I knew these people a little, like I was part of their group.
• Set appropriate expectations – This one’s great too, and it’s easily overlooked. When you open a support request, SmugMug lets you know what time it is in "SmugMug land". This helps set appropriate expectations for when you’ll receive a response. "It’s 4:27am SmugMug time and our heros are snoozing…you’ll hear from them by early morning." They’re asleep – fair enough, I can live with that. They’re people, after all (see above points).
• Automate – Here’s another neat touch when sending in a support request: the user’s browser and OS are automatically detected and added to their email. My support query to them automatically had the following added: "Hey Support Heroes, I’m using Chrome on Mac OS." Auto-generating details like this (instead of asking the users to tell them to you, which is way less efficient) can eliminate an entire cycle of the support process, which results in quicker support and happier users. No more asking users what web browser they’re using only to have them reply "Dell" or "purple".
• Provide help documents – Another seemingly obvious one, but a lot of small companies don’t provide any sort of help documents for their product. I see this a lot in small webapps released by one or two people (usually programmers, because we all know programmers hate writing documentation – I’m guilty of this – SendAlong suffered from it). This is a fundamental first step that a lot of companies drop the ball on. SmugMug has a lot of nice help docs. They even go so far as to explain how to write some simple CSS rules.
• Make help easy to access – If you spend a lot of time making your help system awesome, make sure you do it justice by making it easy to find. Link to it on every page, and for added bonus points, make the links smart – don’t just dump them at the help homepage, show them topics related to the page they came from.
• Include a FAQ in your help – You should have the top 5 to 10 questions asked right there at the top of your help homepage. 80% of your users are going to need one of those questions answered, so why not make it easy on them? Bonus: now that you’ve got a FAQ, go through it and see if you can make any of the answers to the questions obsolete by making your product easier to use.
• Let them know if you’re special – It doesn’t hurt to let your users know that you’re better than average. In my welcome email I found out that "80% of customers who have purchased SmugMug accounts in the last 5 years are with us today. We hope you’ll join the family." I immediately thought "Hmmmmm…they must be really good at what they do." And I’m sure that’s exactly what they wanted me to think.

All of this, and I never actually contacted their support team! Based on what I found on SmugMug’s site, I can only assume that their team would live up to my expectations. And that, in a nutshell, is great customer support.

Being nice is good (duh!)

With SendAlong, I violated all of the ideas above with one exception: I was friendly when talking with customers. And I could tell that customers appreciated it. I slowly started to see a pattern in how customers communicated with me.

• Their first email would usually be neutral or somewhat passive aggresive/demanding. "Why doesn’t it have feature X? I need this now."
• I always tried to be as friendly and personable as possible in my replies. "Hey, thanks for using SendAlong! That’s a great question, and…"
• After extended the "there’s a human on the other end and he’s nice" olive branch, the next customer reply was usually pretty friendly. "Ahh, that makes sense. Thanks for letting me know, Jon!"

Come to think of it, maybe those first customer emails would have been a lot friendlier if SendAlong had done a better job in earning users trust before they emailed by taking note of some of the tips above…

What tips can you give for providing great customer service? I’d love to add some of your ideas to the list above and into Every Single Shot as well.

Someone just posted a question over on the Business of Software forum asking for recommendations on books and blogs related to sales. Since I’ve been doing a lot of reading on marketing (I know, marketing isn’t sales, but they go hand in hand), I figured I’d post my reading list so that others might benefit.

Here are the marketing books I’ve read recently:

• Inbound Marketing
• Duct Tape Marketing
• The 22 Immutable Laws of Branding (I recently wrote a summary of this book)

Here are a few books that I haven’t read yet but look good:

• The 22 Immutable Laws of Marketing
• The New Rules of Marketing and PR
• Word of Mouth Marketing
• Crossing the Chasm

Happy reading!

And no, the above are not affiliate links.

What about you? Read any good books (marketing/sales related or otherwise) lately? Leave a quick comment below and share them with everybody.

UPDATE Looking for more marketing books? Here’s a list of good ones that I’ve read recently (or am planning to read).

I just read The 22 Immutable Laws of Branding and was happy that I set aside a couple of hours to do so.

I’m currently working on a new product and a lot of the material was relevant to me. I’ve read a few books on marketing, but nothing specifically on branding. This book has whet my appetite for more.

Here are my notes:

• Generate publicity, not advertising. Best way to get publicity? Announce a new category, not a new product.
• Claim your product is a "leader", not "better". All products claim they are better, but you can’t argue with leader.
• Own a word. Like "luxury".
• Perception of quality is built by a narrowly focused brand, a high price, and a better name.
• Promote the category, not the brand, and be first in the category so that your brand is associated with the category.
• Expand a brand, reduce its power. Contract a brand, increase its power.
• Welcome other brands in order to build the category.
• Generic brand name = bad
• Select a brand color opposite of that of your main competitor’s.
• Consistency is key. Never change your brand, ever.
• What’s a brand? A proper noun that can be used in place of a word.

Update: See the bottom of the post for some updates.

I was delighted to find this timely article by 37Signals on credit card processing. I’ve been facing the question of how to process payments online and it’s very helpful to hear reports from successful businesses in the trenches.

It’s noted in their approach that they are using Authorize.net as their gateway and Chase Bank for their merchant account. This bodes well, as I was already considering the same combination of gateway/merchant account – Authorize.net is the leading payment processor and Chase Bank sounds like a name I can trust:).

As for recurring payment processing, it also sounds like they are not using the recurring payments functionality of Authorize.net and instead just running a nightly job to take care of it. I’ve been looking at the recurring payments functionality provided by Authorize.net, but I’ve been slightly turned off by it because it looks like it would be tough to implement recurring payments using their API because of all the little business process exceptions (prorating months, etc.) that need to be handled. This gives me confidence that I can ditch the recurring payments API and just run a nightly job to take care of this aspect of the billing.

As for now, I recently had slated the implementation of SendAlong’s billing processing as part of my next two week iteration. However, I’ve been doing some thinking about this over vacation (the lines at Disney World give you a lot of time to think) and I’ve almost decided that I’m going to forgo automatic payment processing for the time being in the hopes of releasing version 1.0 earlier. I can handle the first few accounts on a manual basis (as long as Authorize.net or my merchant account provides an adequate web interface to do so) – this will minimize the wait for the 1.0 release and may give me more insight into what SendAlong’s billing system needs to do.

A couple other things to note:

• Credit card details are usually NOT stored by you, but instead held by the payment processor’s system (Authorize.net) – this is much safer and easier for you. The payment processor returns a unique token that can be used to identify that customer at a later date for more charging/crediting. You should probably store the credit card expiration date in your system if you’d like to proactively contact your customers to let them know their card will be expiring soon.
• Make sure to check the comments of the 37Signals post – there’s sure to be some good information in there too.

Update: After reading through the comments on the 37Signals post, I found that 37Signals actually stores all of the credit card information that they collect. This involves a fair amount of overhead, and from other readers’ comments, I can’t say I would recommend it for the average microISV. It also sounded like a few people are having good success with TrustCommerce’s Citadel.

It’s time for an update on the perceived marketing effectiveness of SendAlong’s site. Having just released a newly updated beta, let’s hope it does much better.

Alright, the results are in:

Compared to late October’s results, it looks like the grade has improved (although not as much as I would have liked), however there’s still a lot of work left to do.

Want to grade your site? I used Web Site Grader.

If you’re going to try to process credit card payments from your web site, you’ve got a lot of learning to do. On the one hand, there are the third party providers like PayPal, and there are the merchant account providers like Authorize.net. If you have no idea what I’m talking about, have a read of the following articles.

Solve the Payment Processing Problem – I found this particularly enlightening. Good description of the differences between a merchant account (like Authorize.net) and a third-party processor (like PayPal).

Put your Money where your Mouse Is: 6 Payment Gateways Reviewed – This one was great too – a good review of several payment gateways.

I’ve looked further into Authorize.net. On the plus side, you can do everything through an API, and no “Pay now with PayPal” button is required on your site. It also offers a nice looking package for recurring payments, and even handles trial periods to boot.

As for prices when using a merchant account, they’re not as clear cut as, say, PayPal is. There will be some calling around involved and prices are definitely negotiable.

I’m sure there’s going to be a lot of leg work involved as I go through the research process, so subscirbe to the RSS feed to get the updates I post to the blog.

I just stumbled upon Startupping.com, which looks to be a good resource for start up information. They have what appear to be some decent looking forums, a nice wiki, and a large list of start up blogs (in OPML format – can be imported into most RSS feed readers). Not to mention I think they have a nifty logo:).

Starting a business is difficult. Even more so if it’s done in isolation.

But blogs can help. Really.

Although blogs aren’t a substitute for face to face contact with others, they do serve many purposes: they can be inspiring, insightful, educational, and a great way to get in touch with like minded others.

With this is in mind, below is an (incomplete) list of some micro-ISV and startup blogs that I find particularly useful with helping me along on my micro-ISV/startup journey. My hope is that they prove helpful to you too. And believe it or not, some of these guys can even be funny from time to time (but don’t hold your breath!!).

• Ian Landsman – UserScape/HelpSpot
• MicroISV on a Shoestring
• Successful Software
• Bill Boebel
• Don MacAskill – SmugMug
• Ryan Allis – iContact
• Andrey Butov – Antair