Why does this happen? Well, when many people are involved in a specific ticket, there will be bunch of assigning, back and forth communication, until the ticket is approved, and resolved in the end. I am referring here to tickets that are related to new features or complex bugs. Dealing with simple bugs is easy and this would probably never happen.

How to deal with ticket readability

So, how to deal with tickets and avoid “noise?” You don’t want developers to miss out on features or bugs in the ticket and you also want testers to see what they need to review so it can be properly checked and approved.

I prepared a list of things we do to improve ticket readability and reduce the risk of missing valuable information.

Separate discussion from tickets as much as possible

We are lazy in nature, so from time to time, we tend to discuss things in tickets more than needed. Try to avoid this. Leave out all unnecessary information from the ticket and leave only clean concise data which is required for people working on the ticket. For additional details link to an external discussion, which is posted separately.

For example, say you are not sure how you want to implement a feature. The feature was discussed and final requirements are settled.

Now think about if you have all this information in ticket. This is a lot of unneeded data. The person to which ticket is assigned only needs to know about the final decision, and perhaps something else, but this can be all written down cleanly with a link to the discussion in which final decision was made.

Always attach links to the final copy and design updates to the ticket

When a developer is working on a feature, the ticket also includes a link to Beanstalk changeset and the latest design pages. Now these pages can change many times through the ticket. Attaching all the changeset changes and design pages at bottom of the ticket is a huge help.

Clean tickets reduce the probability of error

The bottom line is that you should try to keep your tickets clean and easily readable, at the same time try not to have long tickets which have thousands of lines of text. This means you should have separate tickets in smaller pieces.

Let me know what you think and how you are working in your task management system with tickets.

But, why are you bringing SMTP back?

Well, we are not really bringing it back. Think of the SMTP endpoint as another API entry point. We realize that the entire world does not speak our REST API (yet!), and we want to make sure we can accept messages from as many clients as possible. The whole world speaks SMTP and that is a fantastic way to use Postmark.

I can use both the REST API and SMTP access. Which one do you recommend?

The REST API is, and will always be, the preferred choice to send email through Postmark. We fully control it and can evolve it to fit our customers’ needs best. We add and will add exciting features that are plain impossible to do with SMTP. These days I like to call SMTP access “the gateway drug” to using Postmark. It is ideal in cases like:

• You already have an application in place that sends email using SMTP. You want to try Postmark out, but you don’t want to change your code. Change your SMTP configuration to point to Postmark’s servers, and you are all set.
• You have an old legacy application and you are damn sure you don’t want to touch that code again! Proceed as above :-).
• You depend on an external tool that can only send SMTP. Now, you can use Postmark for that too.
• You happen to work with an ancient or exotic platform (COBOL anyone?) and there is no client library for our REST API for that platform. Share emails generated by your oldest code with us!

How do I use it?

SMTP access is configured for each Postmark server. It is not enabled by default, so you need to go to the server settings screen and enable it. You will get the connection instructions, but basically you need to connect to smtp.postmarkapp.com on port 25 and use your server API token as both the SMTP user name and password. We support both plain text and CRAM-MD5 authentication — please, do yourselves a favor and use the latter.

What is not supported as compared to the REST API

I mentioned above that advanced features will not be available over SMTP. Here is a list of what is not available or just works differently:

• Tagging emails is not supported. We could have implemented that with a custom SMTP header, but our philosophy for this is that using SMTP should require no changes to your code. Modifying your code to add headers sort of defeats the purpose.
• We do not support encrypting the communications channel. Due to a limitation of our SMTP server we do not offer TLS. If you need to guarantee encrypted message delivery, use the REST API over SSL.
• The REST API will immediately return an error if you feed it bad data. SMTP will not. If we detect an error, such as trying to send with a From address that you have not configured in a sender signature, we will log a special “SMTP API” type of bounce. We advise that you review your bounces often or set up a bounce web hook that will alert you when that happens.

I want to know more!

I bet you do! Head to the docs for the details.

A New API Is Born

Postmark has a pretty interesting architecture — its user interface is implemented as a Ruby-on-Rails application, while the delivery API engine is done in ASP.NET. This has enforced on us a clean separation of UI code from delivery code from the very beginning of the project. Since we already had the internal API to let the Ruby app fetch data from the .NET side, it was pretty easy to take that API and expose it through a different endpoint that uses the server API token authentication we already had in place for email delivery and that was basically it. Should I go into details about the extra layer that we built to make sure people had a descriptive error message when they feed us broken data or they get a nice slap on the wrist when they try to access somebody else’s data? Probably not.

