Bootstrapping a Software Product
bootstrapping.sifterapp.com
bootstrapping.sifterapp.com
Can you share the PDF? The link on SpeakerDeck doesn't work.
https://speakerd.s3.amazonaws.com/presentations/4e6a452f4932...
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.
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.
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.
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.
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.
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! :-)
Strip is brilliant - I wish I had it 10 years ago instead of dealing with Paypal or banks and merchant accounts
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).
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.
[1]: http://journal.sifterapp.com/blog/2011/08/sifters-new-hostin...
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?
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.
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.
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?"
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".
What does "No custom statuses" mean? Can you please elaborate?
PS: Thanks for sharing. Great slide deck.
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...
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.
we're you ever scared of promoting / launching your product in case people thought it wasn't good enough (yet)?
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 :)
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.
As far as the biggest lessons, they're all in the slide deck. :)
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.