garrettdimon

I can't tell from your question if you're asking for a simple "performance" or "redundancy" answer or if you're asking for a deeper explanation about application architecture. So, I'll try to answer both.

The short answer is redundancy. With virtual servers, problems on the host machine due to neighboring virtual servers can be frequent. This can slow down the application server and lead to performance problems. With two load-balanced application servers, this isn't as much of an issue.

For the database, I'd suggest reading up on replication. In addition to the master/slave databases, we also have hourly, daily, and weekly snapshots stored offsite because a slave database isn't enough protection from some types of data loss.

Application architecture is a whole beast unto itself, and my real recommendation would be to find and hire a professional to handle this kind of stuff for you.

"Spend" is a very misleading and even distracting metric. Before going to deep into this, it's worth noting that you should never rely on advertising as your sole source of traffic generation when bootstrapping. It gets expensive, and it generally doesn't generate immediate returns. Pay-per-click can be an exception, but that's also an expensive game to get into.

Unfortunately, much of our advertising experience isn't going to be relevant due to how long ago it was. We advertised primarily on FusionAds and Daring Fireball, which has increased from $2,500 to $8,500. We don't have a daily advertising burn, and we never really have as we just dabble in advertising from time-to-time.

I'd be willing to bet that advertising has at best contributed 10-15% to our growth. Given the amount that we've spent, that's a very high cost of acquisition. However, it did help generate some awareness. There's a whole lot of context with advertising. The first $5k was relatively more effective because Sifter was so new. It was great for generating awareness. However, after that initial awareness is generated, unless you're going to spend heavily (more than $10k a month)on a branding campaign any additional impression-based advertising to the same audience generally won't be as effective.

Trials and free accounts are two very different things. Free accounts implies that they are perpetually available at no cost.

Keith doesn't draw a salary at all. His equity is large enough that he's simply banking on the day that we stop re-investing 100% of our profit and start paying out some sort of dividends.

That wasn't time tracking. That was just the number of hours in a year. :) I was pretty bad and really worried about things almost non-stop. So it was a bit of an exaggeration--but not much.

No problems yet. (Knock on wood.) We never had any ambition plans of raising money or going public, so we just wanted the simplest structure that wouldn't require extra costs or overhead. There might be tax implications, but that's more the realm of my business partner, so I'm not really qualified to offer any extensive advice there beyond the fact that you'd want to consult an accountant in addition to a lawyer when incorporating.

I answered this in a little more detail further down the page, but the short version is that I didn't really have a customer acquisition strategy. I just had a little overlap from my blogging and a product that I wanted to build. The rest was pretty basic. Do things and tell people. By talking about it, I was able to reach a fair amount of people who were interested and start from there.

In terms of a competitive market, I really just kind of went the opposite direction from the established options out there. The truth is that those other apps were and are great for some teams doing large complex software development projects, but there was a whole other group of smaller teams that didn't need all of the advanced features that those big players offered. I thought the world need something between a todo list and those options, so I tried to fill in the gap.

It's both. The upside is that I didn't need to find a designer or developer to build it, but the downside is that it's a lot of work to keep up with all of the skills that I need. Ruby, Rails, design, front-end development, MySQL, servers, etc.

Fortunately, as we've grown, we've been able to contract work to friends who are experts in each of the areas, but it can be rather daunting at first.

The other downside is that when designing, I always begin to think about how design decisions will trickle down the front-end to the application to the database and sometimes even to the server. As a result, it's hard to just design and implement. I'm always caught up thinking about implementation even when I'm working in Photoshop.

These days, the biggest benefit is that even though I'm far from an expert in any of the areas, I can competently navigate all of the topics and maintain a pretty holistic view of both the business and the product. That makes it much easier to effectively coordinate everyone as the team grows.

It's an LLC, but for better or worse, that's not a decision that we put a lot of time into. So it's probably not a meaningful data point.

It was just a matter of running some SQL queries and putting it into iWork Numbers to generate the graphs.

There wasn't much experimenting. I've always been so heads down on the product, I've been terrible about running tests. I probably rely way too much on my gut feel with decisions like that.

That said, removing the $14 plan did not hurt us at all. Since the $14 plan was half the cost of the next plan ($29), we were simply hoping that 50% of the people that would have signed up at the $14 level would go ahead and be willing to pay $29. At that point, the decision means we make the same revenue on fewer customers. My theory was that would help me stay on top of providing sub-30 minute email response times to all of our customers without going crazy. :)

