Bootstrapping a Software Product(bootstrapping.sifterapp.com)
bootstrapping.sifterapp.com
Bootstrapping a Software Product
http://bootstrapping.sifterapp.com
51 comments
I'll followup with the SpeakerDeck folks. I expect they'll have it working soon. I think they got slammed a bit more than they expected, but they're throwing more resources at it now.
The PDF is hosted at Amazon S3, so server resources at SpeakerDeck shouldn't matter. The problem is the wrong permissions on the PDF.
https://speakerd.s3.amazonaws.com/presentations/4e6a452f4932...
https://speakerd.s3.amazonaws.com/presentations/4e6a452f4932...
Gotcha. I passed it along. I'm sure they'll get it sorted soon. If you'd really like it now, shoot me an email, and I'll send it along. garrett at nextupdate dot com.
Permissions fixed. Sorry!
I know you meant "got slammed" but getting "god slammed" is probably how their server felt.
Great deck for those of us working toward a switch from a service model to a product model. It's rare that the lifestyle aspects (marriage, home, children) are covered in decks about startups or bootstrapping, but those are such HUGE considerations if you have (or want) a life outside of your work.
I'm not a Sifter user (different needs), but I've gleaned a lot of professional insight from your posts/interviews/presentations in the last few months. Thanks for sharing so openly.
I'm not a Sifter user (different needs), but I've gleaned a lot of professional insight from your posts/interviews/presentations in the last few months. Thanks for sharing so openly.
Slides obviously miss a lot of context if you didn't attend the presentation, so I'd love to chat with folks or answer questions if anybody has them.
Would you mind saying a bit more about why you felt building your own billing system was a bad idea?
We're looking into that at the moment, and have been considering the usual options of DIY, using Recurly/Chargify/similar, going quick and dirty with Paypal/Google, etc. Right now, after a great deal of investigation and contacting many organisations for more details, we are overwhelmingly thinking that a simple, direct system with a payment gateway and merchant account is the way to go. None of the usual recurring billing suspects has even come close to justifying the costs and usually lock-in of integrating their service instead.
However, in the HN goldfish bowl, almost everyone seems to have a different view (though I have noticed a few dissenting voices creeping in recently). Right now, all we've done is a bit of prototyping with the test system for the service we're looking at using and a thorough read of the docs. If we're about to enter a world of pain when we actually want this stuff to work, it would be good to hear any advice about how to minimise the damage and make it through!
Great slides, BTW. Thanks for sharing.
We're looking into that at the moment, and have been considering the usual options of DIY, using Recurly/Chargify/similar, going quick and dirty with Paypal/Google, etc. Right now, after a great deal of investigation and contacting many organisations for more details, we are overwhelmingly thinking that a simple, direct system with a payment gateway and merchant account is the way to go. None of the usual recurring billing suspects has even come close to justifying the costs and usually lock-in of integrating their service instead.
However, in the HN goldfish bowl, almost everyone seems to have a different view (though I have noticed a few dissenting voices creeping in recently). Right now, all we've done is a bit of prototyping with the test system for the service we're looking at using and a thorough read of the docs. If we're about to enter a world of pain when we actually want this stuff to work, it would be good to hear any advice about how to minimise the damage and make it through!
Great slides, BTW. Thanks for sharing.
The main reason that I don't personally believe it's a good idea is that it's not a core part of Sifter. We use Braintree and process everything via ActiveMerchant, but we've been using Braintree so long that we're actually on their old API.
Obviously, since we built it in house, I don't have any hands on experience with the other options that are out there now, but from what I've seen with other applications, I can't see any reason not to use the other providers.
The downside to not building your own system is that you may lose some control over things like invoice formatting or other parts of the user experience.
The other aspect that's a big consideration is PCI compliance. We don't store any payment information on our servers, but it does pass through our servers which means we have to have the minimum amount of PCI compliance. By offloading it to another provider, you're almost entirely free of any significant PCI compliance.
Now that it's done, it's kind of nice having full control over every detail of how we handle credit cards. However, I wouldn't do it again now that there are so many other options out there.
Obviously, since we built it in house, I don't have any hands on experience with the other options that are out there now, but from what I've seen with other applications, I can't see any reason not to use the other providers.
The downside to not building your own system is that you may lose some control over things like invoice formatting or other parts of the user experience.
The other aspect that's a big consideration is PCI compliance. We don't store any payment information on our servers, but it does pass through our servers which means we have to have the minimum amount of PCI compliance. By offloading it to another provider, you're almost entirely free of any significant PCI compliance.
Now that it's done, it's kind of nice having full control over every detail of how we handle credit cards. However, I wouldn't do it again now that there are so many other options out there.
Thanks for the reply. I can understand your reasoning, but I think perhaps our situation is different.
For future reference, you might like to know that there are now regular payment gateway/merchant account combinations where you can use their systems to handle the final part of the transaction so you never even have card numbers on your network, so the PCI DSS issues are moot, at least here in the UK. The lock-in isn't ideal, but as far as I know only Recurly out of the major billing services doesn't effectively lock you in just as badly anyway.
However, we've found that the recurring billing platforms tend to lack precisely the kind of flexibility you mentioned above. We have all kinds of plans to use promotional codes, multiple offerings that users can subscribe to individually or in combination, etc. As far as we can tell, none of the "big name" billing services even gets close to supporting this kind of stuff properly yet.
For the benefit of anyone else following this discussion, I'll also mention that because we're in the UK but most (all?) of those billing services are across the Atlantic, there are serious concerns about legal differences, particularly data protection/privacy rules, and about tax, particularly how VAT is handled. Again, the billing services whose terms and conditions we've checked out had deal-breakers here.
Given that the billing services take a relatively large cut out of the payments, sometimes with terms that don't even guarantee any particular level of service, and that we'd have to implement a whole bunch of things on top of their platform anyway, we concluded that they simply don't offer enough to justify the risks and overheads.
For future reference, you might like to know that there are now regular payment gateway/merchant account combinations where you can use their systems to handle the final part of the transaction so you never even have card numbers on your network, so the PCI DSS issues are moot, at least here in the UK. The lock-in isn't ideal, but as far as I know only Recurly out of the major billing services doesn't effectively lock you in just as badly anyway.
However, we've found that the recurring billing platforms tend to lack precisely the kind of flexibility you mentioned above. We have all kinds of plans to use promotional codes, multiple offerings that users can subscribe to individually or in combination, etc. As far as we can tell, none of the "big name" billing services even gets close to supporting this kind of stuff properly yet.
For the benefit of anyone else following this discussion, I'll also mention that because we're in the UK but most (all?) of those billing services are across the Atlantic, there are serious concerns about legal differences, particularly data protection/privacy rules, and about tax, particularly how VAT is handled. Again, the billing services whose terms and conditions we've checked out had deal-breakers here.
Given that the billing services take a relatively large cut out of the payments, sometimes with terms that don't even guarantee any particular level of service, and that we'd have to implement a whole bunch of things on top of their platform anyway, we concluded that they simply don't offer enough to justify the risks and overheads.
Those are definitely all very good points. Everyone's situation is so different, I'm always hesitate to give any advice as a "prescription" and more of "here's what we did and why we did it so you can decide for yourself".
I'm definitely aware of how easily the new services enable you to entirely avoid the PCI issues. Personally, I'd say that their cut is probably well worth it relative to the time and effort that it takes to build it from scratch. However, that's driven in large part because I'd much rather invest time in the product than worry about the billing details. It's not that it's all that difficult, it's just that it's not the core of what makes Sifter unique.
With regards to promotions and stuff, I'm not a big fan of that. I'm a strong believer in keeping things simple and people either like it enough to pay for it or they don't. I feel that promotions might attract people for the wrong reasons. The more complex the pricing is, the more painful it is to deal with, and it can quickly become a distraction from simply crafting a better product.
Of course, plenty of companies have had great success with promotions, but it's not for us. To each their own, right? Either way, I hope the info helps. Best of luck which ever way ends up working out for you.
I'm definitely aware of how easily the new services enable you to entirely avoid the PCI issues. Personally, I'd say that their cut is probably well worth it relative to the time and effort that it takes to build it from scratch. However, that's driven in large part because I'd much rather invest time in the product than worry about the billing details. It's not that it's all that difficult, it's just that it's not the core of what makes Sifter unique.
With regards to promotions and stuff, I'm not a big fan of that. I'm a strong believer in keeping things simple and people either like it enough to pay for it or they don't. I feel that promotions might attract people for the wrong reasons. The more complex the pricing is, the more painful it is to deal with, and it can quickly become a distraction from simply crafting a better product.
Of course, plenty of companies have had great success with promotions, but it's not for us. To each their own, right? Either way, I hope the info helps. Best of luck which ever way ends up working out for you.
I completely understand your point on wanting to concentrate on the main product and not the billing. That's why we spent such a long time looking into the alternatives, and we would happily outsource that side of things if we could do so with acceptable losses in flexibility.
It's interesting that you don't rate promotions, and I noticed elsewhere in your slides you were fairly negative about ongoing publicity spend. On that we would somewhat agree as well, I think.
The difference is more that we're in something of a niche market, nothing like the stereotype HN fodder that is aiming for the general public as a target audience and low prices. We've done a lot of research into both the global demographics of our market and various potential marketing channels, and it turns out that something as simple (to the customer) as a promotion code can support all kinds of other activities beyond just a generic coupon code promotion, as long as you can implement the right systems for generating and recording those codes behind the scenes.
This is where we felt the simple options offered by the various billing services today just weren't up to the job, and to some extent I'm not sure they ever could be since beyond a certain point I think these policies are always going to be customised to a particular business model.
Anyway, thanks again for sharing the slides. It's useful to know where you were coming from on that particular one because it's the only one where our current approach is clearly different to what you felt had worked for you. Otherwise, your experience is actually quite reassuring, as we had come to many of the same conclusions on your other points and it's nice to know that we aren't completely crazy! :-)
It's interesting that you don't rate promotions, and I noticed elsewhere in your slides you were fairly negative about ongoing publicity spend. On that we would somewhat agree as well, I think.
The difference is more that we're in something of a niche market, nothing like the stereotype HN fodder that is aiming for the general public as a target audience and low prices. We've done a lot of research into both the global demographics of our market and various potential marketing channels, and it turns out that something as simple (to the customer) as a promotion code can support all kinds of other activities beyond just a generic coupon code promotion, as long as you can implement the right systems for generating and recording those codes behind the scenes.
This is where we felt the simple options offered by the various billing services today just weren't up to the job, and to some extent I'm not sure they ever could be since beyond a certain point I think these policies are always going to be customised to a particular business model.
Anyway, thanks again for sharing the slides. It's useful to know where you were coming from on that particular one because it's the only one where our current approach is clearly different to what you felt had worked for you. Otherwise, your experience is actually quite reassuring, as we had come to many of the same conclusions on your other points and it's nice to know that we aren't completely crazy! :-)
I went through picking a payment provider recently as well. I ended up going with Stripe[1]. It is currently in a closed beta, but if you request an account they are activating after around a week of waiting (you could also try emailing them).
Strip is brilliant - I wish I had it 10 years ago instead of dealing with Paypal or banks and merchant accounts
[1] https://stripe.com/
Strip is brilliant - I wish I had it 10 years ago instead of dealing with Paypal or banks and merchant accounts
[1] https://stripe.com/
Hi Garrett. I was at your presentation at Schnitzelconf last year -- if I remember correctly, that was just after you quit your day job to work on Sifter full time. Now one of your biggest concerns back then was availability – first your application's, and then yours, because of the former. You mentioned that you were quite concerned whenever you were away from a computer or even a mobile internet appliance.
You mentioned this concern in the slides, especially at the very end. What's your current situation in this regard, both from the personal (worry, sleep lost etc.) and the technical side (high availability, outsourced admin etc)? And what's your outlook on that for the near future?
This is one of the major benefits of having a "proper" startup, as you can share the load. For a bootstrapped single founder, it's a pretty big issue – or at least it appears to be one (most web apps don't really need five nines – unless it's your web app).
You mentioned this concern in the slides, especially at the very end. What's your current situation in this regard, both from the personal (worry, sleep lost etc.) and the technical side (high availability, outsourced admin etc)? And what's your outlook on that for the near future?
This is one of the major benefits of having a "proper" startup, as you can share the load. For a bootstrapped single founder, it's a pretty big issue – or at least it appears to be one (most web apps don't really need five nines – unless it's your web app).
I generally worry a lot less these days. There are other people involved now as well, including a sys admin on retainer, and it's been a huge change. I'm probably more neurotic about it than most people, and definitely more neurotic than I needed to be.
The reality is that Sifter almost never goes down, and when it does, it's usually something outside of our control and gets resolved fairly quickly by our host. Now that we're in a higher availability environment, that's helping a lot too.
The outlook is pretty great now. It was definitely hard at the beginning, but most of that was self-imposed. Now that I recognize how rarely Sifter does go down or have performance issues, I know that I don't need to worry as much. It was a difficult lesson to learn though.
The reality is that Sifter almost never goes down, and when it does, it's usually something outside of our control and gets resolved fairly quickly by our host. Now that we're in a higher availability environment, that's helping a lot too.
The outlook is pretty great now. It was definitely hard at the beginning, but most of that was self-imposed. Now that I recognize how rarely Sifter does go down or have performance issues, I know that I don't need to worry as much. It was a difficult lesson to learn though.
What is your "higher availability environment"?
According to the blog[1], it's Rackspace.
[1]: http://journal.sifterapp.com/blog/2011/08/sifters-new-hostin...
[1]: http://journal.sifterapp.com/blog/2011/08/sifters-new-hostin...
Great story! Thanks for sharing.
Did you hire any freelancers or interns to get help when you were working alone? I'm considering doing that now to help me with some backend support work, while I focus on the core product. These are little jobs which need to be done to help me move faster.
If you did, do you have any tips or advice?
Did you hire any freelancers or interns to get help when you were working alone? I'm considering doing that now to help me with some backend support work, while I focus on the core product. These are little jobs which need to be done to help me move faster.
If you did, do you have any tips or advice?
We haven't really done much with freelancers. Some of the design work and a little bit of development was outsourced to friends that we already had relationships with. These days we have a sys admin and bookkeeper on retainer so they help a little bit every month, but for the most part, we keep all of the work in house.
I don't really have any tips or advice beyond making sure that you meet people and build the relationships long before you need them. Then, you have people that you trust that you can turn to when you're ready.
I don't really have any tips or advice beyond making sure that you meet people and build the relationships long before you need them. Then, you have people that you trust that you can turn to when you're ready.
If the majority of your revenue was from the small & medium accounts, why not just create a single plan, remove the lower plans entirely? Why continue with the personal plan if that resulted in higher turnover and less desirable customers?
Because the two smallest plans, while having high turnover, have also ultimately generated 65% of our revenue. So at this point, they're still a very important part of our customer base.
As far as only offering one plan, it simply doesn't make sense for us. Our costs go up based on the amount of usage, so it makes sense for the price to go up for customers who use more resources.
As far as only offering one plan, it simply doesn't make sense for us. Our costs go up based on the amount of usage, so it makes sense for the price to go up for customers who use more resources.
There's also a psychological aspect. Although I don't think it's as important on the lower end, as opposed to the people who believe they're actually being somewhat frugal by not choosing the (often mostly superfluous) "deluxe* version.
Thanks for the explanation. This is a great resource. My only regret is that I wasn't there to listen in!
This is worth the read, thanks.
What fraud did you experience?
How did you transition from (presumably) VPS -> whatever -> current high availability hosting. What prompted you to start each transition, "we have enough money to do it" or "we have X, Y and Z problems?"
What fraud did you experience?
How did you transition from (presumably) VPS -> whatever -> current high availability hosting. What prompted you to start each transition, "we have enough money to do it" or "we have X, Y and Z problems?"
The fraud was someone that was using us to validate stolen credit cards. They ran about 100 test transactions before we could lock it down. It took a while because we didn't want to detrimentally affect our customers just to stop it. So, it cost us some money in transaction fees, but beyond that, it wasn't a big deal.
As far as the transitions, it was partially cost and having extra cash and partially just being ready for it based on growing traffic or new functionality. It was never the same set of motivations. Fortunately, we never grew so fast that we didn't have time to scale with the growth. So, it was a combination of "things are slowing down a bit" and "we have the money to take the next step" and "we ought to have a better hosting environment".
As far as the transitions, it was partially cost and having extra cash and partially just being ready for it based on growing traffic or new functionality. It was never the same set of motivations. Fortunately, we never grew so fast that we didn't have time to scale with the growth. So, it was a combination of "things are slowing down a bit" and "we have the money to take the next step" and "we ought to have a better hosting environment".
Which HA environment did you go with?
We went with Rackspace's Cloud Servers. We're using their load balancers with a couple of app servers, a background processing/search indexing server, and 2 database servers for a master/slave setup.
Slide 38 says: "No custom statuses. This one decision defines Sifter."
What does "No custom statuses" mean? Can you please elaborate?
PS: Thanks for sharing. Great slide deck.
What does "No custom statuses" mean? Can you please elaborate?
PS: Thanks for sharing. Great slide deck.
It's a feature within Sifter. Here's a few blog posts that go over the details.
http://journal.sifterapp.com/blog/2007/08/bug-issue-tracking...
http://journal.sifterapp.com/blog/2007/08/tracker-status-com...
http://journal.sifterapp.com/blog/2011/07/resolved-vs-closed...
http://journal.sifterapp.com/blog/2007/08/bug-issue-tracking...
http://journal.sifterapp.com/blog/2007/08/tracker-status-com...
http://journal.sifterapp.com/blog/2011/07/resolved-vs-closed...
My guess is that since Sifter is a bug-tracking app, "no custom statuses" means a user can't provide a custom status for a particular bug--only pre-set options like "Open", "Assigned", "Resolved", etc.
can you tell us more about where you advertised, what the rates and returns were like, and if you used anything to measure ad ROI?
FusionAds, Daring Fireball RSS sponsorhip, RailsCasts, Dribbble, and a variety of other spots. In terms of ROI, we weren't really measuring things in that great of detail. We just used Google Analytics to understand the quality of the traffic.
The rates and returns were all over the board. The only consistent factor was that once Sifter became more well known, the advertising was significantly less effective at generating advertising. So, it's great for finding new traffic and getting the word out, but once that's done, we'd have throw a lot of money at it to see significant results.
The rates and returns were all over the board. The only consistent factor was that once Sifter became more well known, the advertising was significantly less effective at generating advertising. So, it's great for finding new traffic and getting the word out, but once that's done, we'd have throw a lot of money at it to see significant results.
would be very cool if you could do a voice over of the presentation or something like that. nice work man!
I'll give it some thought, but I've always failed miserably at trying to do that. I'm thinking it's easier/more efficient for everyone if focus on answering questions.
it's like reading a slide show of my current life up to about 33% of the way through... I'm starting the next 67% now. I got more questions than you've got time... but..
we're you ever scared of promoting / launching your product in case people thought it wasn't good enough (yet)?
we're you ever scared of promoting / launching your product in case people thought it wasn't good enough (yet)?
Every day. In my mind, it will never be good enough. I've found that the philosophy that has worked best for me is that if you're not embarrassed, you've waited to long to launch. (I believe Matt Mullenweg said that, but I've heard it so many places now, I'm not 100% sure.)
I've been aware of Sifter for a while but it's great to get the inside story.
I particularly liked your point about building features that no-one used - I'm sure it was kinda hard to watch all that hard work go to waste.
You might have covered this in your talk, but which features did you add that you could have omitted? Without having that usage data early on, is there any way you could have done this differently?
Your slides are awesome by the way :)
I particularly liked your point about building features that no-one used - I'm sure it was kinda hard to watch all that hard work go to waste.
You might have covered this in your talk, but which features did you add that you could have omitted? Without having that usage data early on, is there any way you could have done this differently?
Your slides are awesome by the way :)
I don't think that we've added anything that we should have omitted, but I definitely think we added them before we probably should have.
Keep in mind that it really all depends on your goals, and my goals aren't to create a huge app that generates millions but to build something that's pleasant to use and supports me to the point that I can continue to work on it.
That said, I think that we probably should have invested in improving and polishing our existing features before adding source control and email integration. However, I'm sure those have generated a handful new customers that otherwise probably wouldn't have used Sifter. I think they fall into the categories of things that people need when they're evaluating software but that in reality they really don't end up using.
Really, there's so many variables that it's hard to contribute any level of success or failure to one decision. I'm really pretty happy with everything that we have or haven't done to this point. It's just a bit disappointing to pour effort into a feature and find out that it's only being used 2-3% of the time.
Keep in mind that it really all depends on your goals, and my goals aren't to create a huge app that generates millions but to build something that's pleasant to use and supports me to the point that I can continue to work on it.
That said, I think that we probably should have invested in improving and polishing our existing features before adding source control and email integration. However, I'm sure those have generated a handful new customers that otherwise probably wouldn't have used Sifter. I think they fall into the categories of things that people need when they're evaluating software but that in reality they really don't end up using.
Really, there's so many variables that it's hard to contribute any level of success or failure to one decision. I'm really pretty happy with everything that we have or haven't done to this point. It's just a bit disappointing to pour effort into a feature and find out that it's only being used 2-3% of the time.
What made you get into this market in particular? What are your main channels for new customers? What were the biggest lessons on the business and marketing end?
We chose it simply because it was just an area that I'm oddly fascinated by. Our main channel for new customers these days is word-of-mouth referrals.
As far as the biggest lessons, they're all in the slide deck. :)
As far as the biggest lessons, they're all in the slide deck. :)
Thank you so much for posting this. I particularly liked the timeline showing what was going on in your life as you built Sifter.
When you say "run billing daily", I assume you don't actually charge customers daily. What is it that runs every day?
Our billing runs daily and charges each customer once every 30 days based on when they originally signed up for a paying account.
So each night, we bill about 1/30th of our customers. It's not exactly 1/30th because some days have more customers and some have fewer.
So each night, we bill about 1/30th of our customers. It's not exactly 1/30th because some days have more customers and some have fewer.
Some companies do monthly billing runs and then pro-rate new customers (Linode, for example). Others do daily billing runs and charge customers on the anniversary of their signup. The latter can be more challenging in terms of accounting and technology in some cases but has the psychological benefit of money "streaming in" daily.
I interpreted it as each subscriber can be billed on any day of the month as opposed to everyone billed on the first for example. This would help the cash flow.
Cash flow is definitely a big part of it. With daily billing, we never see any huge fluctuations in our account. In my opinion, a slow and steady stream of income is much better than big pop once a month.
[deleted]
[deleted]
awesome slides and presentation Garrett!
Can you share the PDF? The link on SpeakerDeck doesn't work.