
Bootstrapping a Software Product - garrettdimon
http://bootstrapping.sifterapp.com
======
kristofferR
Great slides! I especially enjoyed the "great decisions"/"bad decisions" part,
I catched myself currently doing some of the "bad decisions" - like focusing
too much on short term ups and downs.

Can you share the PDF? The link on SpeakerDeck doesn't work.

~~~
garrettdimon
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.

~~~
kristofferR
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/4e6a452f4932a400010002c0/Refresh2011.pdf)

~~~
garrettdimon
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.

------
jasonmklug
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.

------
garrettdimon
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.

~~~
Silhouette
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.

~~~
garrettdimon
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.

~~~
Silhouette
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.

~~~
garrettdimon
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.

~~~
Silhouette
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! :-)

------
paulmckeever
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 :)

~~~
garrettdimon
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.

------
rgraham
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?

~~~
garrettdimon
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. :)

------
japhyr
Thank you so much for posting this. I particularly liked the timeline showing
what was going on in your life as you built Sifter.

------
endlessvoid94
When you say "run billing daily", I assume you don't actually charge customers
daily. What is it that runs every day?

~~~
siavosh
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.

~~~
garrettdimon
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.

------
helloburin
awesome slides and presentation Garrett!