Using the API to Work with Bounces

So, what’s in store with the new API? Here’s the list:

• Getting a list of tags defined for the current server
• Retrieving a summary of the delivery issues: the number of bounces for every bounce type and the number of inactive bounces
• Fetching a filtered list of bounces with paging support
• Reading the details of a single bounce
• Obtaining the raw dump for a bounce (One more and I have to hunt for a Thesaurus to get more verbs for reading/loading data)
• Activating an inactive bounce

You can get the full details for every method, the input it requires, and the returned output in the Bounce API documentation.

Now what?

We have done our best to make the API as extensive as possible, and we are almost as good at guessing the way people would use Postmark as Chuck Norris himself, but we may have missed something. So, if a cool idea on using Postmark bounces crosses your mind, feel free to share it.

1. Semantic tagline and subtitles

<hgroup>
<h1>Beanstalk</h1>
<h2>Version Control with a Human Face</h2>
</hgroup>

The hgroup element saved me twice during this work – first for coding our logo and then for marking up subtitles on pages like Partners or Security. It was a pleasure to ditch <p class="tagline"> and other mess like that.

2. Using <h1> as section header

<section>
<h1>Mom, look at this header!</h1>
</section>

In HTML5 each section can have its own <h1> element, so it’s much easier to maintain the correct page outline.

3. Better forms

<label for="fname">Full name</label>
<input type="text" id="fname" placeholder="First">
<input type="text" id="lname" placeholder="Last">

The Placeholder attribute was a nice and painless way to add text placeholders without any JS.

<input type="email">
...
<input type="url">

On the signup and blog comments forms we used new input types – email and url. I especially love how they improve the user experience on the iPhone with customized keyboards.

<input type="text" required="required">

Finally there is a way to semantically mark required fields!

4. figure element in features tour

<figure>
<img src="../images/ss-repositories.png" alt="Beanstalk Repositories">
</figure>

This element may be used for much more than images, but I decided to use it in our feature tour. Sadly, optional <figcaption> child element didn’t allow titles and paragraphs, so I wasn’t able to use it for captions. The <figure> element may not suit the feature tour 100%, but I believe that so far this is the most appropriate element in HTML5.

5. Meaningful dates in blog

<time datetime="2010-03-18" pubdate="pubdate">Mar 18</time>

This speaks for itself. A great way to add semantic meaning to dates.

* * *

Overall, this project went really well. I had only 3 minor issues:

• Wrapping several block elements (like H1 and H2) in A element still doesn’t work well in most browsers.
• Textmate incorrectly highlights HTML5 elements in CSS.
• HTML5 elements code folding doesn’t work in Textmate, too.

After spending couple of weeks with HTML5 it’s painful to get back to old XHTML 1.0 projects – I miss all these funky features!

Tagging

How many times have you wanted to tag your outgoing email and check if it gets delivered, or just get statistics about that category of emails? Would you reconsider your email delivery strategy if all your spam complaints get triggered for the “Mr. X wants to be your friend” invitation email that you send from your social networking site? Now you can see this right in the interface and optimize your email delivery. To start tagging emails, see the new property in the Postmark Developer Docs.

Automatically blocking delivery for certain bounces

We realized that most of the time people do not want to send email to a nonexistent mailbox just to have the target SMTP server bounce the message back. Imagine a bunch of emails hitting the same addresses every day and achieving nothing. It’s both a waste of bandwidth and Postmark credits. Not to mention that ISP’s don’t like that at all and at the extreme you can end up degrading reputation and delivery.

The above situation is not even the worst thing that can happen. Say a user doesn’t want to receive email from you, and clicks the “Report spam” button in his email client. If you fail to handle that, you will keep delivering email, effectively annoying him or her even more. That can have mild consequences like bad email karma resulting in maybe you getting more spam than usual, or, if you are particularly obnoxious at sending those emails, it could result in getting blocked by the ISP and Postmark.

To help with that we decided to start rejecting email that you try to deliver to an address which has previously bounced back. We will do this only for hard bounces since those are guaranteed to represent mailboxes or servers that do not exist, and for spam complaints – those always mean that the user does not want to hear from you. The algorithm is simple — whenever we receive a hard bounce or a spam complaint sent through a server you configured, we will deactivate the recipient address and will not let you deliver email to it. The cool part is that you will not waste credits on those messages either.

