HN user

stympy

16 karma

AKA Benjamin Curtis, co-founder of Honeybadger.io.

https://www.honeybadger.io/ https://www.packagebot.com/ https://www.bencurtis.com/

Posts8
Comments40
View on HN

We did a private beta when launching Honeybadger.io, and it worked really well. We reached out to people we knew who would be good customers, had them go through the same signup flow we planned to use after launch, and had them enter payment information and get billed (so we could test everything). We offered these first customers a special, low-priced plan as a thank-you for helping us test the product.

I think it would be fine to do manual invoicing for this group of customers if you don't have your credit card processing in place yet. These first customers should be ones who will understand that they are testing, so not everything will work. On the flip side, though, you should be prepared to offer them excellent service, responding quickly to any issues they encounter. These customers can become a great source for referrals for additional customers if you treat them well, so treat them well. :)

You can use honeybadger.io (I’m a cofounder) to catch your exceptions and link the lines in the stacktrace to the corresponding file in the Github UI.

Since you have nothing in place at the moment, I recommend you get something in place while you are evaluating your options.

At honeybadger.io we use papertrail for log monitoring, and we love it, but there are plenty of hosted options. Set up a free trial and you'll at least get aggregation and monitoring now, plus an idea of what kind of logging volume you'll need to support with your self-hosted solution.

We are using Elixir/Cowboy at https://www.honeybadger.io to receive log drain data from our customers' Heroku apps. It's reliable and fast, but deployment has been a sort point (we're spoiled by Capistrano). I recently changed the deployment to elasticbeanstalk with the multiple docker image approach, and that has been much nicer.

The ecosystem is still young -- a lot like Rails was in the early days -- so there are rough edges, but I'm betting they will get sorted out, just like they did in Rails land.

Our preferred deployment method at Honeybadger is to (almost) always merge to master before deploying. We will deploy a feature branch when we want it to be a little easier to rollback to a known good state (by deploying master) for changes that we are nervous about. Those deployments are rare, though, as we have an almost-production environment (it talks to all the production services, but no customers use it) for doing one last smoke test before unleashing code on customers. :)

True, but still doable. I have a family, full-time job, and two side startups (5 and 4 years old), but I still manage to work out regularly, spend time with the family, relax a bit, and even sleep. You can do it, you just need to use your time wisely.

I had a project recently that had requirements similar to what you are describing, and I went with s3 + zencoder, and it worked wonderfully. This was my first time working with zencoder, but I've used s3 a lot.

What I did is send movie uploads directly to s3 via swfupload so my Rails app isn't tied up with uploads. When the upload is done I use a JS callback to set the location of the uploaded file (bucket and path) in a hidden field that gets set in the ActiveRecord model when the form is submitted. If that attribute is present at creation time, a call is made to zencoder to start the encode. Then I use flowplayer to show the encoded videos.

It's a straightforward implementation, and it works well. I've been pleased as punch with zencoder, and I'd definitely recommend them. You might also want to look at http://www.pandastream.com/ ... it looks like a great alternative, but zencoder's pricing was a better match for this project.

Be aware there can be a cost difference if you want to provide SSL to your users. A wildcard SSL cert to cover *.app.com will cost you $200/year, whereas a standard SSL cert to cover just app.com will cost you $20/year.

I personally prefer subdomains, but I agree that people are generally comfortable with whatever approach you take.