four bean soup

Every wanted to just jump in feet first and get an app launched? We have! We’ve even done it before in the past, with railsrumble, and we tried to do it again a few weeks ago.

How did we fare? Let’s explore the goals first and then how we did.

Goals

We had an overall task list of 10 things for 2 of us to complete. We hired a babysitter to watch the kids from 10am to 6pm while we focused on working. Our major goals included:

1. Write a node.js/mongoDB download tracker (beancounter) for webpulp.tv
2. Get a working prototype of honeysquares
3. Launch webpulp.tv
4. Redesign tweethopper completely to accommodate changing UI needs.

Know your tools

I said this in a talk I gave about winning the Rails Rumble in 2007, knowing your tools can make a huge difference. Final Cut, Node.js, and MongoDB all had steep learning curves.

Wendy took on the task of editing the videos while I worked on the node.js tracker. In the end, it turned out to be much more of a collaboration on the video editing, as it took both of us tinkering to get things right and we still feel like n00bs. I am glad she took the lead on this, because I was having trouble wrapping my head around node.js.

Choosing node.js and mongoDB for beancounter was probably a real downfall for getting this task done, but something about node.js strikes a cord in me - it feels like the rails community circa 2004. Documentation and example code bases seem hard to come by. The MVC frameworks built around node.js are all a bit newish without many leading contenders. I am getting the hang of it thanks to @atmos.

Just get it working…

Do the simplest thing possible and iterator on working code later. After I made the decision to move forward without beancounter for the first episode, my next order of business was to get a prototype of honeysquares up. I spent about 35 minutes writing the models/db structure/migrations and another hour getting the controllers and js all hooked up. As I deployed and played with the app I tweaked it, but it still lacks an actual UI for now.

Seeing an idea come to fruition can be a very powerful motivator, no matter how basic.

20/20

In hindsight, techniques like time boxing might have made sense when playing with new technology. We are still pretty happy with the results of our “launch week”, we finished 50% of our todo list with our small team of two!

We now have small wins to build on and we’ve cleared our plates to keep working on the new tweethopper design.

We’ve been serving up incremental updates to Tweet hopper recently. A major focus of the work has been on increasing test coverage, but I wanted to give everyone an update on bug fixes and tasty new features that have been added as well.

Tasty New Features

• We added a free account!
• We now track and show the reason for a disabled twitter account, currently we pass the string straight from twitter’s response.
• We’ve updated the look and function of the twitter account edit page, focusing more on job types.
• The wording on the twitter account edit page has been improved, part of a larger ongoing in-line documentation process.

Squishy Bug Fixes

• Fixed the bit.ly “ERROR” that was being inserted instead of the shortened url. Also switched to is.gd for failover if bit.ly isn’t working.
• Twitter accounts are now sorted alphabetically in the index.
• Ensure dm-tweets are sorted oldest to newest so we post the oldest outstanding direct message first.
• We added monitoring for RabbitMQ to ensure the job queue stays up.

As far as the eye can see

We really love to hear from the people that use tweet hopper every day and would be ecstatic if you could give us your suggestions. We have several exciting ideas brewing, including new job types, oAuth support, and much more!

What’s going on at Tweethopper? Who is Tweethopper?

Has your account been deactivated and you’re wondering why? A month ago we sent out an email that said we would be transitioning to a paid application business model in order to have the time and money to improve this app. We got a lot of emails about this transition and thought it would be a great idea to shed some light on who we are and how this change will help.

Tweethopper is owned and operated by a family business called Four Bean Soup. When I say family business I do mean family business. There’s myself, Josh Owens, and my wife, Wendy and our 3 kids. Since our kids are ages 5, 4, and 1 they are more there for inspiration. I do all the work on Tweethopper myself and have struggled to find the time and money to keep it going. We launched this app about a year and a half ago and have been supporting in and nurturing it ourselves, hoping to make it into something that people would find enough benefit to pay for.

We welcome any suggestion you might have, and because of the feedback we’ve received we are introducing a free plan as well. I hope you will help us grow tweethopper into something amazing. In case you missed the email about switching to a paid plan the info is here.

Thanks, Josh, Wendy and the kids :)

We recently relaunched tweet hopper, as it is now owned and operated by four bean soup. The relaunch is part of our effort to build a profitable company that can sustain our family (my four beans…) while offering a great product with solid customer service.

