First, welcome Russ Thompson to the team. Russ will be in charge of web operations for Postmark and Beanstalk, making sure our servers run smoothly and keeping performance steady as we grow. He will also be working on benchmarking and improving our overall infrastructure as we expand into more data centers.

Then say hello to JP Toto. We’ve known JP for a while, but he’s only recently joined the Postmark team at Wildbit. When we realized that he was not only experienced in .NET and Ruby on Rails, but had specialized in enterprise systems and infrastructure, we knew he’d be a great addition to the team as Postmark continues to grow and delivers more and more emails every day.

In addition, Ilya has joined us in Philadelphia for the next year or so on a training program. That means that our Philadelphia office has 7 people in it now, almost twice as many as 4 months ago!

We’re excited about what 2012 will bring. Our first retreat of the year is off to a great start and we’re excited to share some of our plans for the year once we’re back home.

You may have heard or read about Wildbit shutting down Newsberry, our first product on January 2nd. Chris wrote about a few reasons behind it, but I felt like we needed to be totally honest about how we got to this decision. This was a tough time for us, personally, as this was our first endeavor at a product company many years ago. When we shut it down, it was profitable and little effort, yet we still did it. This is why.

Some backstory

Seven years ago our consulting company built it’s first product, Newsberry. An email marketing service when there were very few (at least good ones) out there. We built it as a solution for some of our own customers and then saw a potential market. All the while, we continued concentrating on consulting. Newsberry was always an afterthought, as it couldn’t support the entire team. We would work on it, add features, but not full-time.

Fast forward to 2007 when we had a new itch, and built Beanstalk. We instantly felt closer to the product since we used it every day. We were excited about it and the momentum from customers was much stronger than Newsberry ever had. Newsberry was still there, growing, but mostly just maintaining year after year.

In 2009 Chris asked me to leave my short stint in corporate America to come back to Wildbit to try to revive Newsberry. We had reached a point: we had to do something with it, or shut it down. There was stagnant growth, we couldn’t keep up with the fantastic new services around us and we needed some time to concentrate on it. So that’s what I did, or at least tried to do. We had a developer working full-time on Newsberry at this point and we shifted gears and came up with what we thought was a really innovative approach. We wanted to open email delivery to the customer, give them a dedicated IP and let them see exactly how their sending practices affected them. We partnered with ReturnPath and designed an incredible interface and system to track reputation using ReturnPath’s Sender Score. I wrote a post on email delivery for an industry blog. And then we waited. And nothing happened. We missed so many opportunities because we didn’t market it loudly. Or maybe it just wasn’t something people wanted or looked for. We really had no pulse on the industry and market. I have a hundred theories, and only one with some certainty: it failed.

It was difficult in the team to push a project nobody was interested in. Our team was so focused on Beanstalk, Newsberry became the stepchild. We barely used Newsberry monthly, let alone daily. We were a team of designers and developers, and to us marketing was like a foreign language. I personally had very little motivation as I watched other companies kill it with beautiful design and extraordinary features. It was a gloomy time, but we kept at it.

In 2010 we launched another email service, Postmark. We scratched our own itch again. Beanstalk was sending a ton of transactional email, but we had no clue what it was, where it was going, whether it reached the Inbox, etc. We wanted a Newsberry but for triggered application emails. And we figured if we needed it, so did others. Postmark was a huge hit right out of the door. Our existing developer audience contributed to that of course, but it also helped push Newsberry even further away.

Our last ditch effort

We decided that since Newsberry wasn’t growing, it could not support a full-time developer on the project. Then, we dropped our rates in half. We just couldn’t justify charging people the same rate as other products that provided a richer service. There will always be an audience for a cheaper, simpler alternative so that’s what we became. The first month our revenues cut in half (obviously) but within 3 months we were back at the same rate. That meant we doubled our customer base and we got excited a bit. At that same time we noticed that a lot of these customers weren’t using the best sending practices. Our bounces and spam complaints started going up. The customers who wanted cheap were also using cheap methods to grow their lists, and we started kicking people out. As people started signing up we’d refuse their accounts. So the growth basically stopped.

Why we made the decision to shut it down

