cnagele's comments

This is a big reason for sure. As you can see in this post, those IP addresses can be hit or miss depending on the provider. At Postmark, we don't really believe in dedicated IPs for all customers. We think that our customer base should not include any bad actors, and instead manually approve every customer to ensure our entire CIDR ranges are clean. The benefit is not just clean IPs, but clean IPs that have an incredible transactional-only reputation with the ISPs. This is how we are able to delivery so fast to the inbox. We only really believe in dedicated IPs for higher volume senders, especially since reputation is moving toward the domain more and more. I wrote about this six years ago, and it is even more true today (https://postmarkapp.com/blog/the-false-promises-of-dedicated...).

At the same time, if you are willing to install and manage Postal on your own servers, it's not that hard to maintain your own IP with a great reputation. You just need a good hosting provider (probably not AWS), you need to set up your infrastructure like DKIM, SPF, DMARC, rDNS, and Return Paths, and most importantly you need to maintain good engagement (low bounces, high opens). At a glance, Postal looks like a nice option if you want to do it on your own for cheap. You just might lack the stability, support, maintenance, and performance that goes behind an ESP.

Hey everyone, Chris Nagele here from Wildbit. For some background, I wrote about our reasons for moving to a private office plan. In short, it's more than putting on some headphones.

http://wildbit.com/blog/2015/03/06/wildbit-hq-ending-the-ope...

And a tour of the office itself:

http://wildbit.com/blog/2015/08/05/wildbit-office-tour

SparkPost's claims are misleading here.

LinkedIn, Facebook, Twitter, etc do not use Sparkpost, they use their on-premise installable software that many ESPs use and pay tens or hundreds of thousands for, which indeed is a dumb pipe MTA. Those big companies still have a full-time staff managing delivery and infrastructure. It's basically a replacement to Postfix, not a full fledge, multi-datacenter, multi-tenant hosted application to support many thousands of concurrent customers.

A hosted "product" is a different animal. Sure, it needs to have great delivery, but the work that goes into making it easy to troubleshoot when you have issues, minimize developer work, and bring useful data back into your application is something else. This only becomes painfully obvious when you deeply rely on email for your business.

There is a reason why Sparkpost left Postmark out of their comparison. We have the same data sources (eData), and we came out on top.

[1] http://pages.sparkpost.com/Big-Rewards-WP-Download-Landing-P...

Three things to add here:

1. Our pricing reflects the quality of delivery due to being transactional only. With much higher engagement rates, our speed and delivery is superior. Customers never have to wait behind a bulk campaign.

2. Dedicated IPs are a way for ESPs to pawn responsibility onto customers instead of themselves (and get a few more bucks in the process). They only make sense if you are sending a huge volume, but we do offer dedicated IPs for free for higher volume accounts. Instead, most people use our shared IPs and benefit from the volume of great engagement to get their emails delivered to the inbox faster.

More details: https://postmarkapp.com/blog/the-false-promises-of-dedicated...

3. We're the only ones to offer an extended full content history of every message for 45 days. You can search and see the exact email sent at no cost, which comes in handy when sending so many unique messages.

Full disclosure: I'm the founder of Postmark. Any questions, just email me: [email protected].

Thinking of "email delivery as a commodity" is the first mistake people make - all ESPs are not created equal. If this were the case, there would not be such a huge variance in not only getting to the Inbox, but how fast you get to the Inbox. This is why we've focused on transactional only, knowing fully well we will grow slower as a business (and why we are more expensive), but have superior delivery since transactional email has a much higher engagement rate and reputation with ISPs.

The entire idea of "dumb pipe" or "commodity" needs to go away. There is a reason why companies like Asana, Desk, and Minecraft chose Postmark, since their email is critical to their business and choosing the right providers makes a real difference. Now, if your emails are not critical, I can see how any service might work. I have yet to come across a product owner who is comfortable letting their customers wait for their transactional emails though - no matter the size of product or company.

Full disclosure, I'm the founder of Postmark - the best "dumb pipe commodity" money can buy.

When we were searching for space this was our preferred choice. We wanted a large single floor space with offices on the perimeter. Each office would have a glass wall to see the open space. This way, as you said, people can see what is going on. Searching for office space is hard, so we ended up where we are and made the best of it. We still get the offices on the perimeter and the glass wall, but separated by multiple floors. Maybe we just put Dropcams everywhere so people can see when lunch is ready :)

These are great questions. I'll be sure to do a follow up post in a year and see where we are. I know that the biggest reward when we went from 100% remote to having an office was the feeling of being in touch with what was going on. It was also the spontaneous conversation. I am hoping we don't lose that.

It's actually the biggest reason why we have a chef prepared lunch. We found that it forces everyone out of their desks at one time to hang out as a team. We usually don't even talk about work, which is the way it should be.

The other assumption is that the break out rooms will become longer term project team rooms. So if a couple of people are working on a feature for a few weeks they can take over a room to focus together.

I can say for sure that being a remote team enabled us to work around a lot of these concerns. It's easy to feel isolated when you are remote, so we work hard to make sure all communication happens asynchronously or in chat, even if we are in the same room. We also use video a lot, and my hope is that we can use it even more in the new office with remote team members.

Your first point reinforces our decision on private offices. We encourage only working 8 hours a day. This way you don't have a chance to stay late or work long hours to find that "quiet time" when everyone is gone. It's up to us, the founders, to make sure you are productive during the day.