While I don't have exact numbers, based on our growth after the change, probably 75% of people that would have chosen the $14 plan simply signed up at the $29 level and the other 25% didn't sign up. So, the net effect was great for us.

I have finally hit my pre-Sifter salary. We could have technically afforded it a while ago, but we only recently decided to make the adjustment. Of course, that was my salary 5 years ago, and from what I've gathered, I'm still way under what I could be making elsewhere--especially if you factor in benefits.

Keith, my partner, has never been full-time. He's always been involved at about 5-10 hours per month, and that's still the case these days as well.

I have a blog post that talks about the pay cut side of things a bit on my blog. http://garrettdimon.com/post/34571624540/can-you-afford-a-pa...

Unfortunately, there's not a recording, but I'm doing my best to expand on the slides and add in the year's worth of lessons learned since this deck into a book.

http://startingandsustaining.com

I hear this question a lot. Unfortunately, there's not a simple answer. In my case, it was a matter of blogging for years, building up a modest, but interested, audience, having about 2,000 Twitter followers at the time, and spending about $5,000 on advertising once we had been live for about 3 months. I also blogged extensively about the process of designing the application and some of the other steps involved.

Really, though, it's not the first customers that are hard. It's maintaining and continuing to work on it and grow it during the time where growth isn't amazing and it isn't yet a full-time job.

This deck is over a year old. A lot has changed. I'm not really a fan of disclosing actual revenue numbers because that opens a whole other can of worms.

As such, I chose revenue and how it related to our ability to pay me a salary.

Author of the deck here. I'm actually in the middle of evolving these into a book. http://startingandsustaining.com

Happy to answer any questions anybody might have.

Thanks for the feedback. That's definitely part of the plan. While I'm not quite sure just how detailed it's going to get, I've started on a one-page checklist of the items that I talk about in the book.

Thanks for mentioning it. Intercom is in there, kind of crammed into the "support" category. I'll definitely add Customer.io and create a dedicated category.

Ultimately, this wasn't meant to be an exhaustive list. It's just a quick list from some very superficial collecting of URLs. There's still a lot of work to do for the book before the list is complete.

I try to avoid any specific recommendations of services because everybody's needs and priorities are so wildly different. I'm very much of the belief that it's best for people to take a look themselves rather than rely on others' preferences.

In terms of not mentioning other services, it's probably more a matter of the book being in progress. I've done quite a bit of research, but the vendors list is rather incomplete because I'll be including it in the appendix of the book. So in most cases it's simply a matter of the fact that I haven't actually finished it yet. These are mainly just from my notes that I've jotted down.

Fixed. Thanks for the heads up.

Fixed. Thanks!

I believe I'm overlooking how to manually force line breaks in there. Any tips?