Whenever Chris and I would see his parents, his dad would ask about Newsberry. He called it the “CEO’s pet project.” The one that doesn’t really do anything for the company but you keep around because it has both sentimental value and it’s too difficult to part with. When we announced shutting Newsberry down it was a profitable product, making approximated $75,000 a year, in profits. A lot of people will look at that and think we’re crazy. We had similar thought for the last year. The problem is that that profit came at a hidden cost.

Newsberry was not a product we were proud of, and that’s a huge problem for our team. Wildbit prides itself in design, detail and quality. Newsberry just wasn’t fitting the bill. I once logged into Campaign Monitor after not seeing it for a long time. I was blown away by how beautiful and smart it is. It was so much of what we always dreamed Newsberry would be. How could we keep going along if we knew that it wasn’t our best work? The team ignored it. Nobody used it or even knew how to use it. And yet we were charging people money. Sure, it did exactly what it was meant to do, and really well. We still had phenomenal email delivery, and the list-based method really resonated with a lot of people. But it just felt wrong.

Postmark was demanding a lot of attention as a growing product and Beanstalk was continuing to grow as well. They needed all of our concentration, and we just didn’t have the energy or mindset to keep that going with Newsberry. Concentrating on what you are good at is so important. Working on what you feel passionate about is critical. Newsberry was neither of those things for us.

When we sent out the announcement about closing to our customers, I cried a little. This was our first baby. We felt so defeated and at the same time relieved. We setup a partnership with Campaign Monitor to help make the transition smoother. We felt our customers deserved a better service. A lot of these customers had been with us for years, many since the beginning. I felt like we let them down. The relief came like ripping a bandaid. We could shut it down and concentrate all of our efforts on the products we think about when we get up in the morning. We could be intensely proud of our entire portfolio of products again.

Why we didn’t’ sell

Yes we got offers to sell. People asked to buy our code, the IPs, the lists (ha!). We didn’t sell. We would only consider selling to a company we could be confident would do do right by our customers and the industry. We talked with a few large companies that reached out to us about an acquisition but it never panned out. We didn’t go looking and we’re ok with that. Selling would have involved a lot of effort and time, and we just needed to focus on our products that were growing.

What we learned

If we could go back, I think we would have closed it down a lot sooner. The honest truth is we haven’t loved it in many years. That said, Newsberry solidified some core beliefs we have as a team and a company. Working on what you love, what you use, and are proud of is the key to being successful. Everyone says it, but this has been a real reality check for us. Sometimes we kick ourselves thinking about how open the market was when we started. But we’re quickly remind that it’s just not who we are as a company. We don’t feel a pulse on that industry and that’s ok. What a great experiment we had. Three products, one that we didn’t use ourselves and two that we use every day and love.

And as expected, one had to go.

We handle a lot of support between Beanstalk and Postmark. We have, and I say this all the time, the best customers in the world. They are designers and developers, just like us. So most support is really great and easy to answer. On occasion a client or two come along who starts building an entire reputation amongst our team. They are difficult, and not in an angry way, more like a lazy or inexperienced way. Our team will help to a fault sometimes. We will provide articles and screenshots and links to books, but the customer would rather have us do it for them. Then we summarize what’s in those screenshots, and books. Still nothing. We’ll spend hours trying to teach someone how to use version control, or even write them some code to access our API. In one of those moments, I had a thought: How much support is too much for $15 a month?

I think it’s like pooling. In insurance, we take an approach that many pay for one. The same goes with this. If we had 10,000 accounts that pay $15, and 5 of them cost me $500 in hours of support, it’s totally ok. When it get’s bad is when one customer starts taking away from others, using that $500 to themselves. I don’t think we need to hire more support people, I think we need to fire some clients. And, we do. We don’t want to owe more than we make, we don’t have investments to make up for it.

So, going through the extra effort for some customers, even when difficult, is fine. Just make sure there is a balance.

On Monday November 21st, we’re excited to be hosting Philly.rb, our local Ruby user group, and their monthly Hack Night.

From their website:

Hack Nights are a great chance to get some input on your personal project or help out with other projects in the community. Bring your laptop and and your favorite coding tools! Beer will be served.