Important: Right now we are still allowing emails to be delivered. On Monday March 29th we will flip the switch and stop sending to bounced and spam emails.

But I insist on sending to that address!

Do not worry! The delivery issues interface will allow you to reactivate an email address that has generated a hard bounce, so that you can send email to it again. Spam complaints are different. We feel that nobody should have to put up with continuously getting email he or she feels is spam, so we will not allow you to reactivate an address that has been deactivated because of a spam complaint.

I have several applications. Will deactivating an address for one of them affect the others?

Inactive addresses are associated with a Postmark server. Your applications should follow the recommended practice of using a different server for every application, so that a spam complaint for your WWE fans social network does not hurt your other apps’ delivery.

How will you reject my email? Will I get an error?

Yes, the plan is to eventually get an error back at you. Since that email will not reach anybody, we think it is best that you get an early notification and do something about that. This might cause some problems with your existing code though. Imagine the following pseudocode:

    actionA();
    sendEmail();
    actionB();

If sendEmail() throws an exception because you sent to an inactive email address, actionB() will never be executed. While I think this is not a typical situation (You are doing proper error checking when calling an external service over the network, right? Right?!), we still have to do the right thing and provide a grace period until people check their code. For the time being you will get a warning when you try to send to an inactive address, if you check the Message property of the JSON response. In a week or so, we’ll flip the switch that will start generating real errors.

As a conclusion, I’d like to say that I’m pretty excited about the new features. I hope they are useful for you and your apps. As usual, feedback is welcome.

Open Source Fridays, Postmark Libraries, and more

So far our public repos are mostly focused around our products, such as the gems for Postmark and Newsberry, along with a few others like shellshot and unpacker. Some more recent additions are PrettyDiff, which is the first result of Wildbit’s Open Source Friday’s and Hopsharp, a .NET library for Hoptoad.

As we go, you can expect more projects to be added, so be sure to follow us on Github for the latest.

Git support was probably the biggest update for quite some time, so it did make perfect sense to relaunch the landing site at the same time. I didn’t try to reinvent the wheel here and decided to use the fairly basic 960 grid system, which you can see below. We didn’t use their CSS though, we always prefer to write our own code instead of relying on any 3rd party code or frameworks. The site is our first official HTML5 project and Eugene had a lot of fun with it, he’ll go more into detail in another post.

Besides the visual and technical updates, we also set some goals on the content which we wanted to achieve. A lot of customers asked us about the security of Beanstalk, so instead of answering the same questions over and over again, we build it into the site. Since security is a concern for customers, we made a bit more prominent on the homepage too:

Another thing I want to mention is the Feature Tour. You probably remember our old homepage, where we built the slides right into the header area. While this was an elegant solution, it was also very limited at the same time: the slides weren’t easily extendable. That’s why a separate page is a much more future-proof solution.

I hope you enjoy our new site, feel free to ask any questions.

• It seemed to us it was not a typical usage scenario for transactional email, so it was a safe choice to delay implementing it.
• It was hard to implement. Apart from having to parse the almost free-form format of email addresses that mail servers accepted, we had to deal with finding out exactly which recipient triggered a bounce or a spam complaint.

We wanted to solve this problem anyway because the alternative for customers is pretty bad. To send an email to three recipients, you’d have to generate three Postmark messages. That means three HTTP requests to our service. I wouldn’t do that in a web request handler in my web app because it would degrade the user experience. The alternative is to queue a background job and process it asynchronously… which adds a lot of complexity to a seemingly simple task. That is why we just went ahead and added the feature. You can now pass multiple addresses in the To field and optionally include a Cc field with one or more additional recipients.

But What about Bounces?

Didn’t I just say it was hard to find out which recipient is invalid and triggers a bounce or represents a trigger-happy user that hates your guts and won’t think twice before clicking the “Report Spam” button? Yes, it is not only hard, but it sometimes is just impossible. The tricky part for us was to parse bounces that we get back and try to extract the original recipient from there. That is especially hard to do with spam feedback reports. Some ISP’s (looking at you, AOL!) explicitly redact every occurrence of the original recipient in their reports, and you can literally do nothing about it.

Our solution to that problem was to try and do our best in finding the original recipient. If we fail, we log a bounce or spam complaint with an empty email address. Pretty soon we’ll provide the UI to let you review the full text of the bounce, so that you have some idea what really happened and why. Of course single-recipient emails will use our proven mechanism of detecting the recipient, and in that case we should always be able to infer the bounced address.