As some of you may have noticed if you tried to sign up in the last week or so, it wasn’t working. I have one reason why: Paypal. We initially signed up for their Website Payments Pro offering, the same one we used while running my previous business, Handcrafted. After two weeks of testing, we launched and everything was going smoothly after we worked out a few bugs.

An ominous fore-warning

A friend of mine happen to IM me on the 18th and we chatted about getting tweet hopper launched, the Paypal setup process, and some other business related stuff. He sent me this link about a Paypal horror story and warned me to be careful about relying on Paypal. Low and behold, the very next morning I received an email at 7am from Paypal saying they suspended the account and they need more business details, on a Saturday to boot.

A startup’s worst fear, realized

Not sure what to do, I logged in immediately and started sending them the docs they requested. They wanted silly things like my list of suppliers, even thought it is a purely digital service I offer. They asked for:

• Driver’s licenses
• Social security cards
• Bank statements
• Sales policies
• Refund policies

The timing couldn’t have been worse, we were rushing around that morning to head out to an all day Nutcracker event for my oldest daughter. I quickly got them all the docs before we left and spent the 45 minute car ride on the phone with customer service. They finally said they needed time to review all the documents, I should hear back in 24 hours.

The 24 hours came and went, so I called customer service back. They reviewed the documents on the phone with me and lifted the restrictions on the spot! I was so happy that I could put it all behind me. Then I logged in and saw the Website Payments Pro was still gone. I called customer service back again and asked about my payment processing, they said I needed to reapply for it and they got the ball rolling, but it would take another 24 hours. I waited patiently, actually thinking it would all be ok because we used Website Payments Pro at Handcrafted with no issues.

23 hours later I received an email informing me I was too high risk and my previous approval was being denied. When I called customer service they informed me the virtual terminal department doesn’t take phone calls, I would have to email them. I did, a half hour later I got the same denial letter sent back to me. When I emailed a third time they added a note saying there was nothing that could be done before parroting the denial again.

Spreedly FTW!

A mere two days before Christmas, we were left with no options for a gateway and we weren’t sure how to proceed. Luckily we made the decision to use Spreedly before launch and we had some options for a new gateway - namely First Data. Nathaniel from Spreedly had recommended First Data, so I gave them a call. They sent over paperwork for me to fill out, but they couldn’t start processing it until the Monday after Christmas, what a bummer!

I sent them all the info right away and waited to hear back. The whole process was slow and tedious compared to Paypal, but we finally got the approval and account setup after two weeks.

Whoops, wrong account type

After I was up and running, I realized I need their API not their virtual terminal product. After a bunch of emails back and forth and a couple more calls to customer service, we finally had what we needed! I quickly plugged it into Spreedly and gave my credit card a live test - it worked!

The moral of this story: Steer clear of Paypal!

I think there are three important lessons that we learned as a business:

1. Never be stuck relying on PayPal without a backup plan
2. Ask for personal recommendations
3. Use Spreedly to get gateway flexibility

I really can’t say enough about #3, to make the change, we didn’t modify any code. We just logged into Spreedly and added a gateway and switched all the card types to use it. Previously charged cards that were handled under paypal will now be handled under First Data for next months charges!

The other day, we took tweet hopper down for some unexpected maintenance. I just wanted to take a minute to talk about what we did and why it had to happen.

Server additions

Since we changed out all our hardware when we switch from Handcrafted to Four Bean Soup, we didn’t have the need for the same shared resources as before. All our linode servers are now solely dedicated to tweet hopper, we moved from six shared servers down to three dedicated boxes.

Three servers proved to work ok, but once we got some started getting stats, it wasn’t what we were used to serving up to customers. We try to keep most page loads under 200ms and a YSlow score of 80+. We were averaging a few seconds for page loads, as you can see in this graph below.

The unexpected downtime came about because I didn’t realize how slow the service was running. I knew it wasn’t up to par with what we offered before, but I didn’t have any insight into real metrics. The morning the service went down was the morning New Relic finally released a version that supported Unicorn for stat tracking. We immediately set to work installing a dedicated mysql server and put it into service at the first real slow time in the EST time zone - usually we shoot for midnight, same this time.

The results are spot on with what we wanted out of the upgrade. Our page load times dropped to 85ms on average, with some spikes hitting 150ms. If anyone is looking for a good mysql config, we used Evan Weaver’s 512mb vps setup. We will continue to use New Relic’s rpm service to monitor and find slow spots in our app, we love it!