All are welcome to join this free event and meet some of the Wildbit team. Just RSVP here.

Overall I would say that we accomplished that goal. We built a complicated system that was simple to use for our customers. It brought in some revenue and maintained profits year after year. At the same time we learned some important lessons that helped us become the company we are today.

Newsberry was our first attempt at becoming a product company while trying to maintain consulting contracts. We treated it like a side project with potential, instead of a service that was a big part of the future of our company. When we started Beanstalk, we knew that to make it successful it needed dedicated attention.

We also learned that our team and passion is aligned better for a certain audience, designers and developers. For years we tried new features, new strategies and even focused on different segments to grow Newsberry, but it never worked. What we realized is that we didn’t lack the ability, we lacked the connection to our customers. This became most apparent to me after Beanstalk started to grow. I noticed that as a team we used Beanstalk every day and immersed ourselves in the product and subject, which helped us come up with new ideas and connect with customers better. With Newsberry on the other hand, I would get a perspective every couple of months when we decided to send a newsletter. The rest of the team hardly even used it. There is nothing more important than using your own products.

The biggest lesson I learned is that you need to know when to shut it down. In hindsight we should have done it a long time ago. Nothing is more important than focus and it was clear that Beanstalk and Postmark were growing like crazy while Newsberry remained idle.

With that said, the technology and domain experience we learned from Newsberry helped us create Postmark. The difference is that we solved our own problem and focused on an audience who we already knew. The growth of Postmark is proof of how important that is.

Partnering with Campaign Monitor

One of the reasons why it took so long to make this decision is that we did not want to leave our customers stranded. We decided that we needed a strong partner in email marketing to migrate our customers. At the same time, we have a strong rule in Postmark that we only focus on transactional email. This has allowed us to stay focused and has had a tremendous impact on our inbox delivery rates. With this focus, it meant that we also need a strong partner for integration when it comes to email marketing and bulk sending. The company who we have admired most over the years is Campaign Monitor. They run their company with similar intentions and focus, realize that design comes first and have been an inspiration to us in many ways.

I decided to reach out to Dave Greiner and he welcomed the idea. They have provided a generous offer to existing Newsberry customers to make the transition easier, and we will be building integrations together, allowing each of us to focus on what we know best. We’ll handle your transactional emails, and they’ll send the newsletters.

We have stopped accepting new customers for a week now, and officially updated our landing site to reflect this. Existing customers can gradually move over in the next two months, and both teams will be here to help. While I’m saddened to lose our first product, I’m extremely proud of the years it’s served as a valuable service. It was a long journey to get to this decision, but we’re confident it’s the best for our team and our customers. They deserve the best tool out there, and Newsberry has not fit those needs recently.

If anyone has any questions feel free to post a comment or email me directly at cn@wildbit.com.

New members of Wildbit!

We were sad when Daniel Crenna left Wildbit two months ago, and started to look for someone to help support Postmark. After a few weeks of interviews, we found a perfect fit in Oren Mazor. Oren is a multidisciplinary computer guy, with software, hardware, and security backgrounds. He’s also active in his local community and an amateur car mechanic.

We’d also like to welcome our newest Rails developer to the team, Artem Chistyakov. Artem lives in Krasnayarsk (Ilya and Dmitry’s city) where he attended all of Ilya’s coffeshop meet ups. After talking to Artem, we asked him to join us as an intern to work on some Postmark front-end updates. It wasn’t long until we realized he’d be an awesome addition to our team full-time! He’s now working on Beanstalk and Postmark front-ends.

Also extremely exciting is the addition of Dana Chaby to our Wildbit family. Dana is going to be our chief customer advocate, answering support for both Postmark and Beanstalk. She comes from a business manager background and is super excited to become an expert in version control and email sending. She’s been with us since August 1st and has learned the ins and outs of our products. Email her to say hello!

New Office

With the addition of Dana, we’re now 4 people in Philadelphia. We started looking for a larger office and found one we loved faster than we expected. We’re in an awesome loft space that just happens to be right above Indy Hall! It’s a space big enough for us to grow in to as we look for more members of our team in Philadelphia. We’ll be sure to post more photos as we decorate and get comfortable!