I Am Using Client Library X — Does It Support the New Features

I think client libraries will not need any changes to support multiple To recipients. Your code should just work. As far as Cc is concerned, libraries will need to be changed, so that they add the Cc field to the JSON they send to our servers. Library authors, please consult the developer docs for details. We will update the Ruby gems shortly.

You support Cc, but not Bcc. How come?

Frankly we can’t think of a good use for Bcc in a web application. The only times people were trying to use it were when they wanted to have some sort of delivery tracking for their emails and we already offer that through our application. We are working on better bounces tracking and statistics, and to us the most logical way to implement that is to build it in Postmark instead of requiring customers to do Bcc hacks. Of course, we may be completely wrong here — in that case, please contact us.

Shellshot – Deal With System Commands the Right Way

First of all, let me warn you. Issuing system calls is usually the worst way to deal with a certain problem. Executable locations vary from platform to platform. Eventual errors are hard to track. Stuck processes are hard to kill. Parameters should be escaped properly. Chances are someone from the community implemented what you need as a gem. If you really need the performance, drop to C even.

Unfortunately, none of the options above were available for certain parts of our application, so we had to resort to system calls. Sigh. What an imperfect world we live in. But let’s try to prepare lemonade from the lemons we got.

Problem #1: System Calls Are Hard to Cancel on Timeout.

So hard, a SystemTimer library had to be incorporated (note – the gem is SystemTimer, not system_timer). This was the first thing we learned the hard way – don’t rely on the standard Timeout library when you do system calls.

Fork? Wait? Waitpid? Exec or System? Kill?! Kill!!

Executing a command that may get killed is not that simple, in fact:

pid = fork do
  exec('your command here')
end

Process.wait(pid)

The whole fork/wait gymnastics is not for the fainthearted. The ruby documentation assumes you have solid unix background on the subject – which, unfortunately was not the case for us mere experienced-in-the-web-development guys. It took us some time to figure out how to combat the myriad of zombie processes at some point, due to the unfortunate choice of waitpid instead of wait.

Piping? Should I Call Mario and Luigi? Anyone Knowing What Context Switching Means?

This problem caused significant amount of hair loss for yours truly, as it was the most cryptic one. It turned out that there is a subtle difference between

exec('ruby -e "puts 1"')

and

exec('ruby -e "puts 1" > file.log')

In the first case, the command is executed directly. In the second, it is wrapped in sh -c "...". The exec command in turn returns the pid of the sh, and not the command (ruby). So if you try killing the process with the pid, returned sometimes the child command performs the so called context switching and continues its execution. Not what you want, usually.

If you need such output redirection, the solution here would be to redefine std{in,out,err} in the fork, before calling exec.

Confused? Bored to Death?

No worries. You don’t need to remember or understand the issues above. Just use shellshot (check README for documentations and samples). Under the hood it utilizes SystemTimer to keep the call under control; IO.pipe is used to collect stderr and report meaningful error messages to you and avoid context switching. After kill, Process.wait is issued to reap occasional zombie processes.

Should I ditch using exec and system on my own in favor of Shellshot?

Not at all! Shellshot is done for dealing with long-running processes which may get stuck, or can behave in unexpected ways. If your system calls are short and generally safe, this is is not something you should worry about.

Stay tuned for more code for free next Friday!

But this is exactly what happened when Hoptoad introduced v2 of their API and phased the current API out. The guys provided an excellent Ruby client library that just worked. Unfortunately Postmark’s delivery engine is built in C# and Microsoft.NET. Hopsharp, the .NET client library stayed at the v1 API. I guess there are not that many .NET developers using Hoptoad over there, and Ken Robertson, the Hopsharp author, must have a lot more interesting projects on his hands. So, with the code being open sourced and hosted on GitHub it was pretty simple for me to do something about that problem. At Wildbit we are trying to establish a tradition of allocating a Friday each month for open source work, and that is how Hopsharp became my first OSS Friday project.

The Solution

Last Friday I rolled up my sleeves, forked the project and started hacking. The Hoptoad API has changed a lot. V1 used a JSON-based protocol, while v2 uses XML. The Hoptoad guys were kind enough to provide an XSD schema, so that you could validate your data before sending it to them (and before complaining to their support folks that “It doesn’t work”). Here is what you need to provide as the bare minimum:

