CheddarGetter appropriately representing the sliced cheese area at MicroConf.
Ringing the Bell
UPDATE: The NYSE Facebook contest is experiencing technical difficulties and is unavailable for voting. We will update this page when they are back up. Thanks for all the votes so far.
We’re excited to announce that we made it to the final round of voting in Startup America’s contest to ring the opening bell of the New York Stock Exchange! CheddarGetter is one of five finalists in the Startup America contest.
So please:
- Visit the NYSE facebook page
- “Like” the page
- Then vote for CheddarGetter!
We’d love to show the world that we have a blossoming tech community here in the Midwest.
A video plea:
Why we want to ring the bell:
If we have the chance to ring the bell, our customers and friends in the web startup community will enjoy a moment of recognition for their tireless hours spent after work at their day jobs, in garages and dorm rooms and coffee houses across the country. CheddarGetter is a scrappy web startup from the middle of the country. We are growing organically, and are proudly profitable at our small size. We’re building a technology company in the corn belt, and are able to employ college graduates that may have otherwise moved to the coasts.
Our story:
CheddarGetter was built in 2009 as a billing tool for tech incubator SproutBox’s portfolio companies, which are primarily SaaS startups. In the years since, we’ve launched to the public and grown to service hundreds of web startup customers across the globe. We are still focused primarily on internet startups, and our company culture revolves around agility, innovation, and fun.
So please, like the NYSE page, then vote for CheddarGetter!
http://chdrgtr.com/CG-NYSE
Thanks everyone!
CheddarGetter Live: Bloomington Playwrights’ Project Blizzard 2012
(Source: vimeo.com)
Fondue
Now CheddarGetter can automatically post in Campfire chat when stuff happens in CheddarGetter! We’re calling it Fondue because why wouldn’t we.
How Does It Work?
When the Campfire service hook is enabled, CheddarGetter immediately sends a success message to your Campfire room.
Then, as events occur, CheddarGetter sends messages to Campfire when:
- A new customer is created in CheddarGetter
- A customer’s subscribed pricing plan is changed
- A customer’s subscription is canceled in CheddarGetter
- A customer’s subscription is reactivated in CheddarGetter
BONUS
We included a bunch of little easter eggs in this integration, so you’ll get some positive reinforcement any time a new customer signs up.
We’ve been beta testing it here for a while now, and it has proven to be a sound prescription for little bits of joy.
Set It Up
To get up and running, visit our new Web Hooks section of your Configuration.
You’ll need to know your Campfire Subdomain, Campfire Room ID, and Campfire API Authentication Token, which you can find in your Campfire account under the “My Info” link.
Enjoy the smell of hot cheese!
Customer Spotlight: OSHAtrac
This month’s Customer Spotlight has a special place in my heart. OSHAtrac is a SaaS company that makes keeping track of OSHA reporting easy. As a former manager of a fairly large restaurant kitchen, I only wish this was available back in the 90s. OSHA is an agency that kitchen managers love to hate. They serve a very important purpose, but it can be frustrating to try to remember all of the regulations in the course of busy operations.
What does it do?
OSHAtrac enables employers to create accident reports, track injuries, print required OSHA documents, and view injury metrics in real-time. It’s super-easy to use, affordable, and assists employers with compliance for federal OSHA reporting requirements.
A big thank you to OSHAtrac for using CheddarGetter for nearly two years now. And thanks for providing an awesome service to an underserved market niche.
Want to be in the spotlight?
If you’re using CheddarGetter for SaaS billing, email me at adam@cheddargetter.com and let me know about your company. Each month I’ll pick one awesome customer to spotlight on the blog and our twitter feed.
The only way to overcome the near complete disregard of most display advertising is to create ads that are visually different from the page they are on, intrinsically interesting, and relevant.
The doctor ad above is our best performer.
Also, keep your color and aesthetic consistent to develop brand recognition.
What happened today?
On January 11, 2012, CheddarGetter was unavailable beginning at around 17:03 UTC. This unprecedented and unexpected downtime lasted for approximately 2.25 hours.
No data was lost, and no payments will be lost. Now that we are back up, our system automatically processes the payments that were due to be processed during that period.
But during that time no data was able to be added. This is a big deal, because it means that new customers were not able to sign up during that time (among other things). We know how frustrating this was for you because your businesses rely on CheddarGetter just like ours does.
What’s next: This problem will not happen again; it has been fixed. We are working to ensure that other things like this will not happen, and are committed to keeping events like today’s black swan notable for their rarity. This means working to eliminate this single point of failure as soon as possible.
I’m not sure how much it helps, but we are very sorry.
The gory technical details:
An unexpected first responder, Papertrail, landed a notification in the team’s inboxes at approximately 17:03 UTC. The message contained an alert explaining that 112 icky log messages occurred on our web servers in the 10 seconds prior to the notification being sent. In other words, thanks to Papertrail, we were aware of the problem almost immediately. Moments later, an annoying number of beeps, buzzers, and bells began sounding off ad nauseum.
The really annoying part was that the only information we had to go on was desperately vague. Those of you with PHP experience might be familiar with the error message: “PHP Fatal error: Exception thrown without a stack frame in Unknown on line 0”. Lovely. That almost always means that we threw an exception from an object constructor. You can’t do that. Now, on to tracking it down with that as a starting point. We had another error that came along with the infamous “Unknown on line 0”: “PHP Warning: Unknown: Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/lib/php5) in Unknown on line 0”. Ok, so that actually helps a little, right? Wrong. More on that later.
First thought: any boneheaded deployments recently? Nope, no deployments at all within 23 hours.
Second thought: problems saving session? Hmm… that’d be odd. Ok, we’re using Memcached for session storage so let’s check that out. Using telnet try a simple set. Success. Try a simple get. Success. Damn. One of the most frustrating parts of troubleshooting a problem like this is desiring failure and not getting it. Memcached is really solid so no surprise there.
Third through fifty-seventh thought: grasping at straws around the idea of “Failed to write session data”. This included some line-by-line “Hello World” nonsense. Grr…
What we found here was that the problem was actually related to a DB connection failure during auth.
In walks an intern who says: “Is there anything I can do that wont cause you to punch me in the face?”
CEO: “Hmm, probably not but we’re getting close to finding the cause. It appears to be database connection related.”
Intern: “Did Rackspace reboot anything recently?”
CEO: “Not that we’re aware of.” [Checks uptime on db server]. “Damn, this server’s been rebooted.” [Checks DB connection from web head]. “DB connection is hanging from web1”. [sudo iptables -F]. Ding, ding, ding!!!
So, not quite a perfect storm but, as usual, multiple actions worked together to cause and sustain this downtime. A quick check of the inbox showed a notification from Rackspace regarding a server reboot. Since RS had to force power cycle the offending server, our live iptables rules were not saved (i.e., “post-down iptables-save -c > /etc/iptables.rules” did not fire). Unfortunately the most recent saved ruleset did not include an allow for the web heads. Upon reboot, no connectivity.
Also very common, a well meaning dev tried to be clever about detecting db connection failure and report a nice error message. Unfortunately that included throwing an exception “without a stack frame”. So instead of the nice, well-thought-out error message, we had what we had here today.
Five Guidelines for Pitching Bloggers
As a follow-up to my “Wrong Way to Talk to Bloggers” post, here is a list of things you should keep in mind when reaching out to bloggers:
- Know who you’re talking to.
- It’s a marathon not a sprint.
- Stroke the ego, but don’t ingratiate yourself.
- Don’t bullshit.
- Make it easy.
Plus 6 Tips that will make it easier
1. Know who you’re talking to.
This seems like a no-brainer, but it’s sadly the exception rather than the rule. The best way to do this is to follow the blogger you want to reach out to for a few weeks before actually emailing them. Subscribe to their blog and their twitter feed. Read what they write. Get to know them. Read their bio and about page. That way when you finally do want to reach out and pitch them a story, you won’t make any dumb mistakes like calling them by the wrong name, or mentioning a post they didn’t even write.
2. Blogger outreach is a marathon, not a sprint.
TechCrunch, Mashable, and ReadWriteWeb get hundreds of pitches every week. The better option is to reach out to lower and middle level bloggers who would be excited to cover your new product, rather than begging the top dogs to give you a side glance. This is the same theory that many of my friends use when seeking investors: don’t pitch to investors just because they’re the most visible, instead try to find investors that are as passionate about your industry as you are. You shouldn’t really have to do much selling at all.
Blogger outreach is the same way. There are hundreds of thousands of blogs. Why go after blogs with the broadest reach? Instead, reach out to blogs with the narrowest niche audience that aligns closest with your target market, then branch out and up from there. Make a hierarchical list of target blogs starting with the most niche and expanding to the least niche but in your market. Set a goal to reach out to a certain number every month, or every quarter. Don’t do it all at once or you’ll risk overexposure amongst overlapping audiences and bloggers who read each other.
There are tools out there like BlogDash that supposedly make outreach easier, but I haven’t used them and can’t recommend one over another. I just use good ol Google and Twitter.
3. Gently stroke the ego, but don’t degrade yourself.
Your goal in the first email is to make the blogger feel important and valuable. This should not be hard, considering the fact that they are inherently both of those things if you’re taking the time to write them a personal email. They have the power in this situation, and you should acknowledge that without ingratiating yourself like a hungry dog.
Good Example: Your little markup explainer was useful, considering I just started switching from XHTML to HTML5.
Bad Example: Your posts are so clearly written and wonderful! I absolutely loved the way you explained the new HTML5 tags! Genius! Are you single?
4. Don’t bullshit. Be honest.
When you’re in launch mode, you are so excited about your new product that it’s easy to forget how other people see it. Don’t make a bunch of crazy claims about what your product can do, or how disruptive it is, or how it is going to be the next X except better. Just talk about who it is for, and what problem it solves for those people. That’s it. This paragraph should only be a couple sentences long, and focus on value not features.
5. Ask for something.
Many pitch emails are just open-ended rambling about the product. Have a clear action that you want the blogger to take, but don’t be pushy. If you want them to write about you, say so. Give them reasons to do so. Give them ways to do so, and ideas to make it easy for them. If you want to buy an ad, say so. Tell them how much you’re willing to pay, and what you expect in return. Be clear and straightforward in your ask, and you will save yourself and the blogger a lot of time and frustration. But this is not the time for convincing them of the importance of your product, or the great “exposure” they might get from talking about your thing. That’s a deal-breaker!
Tips
- Use RSS to keep track of the bloggers in your industry.
- If you can afford it, offer to buy an ad. In the rest of the media world, advertisers get written about first. It’s just the way it works.
- Sweeten the deal. Offer free accounts for them and 10 of their readers, or a discount for all of their readers. Offer to wash their car. Offer to buy them a car.
- Don’t reach out until you’re really ready for users. It’s tempting to want to spread the word as soon as you reach MVP, but that could be a recipe for disaster. Visitors will stumble over bugs, and all the outreach work you did could be for naught. If possible, wait until you’ve tested with an alpha group for a couple months before advertising.
- Keep it simple, keep it short. My rule of thumb: If you have to scroll to read the whole email, it’s too long. Keep it short enough to fit above the fold.
- Go overboard. If you have time, make a short video for every single blogger you reach out to and post it on Vimeo or Youtube with password protection. This guy Max Yoder did this with great success. It takes a certain personality to pull this off, but it’s proven to be effective. Video in general is a much more personal way to talk to people. If you can, do it.
In conclusion: be honest, be grateful, and be nice. And have something worth writing about.
Thanks for reading,
Adam @Quirk
Before you go, here’s an important question:
One Time Transactions? …. Yup.
With CheddarGetter you can initiate one-time transactions.
The CheddarGetter team is focused on creating the most user-friendly, adaptable billing system out there. We know that as an entrepreneur, you need options and flexibility, especially when it comes to billing your clients. That’s why we allow you to offer one time transactions and recurring billing plans simultaneously. We’re giving you the ability to mix and match any way you please.
For example, let’s say that you run a SaaS company which offers subscription plans, billing your customers on a monthly basis. You’ve just added some new features, and you want to charge customers for these outside of their subscription plan. You can set up a one time transaction to charge for the additional feature at any time. The client is charged immediately, in real time, and their credit card information is stored for the next time they purchase from you. In the meantime, we keep up on the dunning management so you don’t have to worry about failed transactions due to expired cards.
Whether you want to charge for overage or add-ons, offer a la carte pricing or subscription based plans, CheddarGetter has a solution for your business.
Why Not Build My Own Billing System?
I was recently talking to a friend in NYC who is getting ready to launch what should be an awesome online photo service. He was considering CheddarGetter, and we had a few email exchanges and one in-person meeting to talk it through.
At the end of the day, he and his partners decided against us, and would instead build their own billing system.
I’m no salesman, so I didn’t push him too hard to change his mind. Especially since I know him well, and could tell that his mind is already well past changing. However, I did want to leave him with some things to consider, and what better place to do so than a public blog‽ (← interrobang)
These are the reasons that all startups should consider using us (or any 3rd party billing system) instead of rolling their own.
1. Go-to market delay
You’re in the heady days of a pre-launch startup, you’re most likely spending long hours writing code, trying to get bizdev deals, and focusing on getting the MVP out the door and into the wild world wide web.
Most times this includes farming out certain tasks and systems to professionals who have already mastered it:
- Most startups use some form of cloud hosting these days, instead of building their own web server from scratch.
- Most startups use some form of CMS for the marketing site, instead of building their own from scratch.
- Most startups use some form of blogging platform for their blog, instead of building their own from scratch.
- The pattern continues even deeper for bootstrapped startups, who regularly use 3rd party unit testing and email delivery.
But for some reason, a significant number of startups decide to build their own billing system. Thus delaying launch, stealing focus from their core product offering, and teeing up a bunch of possible problems down the road. Like…
2. High cost of ownership
Maintaining an active billing system is difficult (trust us!). Crap hits the fan. Your developer team is going to spend time fixing little bugs with the billing system when they should be focused on developing.
3. Inflexible, short-sighted structure
Our product is awesome, let’s charge people for it! How about we keep things easy and just make a simple monthly package? $20 a month? Yeah, we can build that.
One year later:
- Hey, what should we charge for this new offering?
- What about that promotion we wanted to run for RWW readers?
- Can we track usage so we can upsell our power-users?
- I think we need to do a free trial and then control access when the trial expires.
Good thing we went with a recurring billing system that handles all that crap for us!
Derp!
Ok, I’m convinced. So why choose CheddarGetter?
CheddarGetter is Fast, Inexpensive, Flexible, and Knows Billing
And here are a few more reasons:
Embedded Gateway means better pricing and easier setup.
Our CheddarGateway is included in our pricing, and the configuration is integrated within the CheddarGetter setup process. Save time and money! Act now! Supplies limited! Seriously, this is big.
Great Customer Service
Our support is second to none. Ask any of our customers.
Easy Merchant Account Approval for US Customers
Our partners at Gravity Payments in Seattle are the best in the business. If you have a startup that needs to accept credit card payments, you should talk to them. During the setup process, if you need a merchant account, you just fill out this form (requires login) and our partners at Gravity Payments will walk you through it step by step.
Merchant account not required.
Can’t get a merchant account in your country? Use our Paypal or Website Payments Pro recurring billing integration. Simple.
10+ years of recurring billing experience. $100’s of millions billed.
Did you know that our founder Marc has been building billing systems for over 10 years? He built an online rent-payment system for multi-family housing (apartments) in 2001 and scaled it to process over $3 Million of transactions per month. None of our competitors know the intricacies of online recurring billing better than us. Numbers don’t lie.
You can almost guarantee that our billing architecture will be better than whatever you come up with in-house. That’s not hyperbole, it’s just logic. We’ve been doing this for a while now, and have been proven successful. Your team is probably awesome at something else.
So why take the risk?