At Wildbit we like open source a lot and we use open source projects and libraries every day. So when I started working on Mercurial this summer I thought: Why not make a Ruby API for Mercurial (that we had to build anyway) as an open source project? Really, no reason not to do it. So, here it is!

https://github.com/iSabanin/mercurial-ruby

If you ever wanted to interact with Mercurial in Ruby it’s your lucky day. With “mercurial-ruby” you can connect to any Mercurial repository on your local machine and do various fancy things with it. For example you can view commits, branches, diffs, find files and directories, and more. You can also create repositories.

The gem is pretty stable already because we use it in production for our Mercurial beta. It’s also fully covered with tests, so if you feel like hacking the code it should be very easy for you to get started.

I loved working on “mercurial-ruby” and think it’s my best piece of code yet. I hope you enjoy it too!

Design

With this problem in mind I designed a status page to help people understand what’s going on with Beanstalk at any time:

My goal was to make it really simple to get rid of any distraction. We use special headers for moments when we have issues or have a maintenance in progress:

Days without incidents

We thought that it would be interesting to count the days since the last incident, so this number is always there right below “All services are operating normally” message. We are really motivated to keep this number as high as we can!

It’s simple jQuery which calculates the days since the last update and replaces the default message:

// To keep code clean and semantic I store time in datetime attrribute of HTML5's time element
var lastUpdate = $('#updates article:first time').attr('datetime');

// By default this paragraph has universal message for those with disabled JS
$('header section.status-ok p').text(distanceOfTimeInWords());

function distanceOfTimeInWords(){
    var now      = new Date;
    var fromDate = new Date;
    var from     = fromDate.setTime(Date.parse(lastUpdate));

    // Convert milliseconds to days and round to the whole number
    var days     = Math.round(((now - from) / 1000) / 60 / 60 / 24);

    if (days < = 1) return 'Issues were reported in the last 24 hours. Read below for details.';
    else return 'It’s been ' + days + ' days without any incidents.';
}

Platform choice

We had internal debates on how to build this page — plain HTML is easy to build but hard to update and maintain, while simple Rails app hosted on Heroku takes some time to build, maintain and extend with extra features. Tumblr become a winner for a variety of reasons:

• It took only half an hour to create a new blog, convert HTML mockup to template and add a custom domain name.
• Everyone on our team already has Tumblr accounts, so we all can post updates.
• We can quickly post updates and even change headers with just an email.
• It already has an RSS feed.
• It doesn't share our servers and environment.

We use FeedBurner for all our RSS feeds and it has a nifty feature which lets our users subscribe to updates by email. This way subscribers can be notified of maintenance work or issues on our end within minutes.

Switching headers

Of course Tumblr wasn't intended for this use, so I had to come up with some workaround to show appropriate headers. Thankfully Tumblr has tags, which can be used even when posting by email. We agreed to use three tags - 'ok', 'problem' and 'maintenance'. The appropriate header is displayed with simple JS based on tag of the last post, while tags itself are hidden.

var state = $('#updates article:first .status');
var latestState = (state.length > 0) ? $(state).html().toLowerCase() : 'ok';

$('header section').hide();

if (latestState == 'problem') $('header section.status-problem').show();
else if (latestState == 'maintenance') $('header section.status-maintenance').show();
else $('header section.status-ok').show();

The status page is linked from many places on our landing site and within the application. Make sure to subscribe to RSS or email notifications or follow us on Twitter to get latest system updates in time.

Great Communication Earns Trust

One of the most common pieces of positive feedback we get from Beanstalk customers is how responsive we are to support and communication – but that doesn’t mean we can’t always be looking for ways to improve! We know that being clear communicators, not just when things are going wrong, helps people trust us and love our products even more.

This simple status page will help us build and keep the trust of our customers, hopefully you can use some of these techniques to do the same thing for your product status pages!