• An error notice with some basic data: API version and an API key;
• The error (duh!) with a class, message and backtrace;
• Notifier details: information about your library like name, project URL, version;
• The server environment: the app project root and the environment name

My XML skills with .NET were a bit rusty, but I could quickly whip up an object model that I could handle to the XML serializer and have it spew the correct XML back at me. I kept throwing that at the XML schema validator until it got accepted, and that was it. I pulled all external data like environment names, project settings and paths and Hoptoad parameters to a separate class, and set up a builder object to orchestrate all creation and object composition. Being a spoiled xUnit.net user, I felt some pain writing NUnit tests, but I got over that quickly. Today, finishing my work, I was able to send my first v2 error notice to Hoptoad.

The End Result

Overall I feel like I rewrote most of the project. Probably the only thing that is left from the original code is the part that crafts the actual HTTP request to the Hoptoad servers. My efforts are by no means over, though. Here’s what’s left:

• Hoptoad, being targeted at mostly web apps, allows you to submit details about the current HTTP request like URL, controller and action names, request and session parameters and CGI data (server variables?).
• The error reporting part needs more testing and stabilization.
• Building the error backtrace that contains the file and line number for all stack frames doesn’t always work. I guess one needs to deploy the debug symbols (PDB files) for the respective assemblies to get that working. We default to class name for file name and IL instruction offset for line number when that info is not available. Maybe we can do better here.

I’ll probably keep hacking at the code when I get some more free time. After all I want to get rid of my current log4net SMTP error loggers and get back to using Hoptoad ASAP. I’ll post an update when I’m done with sending the request details and when I feel the library is stable enough for me to use in Postmark. The code is available here. You’re welcome to play with the code, send bug reports and, of course, patches.

The volume can be associated with the number of commits from our customers. It’s nice to see that people actually take off on the weekends, although there is a little bit of a rise on Sundays. Most of the work is pretty steady through the work week, with a small bump in the middle. We’ve also had some nice growth in January, which you can see by the rise of emails throughout the month.

It’s nice to use our own product to provide more value to our business. We have lots of plans to enhance the statistics around email delivery for Postmark. If you’re interested, go to the Postmark site and sign up for the beta.

Immediate Future

• Authentication: Being able to verify that you have setup SPF and Domain Keys correctly within the application.
• Web hooks for bounce management: Ping your application when a bounce occurs.
• More libraries for your favorite languages and platforms.

Near Future

• Opens rate and click-throughs: Stats so you can see how your emails are doing.
• Bounce and spam handling: The ability to deactivate subscribers who have bounced or clicked spam.

We’re looking to the beta testers to provide feedback and suggestions so we can continue to build a product you can’t live without. Thanks for the support.

Communication is the key

In order to make products like Beanstalk, Newsberry and Postmark, you need to have great communication in the team. Without communication, projects would quickly lose their pace. We made a bunch of small improvements to keep everybody on the team happy:

Quiet time

When we are working, our goal is to not disturb each other,  so we don’t break the persons “mojo”. Every piece of communication that can wait is not discussed directly through IM. We use Basecamp, emails or tasks for this, depending on nature of the topic which needs to be discussed.

IM Status

IM status can be a really handy piece of information. It can help you figure out whether person is working, whether a person is super busy, when a team member will get back or whether someone is just hanging around after the work day. Although IM status-es are easy to use and pretty obvious, we started using them more intensively just recently.

Discussing features

When we are discussing features, we use Basecamp and include everyone in the team on topics, even if they are not assigned on the project. You never know if someone has a great idea.

Release notes

When we started using scrum, we started using release notes too. Release notes are quite handy. They are not just valuable for Chris (team lead), but it’s also a small retrospective of the work a team member has done over the last iteration. They give an insight for all members of the team about how the project is doing from a high level.

Posting plans

Another great method is posting plans for the work in previous 24 hours, progress at the moment and plans for next 24 hours. It’s one more benefit of using scrum in our virtual team. We tend to post plans in our morning meetings in Campfire.

Managing tasks efficiently

Managing tasks in a task system is never easy. After time tasks pile up and it gets harder and harder to maintain them.  We added a couple of rules to our process to avoid this.

Use simple states

We had a long discussion on which states we would use in the task management system. The more we talked about it, the more states we came up with. Hristo sugested that we use simple states, like