I've been assembling a list of these lately for a book that I'm working on. (http://startingandsustaining.com) Some of the categories are fairly loose as some apps don't fit nicely into categorical buckets, but hopefully this is a helpful list.

--Browser/Email Testing

BrowserStack (http://www.browserstack.com)

Litmus (http://litmus.com)

--Bug/Issue Tracking

BugHerd (http://bugherd.com)

Lighthouse (http://lighthouseapp.com)

Sifter (http://sifterapp.com) (Disclaimer: I built this.)

--Planning & Project Management

Sprintly (http://sprint.ly)

Podio (https://podio.com)

Flow (http://www.getflow.com)

Interstate (http://interstateapp.com)

Basecamp (http://basecamp.com)

Apollo (http://www.apollohq.com)

Pivotal (http://www.pivotaltracker.com)

Asana (http://www.asana.com)

Trello (https://trello.com)

Blossom (https://www.blossom.io)

Trajectory (https://www.apptrajectory.com)

--Business & Traffic Analytics

KissMetrics (http://kissmetrics.com)

MixPanel (http://mixpanel.com)

DigMyData (http://digmydata.com)

--Continuous Integration / Code Quality

Travis (https://travis-ci.org)

Circle (http://circleci.com)

CodeClimate (http://codeclimate.com)

Sempaphore (https://semaphoreapp.com)

--Dashboards

Ducksboard (http://ducksboard.com)

Geckoboard (http://www.geckoboard.com)

Instrumental (https://instrumentalapp.com)

--Error/Exception Handling

Sentry (https://getsentry.com)

Coalmine (https://www.getcoalmine.com)

HoneyBadger (https://www.honeybadger.io)

BugSnag (https://bugsnag.com)

Raygun (http://raygun.io)

--Log Monitoring

Loggly (http://loggly.com)

Papertrail (https://papertrailapp.com)

LogEntries (https://logentries.com)

--Billing & Payment Processing

Braintree (https://www.braintreepayments.com)

Stripe (http://stripe.com)

Pin (http://pin.net.au)

PayMill (http://paymill.com)

Recurly (http://recurly.com)

Chargify (http://chargify.com)

Spreedly (http://spreedly.com)

Spreedly Core (https://core.spreedly.com)

--Support/Help Desks

Desk (http://desk.com)

HelpScout (http://helpscout.net)

ZenDesk (http://zendesk.com)

Groove (http://groovehq.com)

Intercom (http://intercom.io)

Tender (http://tenderapp.com)

--Transactional Email

Postmark (https://postmarkapp.com)

Mandril (http://mandrill.com)

MailGun (http://www.mailgun.com)

SendGrid (http://sendgrid.com)

CloudSMTP (http://www.cloudsmtp.com)

CritSend (http://www.critsend.com)

Postage (http://postageapp.com)

--Email Collection/Landing Page Apps

Launchrock (http://launchrock.com)

Unbounce (http://unbounce.com)

KickoffLabs (http://www.kickofflabs.com)

Launch Effect (http://launcheffectapp.com)

Prefinery (https://www.prefinery.com)

LaunchGator (http://launch.deskgator.com)

For me, the biggest difference was that Gumroad only offers to pay via PayPal, as opposed to running payments through Stripe. I've heard way too many horror stories to trust PayPal when selling things online.

I'm not claiming that they should trust us. I'm only saying that it works both ways, and that we as business owners have a choice about whether to trust potential customers just as much as they have a choice about whether or not to trust us.

It might be anachronistic, but if a potential customer wants to begin a relationship with us with a lie, then of the two of us, I would think we have more reason to mistrust that individual than they have to mistrust us. Their mistrust is based on projecting bad behavior of other companies onto us whereas our mistrust is based on them actively beginning the relationship with a lie.

Of course, this decision may cost us some potential customers, but for now, that's something that we're willing to accept.

My feelings are that trust is a two-way street. If people don't trust us with their email address, I don't think it's fair for them to expect us to trust them with an account on our service if they provide a fake email address.

If they are serious about evaluating our product, they can provide a real email address. If they aren't very serious or inherently don't trust us, then I'm willing to miss the opportunity of having them as a customer.

I respect their privacy, because we don't spam, sell, or abuse any of these email addresses ever, but I find it hard to trust anyone with an account on our service if they use a fake email address. Personally, when I sign up for services, I find it helpful to gauge the company based on how they use my email. If they automatically start sending me marketing materials the next day, that tells me a lot, and I'll generally cancel the service and report all of the subsequent marketing emails from them as spam. The only way to do that effectively is if I use a real email address.

Do people use these fake inboxes for any reason other than trying to prevent or cut down on spam? Am I overlooking some key aspect of allowing people to use these email addresses?

It's unfortunate that businesses do this. Starting off a relationship with a new customer by effectively saying that your pricing isn't 100% honest seems like the wrong way to go about it.

I want every one of our customers to be 100% confident that they are paying the same price as anybody else on the same plan. In our case, I've even explicitly refused to do any deals or promotional discounts. This keeps things simple for us to keep track of as well.

Just a guess, but October is only 13 days in. Thus, about half the revenue so far this month.

It sounds like this was a question for me, but it looks like a reply to a different comment. I actually never take calls, especially in the middle of the night. :) Sometimes, I'll email customers and ask if they'd like to chat on the phone about their ideas, but phone support isn't realistic for us.

I do respond to emails if it seems like the customer could really benefit from a response, and even sometimes when they aren't looking for a response. Sometimes, if it can wait, I'll go back to sleep and handle it first things in the morning.

I hadn't heard it put that way, but that's definitely a good point. My view on all of this is still evolving, and we're getting to a point where it's not going to make sense for me to the primary person on support. As far as above and beyond, you're definitely right. It's all relative. If that part of it bothered me anymore, I'd probably look to make some changes, but oddly enough, I enjoy it, so it's not too big of a deal to maintain that kind of turnaround time.

For us, the biggest change was adding an awesome system admin to the mix on retainer. He's been a huge help and we now have a much more resilient architecture. It's all evolving though as I find time to streamline the processes as needed.

All definitely some good food for thought. Thanks!