You might not have even noticed, but Gmail previews the first few lines of text in an email right after the subject. Normally, this is great, helping you peek inside an email to determine if you want to read the rest. But we realized that for our newsletters, the preview piece was always the same: “Follow us on Twitter. Read our Blog. View this Newsletter Online”. Not very helpful, is it? Wouldn’t it be great if those first few lines were more descriptive, or at least more enticing to the reader?

I poked Eugene about this problem, since he’d recently done a bunch of work to optimize our email templates for Beanstalk. He hadn’t heard of a good solution, so he set out to experiment and create his own.

The challenge was to create some text at the beginning of the email that would be shown as the preview, but not appear in the body of the email itself. It turns out, like many HTML email tricks, an old-school method ended up working best.

Remember spacer gifs?

Back in the days before beautiful CSS-powered layouts, we used tables. Sometimes a table cell needed to be propped open, and a common technique was to take a 1px by 1px transparent gif image file and set its height or width dimensions to stretch it as a “shim” to hold a table cell to a certain size.

Since HTML emails use tables for layout, Eugene was inspired to go back to some old tricks.

<img alt="Free tutorials, tips and best practices to help you make the most of your design and development workflow." src="spacer.gif" width="1" height="1" border="0">

By putting the text we want to show up in the Gmail preview in the alt tag of a 1px by 1px spacer gif, we were able to accomplish the desired effect without changing the visible content of the email. Success! Nice work Eugene!

What to put in your optimized email preview text?

The key to these previews being useful is to find information that supplements the subject line of an email.

For our newsletter announcing Beanstalk Guides, we made the preview more focused on the kind of person who might want to look at guides – in our case, people who wanted to make the most of their design and development workflows.

For your newsletter, you will want to write a preview that speaks to your ideal recipient. Let the subject focus on the specifics of a deal or offer – the preview should be a little more personal feeling!

Update: Looks like Campaign Monitor wrote about this technique…in 2006! We’re glad to see that we’re not the only ones who’ve found this solution, but we’re also sure that we’re not the only people who hadn’t seen Campaign monitor’s post, either. So we’re happy to give this topic a much needed “bump” and encourage people to improve their emails!

Mobile isn’t just in the browser

David Greiner from Campaign Monitor recently posted results from their report and it’s fascinating to see that mobile email clients grown from 4% to almost 20% of the market in just 2 years! From their historical chart, it seems fairly certain that mobile email usage will overgrow desktop email usage in a year or two. Thinking about my own iPhone usage supports these statistics — I check emails, feeds and tweets all the time, but go into Mobile Safari only when I have a good reason.

With this in mind, I began to think about Beanstalk’s emails — newsletters, digests and commit notifications. We’ve made them quite nice in desktop and web clients, but what about mobile clients? Can we keep them nice and readable here? Turns out we can! Mobile Mail on iPhone supports media queries, which makes possible to use the same responsive web design technique we applied to the rest of Beanstalk. How cool is that?

I’d like to show you how we applied screen-size specific media queries to target styles, and what design decisions were made to make the mobile email experience much better

Digests

I started with our Daily Digest emails, which provide an overview of the previous 24 hours activity for a given Beanstalk repository.

First was to add a media query for the iPhone’s small screen:

@media only screen and (max-device-width: 480px) { ... }

After improving font sizes and margins it was clear that mobile version was too cramped, so I decided to hide the commit time. It’s usually more important to see what’s changing than when exactly something was committed, and the time is still presented on changeset page for reference if needed. Next, I reformatted the changes summary — a vertical layout worked much better on a small screen. And the last change was to reformat header into two lines instead of just one. Here is how digests look now:

I noticed minor visual issues on iPad, but they were easy to fix by targeting with this media query for the iPad’s screen size:

@media only screen and (min-device-width: 768px) and (max-device-width: 1024px) { ... }

Newsletter

We also send a regular newsletter to Beanstalk customers, and with experience from digests, it was a piece of cake!

I improved font sizes and margins to use more of the screen space, resized the logo to be proportional to the screen, reorganized the navigation to avoid wrapping, and made images flexible. Now our newsletter doesn’t need any pinch-zooming to navigate and is much more readable on small screens!

What I have learned