• not started – nobody is working on the task at the moment
• in progress  - someone is currently working on the task
• complete – task is complete and deployed to production site

and it proved to be the best choice for us. By using three simple states, we could easily define the state and have a clear view on the status. We added three more states (which I will mention later), but basically these three states are the ones used most of the time.

Assigning tasks and Milestones

When no one is working on a task, the task is not assigned. That is usually happening in the Backlog. We assign tasks to a person in case we know that person will work on it. Assigning a case is also a way of notifying the person by email about the task. Tasks are usually assigned when we are creating new Milestones. Milestones contain all the tasks you will work on, and usually last between one and three weeks. Two weeks is kind of optimal. If milestones stretch for too long, they get harder to maintain and deploy.

By the end of the milestone, all tasks in the Milestone need to be finished. Now, this is not always possible. Sometimes tasks in a milestone simply get out of hand and can’t be finished in time. In this case we move them to another Milestone, estimated with other tasks in hand.

Backlog and On The Radar

The Backlog is where we hold all of the tasks we plan to work on in the future. When there is a huge list of tasks, the backlog tends to turn into a place where tasks will “die” after a period of time, and will never be implemented. That’s why we try to look over the backlog after some time and clear it up. In addition to the Backlog, we use a milestone called On The Radar, in which we store backlog tasks which we will work on in the near future (next month or so). On The Radar can be handy when you need to figure out the next Milestone for the project.

Small things that make life easier

There is a variety of very small things that can make your everyday workflow easier. Here are some that help us out:

Additional Task states – approved, hold, invalid

I mentioned that we are using a few additional states next to the three basic states:

• approved – task is finished and reviewed on staging, but not deployed yet to production
• hold – task is on hold due to a variety of reasons
• invalid – the task was canceled out for some reason

I find the approved state above the most important. This state happens after we have completely finished the task, but did not deploy the updates to the production website. The task is marked approved and assigned to a developer. When updates are deployed to production, the task is assigned to QA, who checks the production site and marks the task complete (or not).

Allowing the team to be creative

Working on something different and new from time to time can boost your creativity. That’s why we introduced Open Source Fridays and Paired Milestones:

Open Source Friday

Open source Fridays allow team members to work on something different every other week, and to release the product of their work to the open source community. You can read more about OS Fridays in this post.

Paired Milestones

We’ve also started to explore less rigid work flows. An example is Paired Milestones. With this concept, we define some general high-level goals for a project and assign two people to accomplish it in two weeks. This could be a designer / developer pair, two designers, or two developers depending on the goals. Instead of having a project lead and specific tasks, the pair is completely responsible for organization, detailed ideas, and the outcome without outside influence.

What’s next?

We have no idea. When we take a look back, our workflow was completely different and we just can’t image how we could live without some of the improvements we have made. We are constantly improving and would probably say the same when we take a look back one year from now.

On our last retreat we decided to try a new habit: every other friday every team member can take a day off to work on any open source project. I was so excited about this idea that I decided to use my friday today, as soon as we finished some major Beanstalk updates.

Writing open source is not just fun, it’s also very important for developers. It helps us improve our communication skills, learn how to take care of projects in the long run and take responsibility. That’s why we should do it more often.

I spent my friday extracting and polishing a library that we use to render diffs in Beanstalk. I called it PrettyDiff. I made it because other tools like it were either too hard to change (html is hard coded all over the place), or didn’t have features I wanted.

Pretty Diff stands out from the crowd because it’s dead simple to customize. All HTML is concentrated in a single place, so you can quickly adjust output to your specific needs. And the code is very easy to read and covered with comments and tests. Plus it comes with built-in coloring support and copy/paste-safe line numbers. Pretty neat.

I enjoyed my Open Source Friday and I’m looking forward to the next one. Stay tuned for more goodies from the Wildbit team!

Looking back at 2009

2009 was really an incredible year for us. Not only did we mature our products, we also helped launch some great client sites such as STP Collaborative, MeetPips, and Lose It or Lose It.

Beanstalk has grown beyond our expectations. We’ve moved to a new host, we now integrate with over ten services, and added many tools and features. Most importantly, we’ve achieved a stable and scalable environment to keep all of you confident in our uptime.

Newsberry has gone through a lot of changes and witnessed growth as well. We have a completely new public site, shifted focus to high-volume senders with delivery tools, and improved the UI and design of the entire application.

