Outsourcing everything you can is the key to concentrate exclusively on your product. I already wrote in my last blog post what a startup needs to get up and run. This time, I will get into more detail about what you should outsource from your back-end.
Every startup usually has a founder and a co-founder that gathers all the necessary information and technology to get things easily done. But what is the right choice? There is a ton of vendors and services that offer all kinds of back-end technology, from newsletter systems to Node.js servers. I will list some services and applications you might consider using.
Mailchimp is a popular email marketing service for newsletters. You can import and collect email addresses with their simple tools, and it’s easy to handle, because it has many integrations for your website and WordPress.
Don’t consider using your own email server for newsletters. You don’t want to be blacklisted, manage single subscription errors, and deal with customer preferences. Mailchimp will do all this for you. It provides an endless list of templates and possibilities to make sure your newsletter is unique.
We already integrated Mailchimp’s signup form into this blog (see right side). There is also a pop-up window when you visit www.chef.one for the first time.
And we integrated Mailchimp with Slack. So every time a new person signs up for our newsletter, we get a notification. Awesome to know who of your friends signed up and who didn’t. This is how we feel when someone signed up:
When we released the pre-alpha to some of our friends and customers, they came up with many questions and suggestions. Every new product/technology/service always brings up customer curiosity. So they start asking. And mostly, the questions have the same pattern. Answering every email, Facebook post, and Twitter question is very time-consuming with so many channels.
Zendesk can help you with that and even more. Seriously, when it comes to Zendesk, I am an evangelist. And not just because I read Startupland by Mikkel Svane (CEO of Zendesk). By the way, thanks Mikkel for that hint using a woman face as customer service.
Zendesk will be your customer service engine. Your customers are the key to success. If they are not happy, no one will be happy.
I remember back in the days, when one requested something via customer support, one had to wait for a week or more to get a reply. Sometimes you even forgot that you requested something until the answer finally arrived.
Now, if you don’t reply within 5 hours, your customer will use a different service. The alternatives are endless, and if customers don’t like your response time, your information, or your attitude, they will look for something better. If you don’t like the service at McDonalds, you go to Burger King, and if they don’t give you what you expect, you go to Five Guys, and so on and so forth.
Make sure you reply to your customers like you reply to your girlfriend, or your dad, or a good friend. They need that feeling that you care. If you just copy and paste text templates, you might save some time, but you will lose customers real quick.
With Zendesk you will have one central back-end service where everyone in your team can handle customer requests. When you reply to an email, for example, there is the support engineer’s avatar, which makes it more personal. The features and options are endless. It easily integrates with your website, WordPress and Slack, of course. The price plan is pretty fair: 2$ per agent, with some limitations.
Parse is our main backend playground. It’s where all the trouble happens.
Parse got acquired by Facebook and I had the opportunity to chat with Charity & Michael from Facebook about the pros and cons which other customers are facing with Parse. I’ve been surprised by the possibilities that Parse offers: webhooks in combination with Heroku, push notifications for mobiles, RocksDB for your database, easy UI anyone can understand.
Let’s be honest, you won’t have neither the time nor the experience to create your own back-end infrastructure. Even if you know how to set it up, you will need someone to make sure it’s available and up-to-date all the time. Don’t get yourself into a struggle against human mistakes, don’t start the battle for high availability. Parse will do that for you.
The documentation is pretty self-explanatory and gives you all the details about the structure in Parse. We never faced any downtime or struggle in terms of back-end problems, which enables us to focus on coding and building great things.
The price policy of Parse is more than fair since they won’t charge you anything until you reach more than 30 requests per second. We are currently in the alpha stage and do not face a high amount of calls to the back-end, so we don’t have to worry about that much. So should you in the beginning. When you need more, you can pay $100/month for 40 req/s.
Some people complain about this “high” price policy, but I don’t agree. Let’s go back to the McDonald’s and Five Guys Burgers analogy. McDonald’s is much cheaper than Five Guys, but has its limitations: you can’t either change or upgrade your burger, all things are pretty limited, and taste OK at best. On the other side, you can choose whatever you want at Five Guys in any combinations. It gives you more flexibility and it tastes much better, but at a bigger price.
There are other vendors like Parse, and we checked them all, and they are just like McDonald’s, and they taste so 2008.
There are maybe two reasons for having more than 30 req/s. You either have bad-code with application logic that calls your back-end all the time, or you have too many users. Check your analytics to see what’s going on. If it’s not an application logic mistake and not bad-code, then you are probably already making enough money to pay $100 or more every month for Parse.
We are currently optimizing our requests from the Parse DB and changing the structure every day to make sure we don’t reach the 30 req/s limit. That is pretty cool! Many startups have an awful database/application structure and don’t care until there is no way around. These are the times when winter finally arrives, as Jon Snow warned us so often. We will have another blog post with more details on this.
Heroku supports several programming languages in the cloud. It’s a Platform as a Service (PaaS) where you can load all your developers’ code. I think every developer will quickly understand how it works.
Parse offers webhooks in combination with Heroku. For example, we have a webhook, when a new user is added to our database, we send out a welcome email via Heroku + Sendgrid (more on that below).
This trigger is based on our _User class and the afterSave method. When a user is added to our DB, the trigger calls the URL to action.
Sendgrid is a transactional email delivery service. As I already mentioned, you can use it in combination with Heroku to send emails to your customers when they sign-up, request to reset the password, receive payment emails, etc.
Sendgrid is very verbose and has a powerful API where you can do anything you want in terms of email transactions. Setting up your own SMTP server for sending emails is mostly a great pain: you have to take care of blacklisting, high availability, spamming issues, bugs in your application, etc. Do you have the time, budget, and resources for that? As any startup in the beginning, absolutely not.
Below is a small graph to illustrate how we use our outsourced backend when a user signs up:
Outsource as much as you can. There are cloud services for anything, and if there is no service, then there is no need for it. Do we need all these service? Well, at CHEF.ONE we do, since our main focus is on the product itself and not everything around it.
But remember: no online service is crash-safe or bug-free. Be ready for unscheduled maintenance as well. Also, none of the services will be as fast as your own infrastructure, but until you reach a bottleneck, you shouldn’t care about it too much.
The good thing about these services is that they do all their administration. Let’s assume your system administrator leaves and there is no documentation, because you are just a startup. You next sysadmin will have a hard time to maintain your infrastructure, and they might have to start from scratch. Online services on the other hand are well documented and very reliable, so your next sysadmin will not take as long to understand your back-end architecture.
Tip: I strongly recommend to set up a developer Twitter account, where you can follow their services to make sure everything is running fine. Create a Slack channel (for example, cloud-services-status) where you can integrate your Twitter account and follow the services. Heroku, for example, has its own Twitter service account: whenever an incident or error happens, it will notify you there. (https://twitter.com/herokustatus)