• Testing in a mobile email client and not just in mobile browser or resized desktop browser is more important now than ever before. Mobile Safari and Mail on iPhone don’t work exactly the same.
• It’s not easy to customize layout based on table cells, but display: block; and negative margins work really well for for small changes.
• In my tests it seems like <meta name="viewport"> (?) doesn’t work in Apple Mail. This caught me off-guard, and may cause you problems as well.
• At first I tried to keep width of emails flexible but in a result every digest had different scaling based on content. That looks really weird if you receive a few digests every day. Sometimes it’s better to keep things fixed at 320px. This requires thinking about your use case!
• Yahoo! Mail removes media queries and applies all included mobile stylesheets to web client, but there is an easy fix for that.

Conclusion

It’s not hard to optimize emails for mobile email clients, and the result is worth it! Even while we still use table layouts and inline stylesheets for emails in 2011 it feels like a fresh breeze to drop in some media queries and advanced stylesheets for the clients that can support them.

We’ll continue to optimize our HTML emails here at Wildbit, and would like to see more optimized emails from the apps we use and love every day as well. Hopefully sharing our experience helps make that a reality!

We knew hiring the right person would be a difficult process. The perfect person would have to show qualities and experience we weren’t used to looking for. As if by chance, we bumped into Sarah Hatter as she was launching her new consulting service, Cosupport.us. Sarah, coming most recently from the 37Signals support team, started CoSupport.us to help small businesses improve their support. Her team helps organize support needs and hire in-house support staff.

After a few talks with Sarah, we decided she would be the perfect fit to help us. We’re happy to report she is managing our support as of April 1st for Postmark, and starting today, for Beanstalk. This is the first in a two step process of learning about our needs to ultimately hire a new full-time Wildbit team member dedicated to supporting our customers. Sarah will be watching for common questions, helping draft responses, and learning about us so we can be prepared for the hiring process.

New Support System

In part of the revamping of support, we have also migrated to a new support system. While we love Tender and have been very happy customers, our needs have grown where we require more automation and integration to our workflows. We have decided to move to Assistly, who happens to also be a Wildbit customer! Assistly will provide us with one support system for both apps, as well as integration with our customer databases that will make support more efficient. What you can expect is the same (and even better!) level of support, with the following visible changes:

• All support will be answered right in your inbox.
• Much easier ticket submission right from the app instead of opening your email or creating a ticket in the help site.
• A new knowledge-base, with the same articles you’re used to.

We are confident this new system will make our excellent support even better, and we’re looking forward to working with Sarah to hire a full-time customer advocate!

We like to spread out our support hours and for that reason would love someone in North America or South America. We are a completely virtual team, so you’ll need to be self-motivated, very passionate, and organized. Our team is currently located in Philadelphia, Russia, Ukraine, Serbia, Germany and Canada.

If you’re interested, we’re going to be looking for the following information about you. Just email jobs@wildbit.com.

• Your experience working with / building web apps
• The city and country where you live
• Any open source projects you’ve contributed to or maintain
• Personal blog, site or articles
• Any blogs or people you follow (helps us understand your interests)
• Books that have inspired your work

Some things you should know about us:

• We plan and release in short iterations.
• We use Campfire for daily meetings
• We have team retreats in places like Greece, Turkey, Cyprus and Spain
• We have a dedicated QA Tester, but expect your work to be fully tested on your own as well.
• We have each person contribute to support in order to understand the needs of our customers.
• We schedule time for open source projects as part of Open Source Friday’s.

Interested?

Email jobs@wildbit.com and include the information above. If you’re not the right person but you know somebody who is, please share this post!

Bantam

Robert Nystrom wrote an interesting article about the benefits of Pratt parsing for quickly breaking down expressions into usable code. As a reference, Douglas Crockford’s JSLint uses this approach to parse Javascript in order to validate it. When you’re rocking Pratt, you never go back. I ported Robert’s Pratt parser example as well as the tiny Bantam language that demonstrates its use. If you really want to be blown away, check out Robert’s Magpie language for the JVM; it is both dynamic and static, has multiple inheritance, multimethods, and still manages to stay clean and expressive.

You can get the Pratt code here or add it directly in Visual Studio from NuGet.

Metrics