As you may have heard we’re also working on our third product, Postmark, an email delivery service for web apps. We spent the final months of 2009 building and testing Postmark to prepare for the initial beta. The feedback has been great so far and we’re really excited to get it out there.

Personally, I have watched our team mature and grow in 2009. It’s amazing to see them in action. As I have written in the past about virtual teams, it all comes down to people who love their work and share a vision. Watching this thrive in our own team has been a rewarding experience.

What we have planned for 2010

With such a great year in 2009, we obviously have a lot planned for 2010.

Our most immediate goals are to get Postmark and Git Support out of beta and into your hands. We’ve received amazing feedback and enthusiasm on both, so we are just as eager to get them out there as you are. You can expect to see some amazing new features in Newsberry as well, including a new editor and better integration tools. We’ll be running some ad campaigns in the beginning of this year to spread the word.

With all the work we do, we also realized that we can improve communication. We’d like to contribute more to open source, blog more about our process, and make it more obvious when we launch new features. Overall, we want our customers to get to know each person in the team.

Keep in touch

We have some aggressive, but realistic goals set for ourselves, which means awesome things to come for you. To get the lastest, make sure to follow our blogs and Twitter accounts:

Follow us on Twitter at @wildbit, @postmarkapp, @beanstalkapp, and @newsberry.

Subscribe to our blogs for Wildbit, Beanstalk, and Newsberry. Postmark’s will be coming soon.

Thanks so much for making 2009 a great year. We’ll make sure 2010 is even better.

Some of you may have noticed that I was once running the customer side of Newsberry, our email marketing service. In the last few months, my role at Wildbit has shifted a bit to incorporate more “business development-esque” tasks such as tracking our site performance and customer interaction across all of our products. My kickoff post is on an experiment we ran to see if we could increase our conversion rates.

The Free Plan Experiment

We’ve always really loved the fact that we can give some form of our products away for free, so people can try them and see how they work. That said, as any product company, we’re always looking to increase our conversions from free to paid plans. We recently did an experiment (on a small scale) using a few different pricing pages to see if we could convert some more people to purchase a paid plan.

We set out to answer two questions:

• Do people only sign up for free plans, and if given no free plan option, would they sign up at all?
• Do people sign up for a free plan because it is easy and available, but are just as inclined to jump into a paying plan if given enough information and incentive? These people, would sign up for a paying plan even if no free option existed.

Setting up the Experiment

Our design team came up with two pages. The first was similar to what was already in place, offering up the free plan right next to all the paying plan options.

The second page took out the free plan from the plan options matrix, and offered it at the bottom. This way, displaying it as more of a trial option, not a full feature plan.

For both pages we wanted to make sure that we provided enough of the relevant information that a person needs when choosing to sign up for a service. We listed the major features, making sure to highlight those that are only offered for the paid plans. We also highlight one of our biggest strengths (based on what customers have identified) which is the other services we integrate with.

We ran the free plan page for 8 weeks, and then the new pricing page for another 8 weeks. We tracked:

• Total Signups to Beanstalk
• Total Signups to a Paid Plan (and to a free plan)
• Upgrades from the free plan
• Total traffic to the site (to make sure inconsistent traffic didn’t skew results)

Results

Well, before we took on this little experiment, we did some reading on other apps, and it seems like most found that this type of move had positive results on revenue. So, when we set out, we assumed the same. Happily, the results were better than we could have expected.

Most importantly, our conversion rate of Total Signups to Paid Plans went from 9.9% to 12.4%! Here are some more stats:

• Total signups to Beanstalk decreased about 2%
• Total signups to a paid plan increased 54%
• Traffic remained consistent throughout the 16 weeks
• Upgrades increased about 7%

Now, there is a lot of ways to look at this data, but I think every conclusion will be the same: People will pay right at the beginning given the right incentive and enough information. The free plans, for most people, are just an easy way to sign up, maybe so they don’t have to commit and think too much about making a decision.

That said, the decrease in signups is not something to overlook. We have a few theories on this, one being that those 2% were probably not interested in ever using the site or paying. They may have just wanted to check us out, and when the free plan wasn’t so obvious, they left. Another is that people may have honestly not seen the free plan option, and went to a competitor where one was available.

Conclusion

We will be keeping our new pricing page. The short term plan is to continue to edit it, providing more helpful information on the product to help make the decision . Long term, we’ll continue to monitor the results to see if any changes occur. We’re by no means scientists, so we’ll just keep watching and adjusting as we go. We have also discussed doing more A/B testing, so we could test in the same timeframe. That could probably decrease the variance, but we’re pretty happy with the environment from these results.