We believe that when you come to work you should make the best of those hours so you can spend the evening with your family, friends, or just relaxing.

Chris from Wildbit here (author of the post).

Half of our team is remote. Using physical space for controlling productivity (or lack of) is not a solution. You and the rest of your team should keep each other accountable through performance metrics that are mutually agreed upon. Being a remote team for so long (15 years) has forced us to find alternatives to traditional office babysitting and it has helped us design our new office as well.

That's the best part, we are not funded at all and are building this office after eight years of profits from our products: Beanstalk, Postmark and dploy.io. We count every dollar that goes into the space and it is purely an investment in our team and culture. I'm personally researching everything from glass panels, to steel sourcing to carpet with our architects to keep costs down.

That's a great point. It reminds me of the "Library Rules" at the 37 Signals office: https://signalvnoise.com/posts/3357-an-office-with-ldquolibr...

At the same time, I think visual distractions also need to be taken in consideration.

Agree. We'll make some updates to explain it better. Our hope was that the more simplistic overview would be enough. For now, you can read the blog post about it:

http://wildbit.com/blog/2013/09/17/dploy-io-our-third-produc...

It's heavily based on Beanstalk deployments, so you can also read about how it works here:

http://beanstalkapp.com/features/deployments

Hi Paul. About a year ago we migrated from Rackspace to Server Central, a colo facility in Chicago. Since then performance and uptime have been incredible. You can read more about the move and hardware here:

http://blog.beanstalkapp.com/post/30879384331/beanstalk-is-m... http://blog.beanstalkapp.com/post/34706145918/new-servers-th...

Our new app, dploy.io, runs on the same infrastructure.

Capitalism works how you want it to work, that is the beauty of it. It's the business principles that lead the decisions that are made, either big or small. The point of the post is deciding what principles you set, and how they will shape the company as it grows. It's my personal feeling (along with my wife and business partner) that while we have competitors, and we compete every day, there are still some boundaries.

There are an abundance of opportunities to obtain new customers and demonstrate a superior product. While this might be one of them, it is not one I respect as a tactic to grow a business, and one I would never use myself.

Don't forget, the principles you set early should stick with your company as it grows. If you "take advantage of every opportunity you can" you may one day find yourself in a place you do not respect either. I think this is the definition of what people have termed "evil companies" in our industry.

It's your choice of course, and that's the beauty of it.

Hi Ben, the ES connector was part of it. At a certain point we had our custom oplog follower working well. After so many years working with MongoDB, we just lost trust in it, to be honest. We ran into so many bugs, replication issues (two secondaries and no primary) and the only way to get what we needed out of it was to use all SSD storage (Even flashcache did not work).

I have to admit that this was for our use case, and I know that MongoDB works extremely well for some people. We still use it in Beanstalk for our deployment logs and have no complaints. It's a much smaller dataset though.

Really nice to see that 10gen made an ES connector. ES is still young, but it's amazing. One thing that I always respected about 10gen is how they maintain all of the drivers and code.

Sorry, I need to correct that. I meant that shards are basically still primary / secondary with an arbiter for failover. We prefer horizontal nodes instead, like Cloudant, Elastic Search or Cassandra offers.

Chris from Postmark here. We definitely had some trouble over the last few weeks. I am hoping we are beyond that in terms of architecture. So far everything looks great.

Regarding lock-in, this was pretty important to us when we decided to migrate. We prefer to control everything in our data center, so if it came down to it, we wanted that option. Since the Cloudant API is compatible with CouchDB, the migration path is not that hard. Although, considering our impression so far and their expertise, I don't expect it will come to that point.

Hi everyone. Chris here from Postmark.

I would say that MongoDB durability used to be an issue, but now with journaling and replica sets it's not as much of a concern.

There were two reasons why the secondary was less capable than the primary. First, the data had become very fragmented due to our frequent purging. And second, we were in the middle of an upgrade to our servers and that one had not been tackled yet. The primary failure came at a bad time. I could have clarified that better in the post.

Regarding capped collections, yes they are faster. The problem is that they can't be sharded. With our dataset that would not allow us to scale.

Hi there. Chris here from Wildbit. I want to make sure I clarify some points.

A big reason we waited so long to shut it down was leaving our customers stranded. Even at such low revenue, we owed everything to them for allowing us to get our first product off of the ground and finding value in our service for so many years. It was a VERY difficult decision.

We did not make a move until we had a very good transition process for all of our customers. We set up a partnership with Campaign Monitor so each customer could easily migrate their lists and avoid any downtime in sending emails. Sure, it is a pain to export and import lists, but there are many good options out there such as Campaign Monitor. If your electric company shut off your service you would surely be screwed, not really the same case here.

Regarding Postmark, this should make you feel even more confident about it. We've seen amazing growth and our team is so passionate about Postmark that we decided it was worth giving up profits on Newsberry to make it even better. That says a lot about our commitment to our other products and our focus as a team.

In the history of Wildbit there were many times when we could have just added a few employees to keep profits going in one area while we worked on something else. A perfect example is when we decided to drop consulting to focus on products. We could have kept it going along side of products, but focus is everything in business if you want to create something that people really love and enjoy to use.

Hey everyone. Chris here from Postmark. This topic means a lot to me, so if you have any questions just post a comment and I'll try to respond quickly.