Alex tipped me off to an eye-opening CodeConf presentation by Coda Hale of Yammer fame on making better business decisions by instrumenting code, and he provided a Scala library called ‘metrics’ to do it. The last slide read “Please build this“, so I did. The code itself is an interesting use of the new .NET 4.0 concurrent types, as well as a few borrowed concepts from Java like AtomicLong and TimeUnit. It was a fun and challenging project to put together for the CLR, and I hope you will join me in making it a useful contribution to .NET. We already instrument quite a bit of our code at Wildbit, but I’m looking forward to streamlining everything through metrics, and using HTTP-based reporting to make real-time visualizations for the rest of the team. Mainly, I am happy to ditch Performance Counters in favor of a lean and mean interface, though some of them are still in play behind the scenes.

You can get the Metrics code here or or add it directly in Visual Studio from NuGet.

Things I learned (or re-learned) during this retro Java port-a-thon include:

• The closest you can get to magic in this industry is running a data-driven business.
• There are no dead languages, only dead people. Cool stuff is happening everywhere.
• The JVM is a lot more flexible, when it comes to runtime introspection, than the CLR.
• While C# extension method usage can quickly border on the obnoxious, adding them to enums is the knees.

We spent the first couple of days trying to get the satellite internet to work. Turns out there is a strange bandwidth limiting model that makes it useless even for minimal work. It was a bit stressful, but not having internet was a pretty interesting experiment as well. It gave us some time to detach and discuss without distractions. Probably the most amazing result was Dima completely rebuilding our deployment code for Beanstalk. More on that later.

Exploring Spain

We stayed in an amazing villa called El Munt, which is in the small town Castelltercol, about one hour outside of Barcelona. It was literally in the middle of no where. If you don’t believe me, check out the ride on the road to the villa in the video near the end of this post. We spent most of the time hanging out at the villa, swimming in the indoor pool, playing ping pong and basketball or cooking on the barbeque outside. It was the most beautiful place we have stayed on a retreat! Catalonia has a lot to offer, so we made sure to spend the nights out at local restaurant for dinner. Most of our team agrees that our best meal was at Hotel Urbisol, about 40 minutes from our Villa. We also took a day trip to the Dali Museum in Figueres and to the Dali House in Portlligat.

For the last two days of the trip we decided on a change of scenery and stayed in Barcelona’s Eixample neighborhood, not too far from Sagrada Familia. This gave us a unique opportunity to reach out to some of our customers in the area and organize a meet up. We met some great people and had an awesome night.

Secret projects

Before the retreat, we came up with a new idea for a retreat activity. Each person was asked to come up with a project to share with the rest of the team, but generally keep it a secret. If we didn’t provide any direction or influence to each other, what would we come up with? We didn’t make a big deal out of it, just something small, even if it is not that useful. On the retreat, we spent a day presenting all of the ideas. I was stunned by the results. There was everything from new ways to analyze our financial data to new features in our products and new ways to manage our infrastructure and quality. It really shows that building a company is all about hiring the right people. With a great team, amazing things just happen if you let them! I don’t want to spoil what we came up with just yet, so stay tuned and keep an eye out for some nice releases.

Setting goals and plans

While we’re not very strict at Wildbit about deadlines for features, each retreat we set some short and long term goals for our product roadmap and the business in general. It gives us the chance to align our growth goals with the smaller projects or features we release for customers. To keep the goals in view, the most we do is look six months into the future, which should be our next retreat. Here are some of the high level goals without making our roadmap too visible:

• Remove, not just add. We’re watching closely which features are being used, and which are not. We’re careful about keeping our products clean and simple, which means that an opportunity to take things out is valuable because it means we can keep things simple and fast, and also make room for new things that our customers will love.
• Improve communication. This goal is tri-fold. We’ve identified some places in our applications where language can be improved to make functions and messaging easier to understand, so we’ll be working on that. We also believe strongly that Beanstalk in particular should help team members communicate better, so there’s some features coming to support that. And last but certainly not least, you – our customers. We want to get to know you better, and for you to know us better, so we’re going to be writing and communicating with you a lot more.
• Businesses Love Beanstalk. And we want to keep it that way. We’ve thought hard about what benefits we can bring our business customers, and that’ll be influencing some of our roadmap moving forward with Beanstalk
• Major features coming to Postmark. Again, we’re not going to say too much, but we’ve got major features in the pipeline for Postmark that we think you’re going to love. We’re also working on getting a tighter iteration schedule for Postmark which should let us roll out more little stuff more often. We also just released a new homepage, be sure to check that out!