As we iron out some of the UI bugs and polish the features we’ll start inviting more people. For now, here is a quick screen shot of the server overview page.

Sure, they’re old news and management styles have changed, but even now I reread them to remember their brilliance and to remind myself how much I still have to learn when it comes to managing people, leading a team, and getting yourself organized. While most of these books are focused on large companies, the concepts and principles can still be applied to even a small company like Wildbit.

Here are some good ones I recommend:

• The Practice of Management by Peter Drucker.
• Think and Grow Rich by Napoleon Hill.
• How to Win Friends & Influence People by Dale Carnegie.
• Swim with the Sharks Without Being Eaten Alive by Harvey Mackay.
• Innovation and Entrepreneurship by Peter Drucker.
• My Years with General Motors by Alfred P. Sloan.

What books are on your list?

So, what is Postmark?

Postmark helps web apps deliver email effectively, while giving you the tools to monitor and track delivery. It’s specifically focused on transactional email, so messages like welcome emails, invoices, comment notifications or any other emails that are triggered by an action from your site. Through our existing knowledge of managing large volume email in Newsberry, Postmark provides a more reliable solution to make sure your emails are received. If there are issues with delivery, Postmark gives you the tools to correct the problems and improve.

The service works entirely through a robust API (xml and json), which you can use to replace your existing SMTP code. From the start, we’ll have code samples for many languages (Rails, .NET, etc) to make integration as easy as possible. We’re also looking for help from our readers, so if you have experience with PHP, Java, ColdFusion or want to write plugins for other apps, please email us.

Why is this better than a local mail server?

If you’ve ever built or launched a web application, you know that setting up an SMTP server is pretty easy. The basic steps can have you up in running in minutes. What you may not know, is that doing it correctly is complex. For instance:

• Setting up authentication like SPF and DomainKeys
• The importance of Reverse DNS
• Managing connection and message rules for each ISP
• Applying for ISP whitelisting and feedback loops
• Accreditation with ISIPP and ReturnPath
• Tracking bounces and spam complaints
• Understanding volume over time

The list is longer, but hopefully you get the point. With Postmark, we bring these benefits directly to your application so those important emails get to your customers or members. If delivery problems arise, you’ll know right away.

When will it be ready?

We’re in the final stages of launching our private beta. The beta will be available to a small group, then opened up more as we learn and tune the product. If you are interested, please sign up for the beta.

Where free succeeds

Where the “free” model plays an important role is not the fact that it is free, but the ability to prove your product. The “try before you buy” concept is not new. By offering a free plan, you give your potential customers a risk-free opportunity to try your product. This can go a very long way compared to “30 day trials” or a well designed marketing site.

The other area where free has value is word of mouth. The majority of our accounts are free, while this puts load on our system and support, it also creates a loyal base of people who rave about our product. We’ve seen many examples of freelance developers on free plans who then convince their clients to use Beanstalk on a paid plan.

Finally, the last point of value is about creating movement. When we started Beanstalk, our goal was to convince more people to use source control and improve their process. It amazed us how many people still did not have proper source control for their projects. By offering free plans, each account is a small triumph for our goal. The “greater good” value eventually brings back more value to the business as more people use source control.

Where free fails

With all that said, there are definitely cases where free does not work. I was doing a quick review of our stats and noticed something interesting. We get a nice number of visitors from stackoverflow.com. One post in particular sends the most traffic, which is titled Free Online Private SVN repositories. Here are some stats for a given period:

• Visitors: 2,617
• Free sign ups: 728
• Paid upgrades: 6

By breaking these numbers down into conversion rates we see some interesting results. First, the conversion rate from visitor to sign up is huge, almost 28%. The conversion from sign up to paid on the other hand is awful, only 0.8%.

What does this tell us? It’s pretty obvious, people who are looking for free will most likely not pay in the long run anyway. If we don’t offer enough resources at the free level, they will probably just go somewhere else. Knowing this, it helps focus attention on the people who are looking for value and willing to pay for it and service them as best as possible.

Learning from the numbers

We are just beginning to understand the details and still have a lot to learn. We’ll continue to review results and study conversions to help make our products more profitable. In the long run, this helps us grow our business and expand our offering for our customers. We’ll be sure to write the results here as well.

Do you run a web product? We’d love to hear your results as well. Please share in the comments.