Overall, this year’s trip was a great time and extremely valuable for the whole team. As a special addition, Ilya shot and produced a little video that might help you feel like you were right there with us. Enjoy!

So needless to say, we’ve been working on this for a long time. We’re so excited to see what apps of the future TWSS can empower.

The best way to continue the momentum is a retreat. In a virtual team, nothing is more motivating than getting together with the team. We talk strategy, get to know each other better and just have a good time. 2010 was really an amazing year, so we are splurging a bit more than we usually do. In early April, the entire team (from six countries) will fly to Barcelona. From there, we’re renting an old farmhouse to get away (we’ll still have internet) and work side by side for a week. After that, we’ll spend a few days in the beautiful city of Barcelona. Huge thanks to El Sol Villas for helping us put this together. Coordinating a trip for so many people is not easy.

Meet us in Barcelona!

We know our customers are from all over the world. So, if you are around Barcelona from April 8th – 10th, let’s meet up! Drinks are on us. We’ll figure out a date, time and location soon. Just RSVP and let us know if you can make it!

So, what does all of this have to do with Wildbit? 2010 was a great year for us. Beanstalk has grown significantly and we launched Postmark, our third product, in April. The growth is both exciting and overwhelming. Towards the end of last year we realized to really grow, we need to connect more with our community of designers and developers we’ve built through our products. This is where Alex comes in. We’ve known Alex for years, and we’ve even worked with him on occasion and go to him for advice when it comes to outreach, sponsoring conferences and creative marketing. With our audience and his skills, it’s a perfect fit.

I have no doubt that you will hear from Alex. In just two weeks he’s already taken part in gathering more data about developer libraries, promoting the latest iPhone apps for Beanstalk, coming up with a strategy for our sponsorship of Superconf in February and helping us plan our 5by5 marketing this week. Yeah, I told you, he’s awesome.

Make sure to welcome Alex to the team. If you’re not already following him, you can find him at @alexknowshtml on Twitter.

So who is Milan and what is he working on? Milan also lives in Serbia. He has an impressive list of skills from building cross-platform apps in C++, writing an alternative to SQL in LISP and his latest work in Java and .NET. He has his Master’s in Software Engineering and also teaches talented high-school students at Petnica Science Center.

Milan has been working with Hristo on the .NET side of Postmark. The main architecture that handles the API, Queueing and delivery is all written in .NET, so having Hristo and Milan team up has been incredible so far. We’re getting ready to release an entirely updated server environment which Milan has had a huge part in building.

So, please say hi and welcome Milan to the team. You’ll surely see him in support and will hear from him on both the Wildbit and Postmark blog soon. You can also find Milan on Twitter as milan_gornik.

Beanstalk is now using Dynectastic daily to create/delete dozens of records and nodes. You can find all the information you need in the README file. As always, don’t hesitate to send patches and pull requests if you know how to improve Dynectastic. Happy coding!

While the JavaScript snippet, which creates a small popup window in your page, works great for marketing sites, it can create quite some overhead in applications like Beanstalk. Loading the extra code on each request is probably not the best idea when your application aims for fast load times. I know that Olark supports asynchronous loading, but I still think you should not bloat your code when it’s not really necessary. After some hacking, I came up with a simple replacement for the Olark chat window, which is loaded in a plain, oldschool HTML popup window. It even has avatar support, which makes the customer experience even more awesome. We already use it in Beanstalk, with Postmark soon to come.

One thing this chat window does not do is ask for customer’s name or email first. This was intended though, just let your app do all the work by dynamically inserting the customer data. You can even pass along more advanced information like the account ID.

Want to use this in your application too? Then head over to Github and grab the code. Don’t forget to signup at Olark, they also have a free plan to test things out.