"Business" Posts
May 27
Andre
Posted in Business | 
Comments
If you’re running a small company, it’s absolutely key that you have redundant skills on your team.
Does that seem counter-intuitive? Isn’t the typical pairing a business guy and a technical guy? In our experience, you’re far better off with two technical guys.
The redundancy is key if you want to stay lean and also stay sane. You need at least two highly technical guys (or girls). There are two reasons for this:
1. Support
All support issues are technical. We pride ourselves in giving great and prompt support when issues come up, and the best way to do this is to get you connected with the person who wrote the code. That’s us—if you email us with a problem, you’ll get a response directly from one of the people who coded Scout. We believe you shouldn’t have to wade through “Tier 3” support to get to someone who can solve your problem.
2. Vacations
We’re running Scout as a sustainable business for the long haul. In the real world, you take days off, go camping for a long weekend, or take a week off to relax on the beach.
When I’m away, I have 100% confidence that Derek can handle anything that comes up while I’m offline. That wouldn’t be the case if Derek were a business or design guy—I would be on the beach worrying about support issues or checking on our server performance metrics.
Our Takeaway
Our takeaway here at Scout: if you want to run a small business (and enjoy it!), get a partner with redundant skills.
Photo credits: http://www.flickr.com/photos/horiavarlan, http://www.impawards.com
March 11
Derek
Posted in Business | Comments
In 2006, the biggest risk-taker on Wall Street looked like John Paulson. This certainly wasn’t based on Paulson’s past behavior. Paulson managed a middle-of-the pack hedge fund. He made careful, boring deals. He rode the bus and liked to ride his bicycle. In other words, he was the anti-Gordon Gekko.
The risk Paulson was taking? He was betting against the mortgage market using credit default swaps. Insuring $1 million in high-risk mortgages was dirt cheap – around $10,000. If all of the homeowners made their payments, Paulson would be out $10,000. If all of the homeowners defaulted, he would make the entire value of the bundle – $1 million.
For Paulson to make money, these high-risk borrowers needed to default. At the time, most analysts thought that a perfect storm of rising unemployment rates, higher interest rates, and poor local economic health was needed to trigger widespread defaults. However, Paulson’s extensive modeling showed widespread defaults required just one trigger: flatlining home prices. With home appreciation rising at 5 times the rate seen from 1975-2000, there was plenty of room to fall back.
Read more... 
February 19
Derek
Posted in Business | Comments
Bootstrapped tech startups are a lot like restaurants started by quality chefs. It’s easy to find restaurants serving award-winning food that fail. There are lots of self-funded startups started by smart developers that either never launch or die a painful death. Writing quality software – just like serving good food – is the foundation, but it’s not going to make you profitable.
Like chefs who take pride in their food and constantly strive to improve it, developers like us are never done making our software better. There is an unlimited list of things we’d like to improve. Better scheduling and planning won’t shrink the todo list – it’s a leaking todo list that spawns another todo when one is completed.
Read more...
February 10
Andre
Posted in Business | Comments
Instrument your business. It's like instrumenting your code, but profitable.
If you're a developer or a sysadmin, periodic optimization is a fact of life. As more people use your code, you'll see performance issues. Unoptimized use cases bubble up. Systems get strained by continued or heavy use.
On the technical front, there are a lots of instrumentation tools available. We've used ruby-prof, Request Log Analyzer, Scout (of course), MySQL Tuner, httperf, and Rack::Debug. Not to mention low-level tools like top, vmstat, iostat, etc.
The point is this: anything that gets used a lot can be optimized. To optimize you need visibility. To get visibility, you need tools.
Read more...
January 26
Derek
Posted in Business | Comments
Older baseball players typically have plenty of power and discipline but are slow runners with lower batting averages. It’s kind of obvious: as we get older, we get bigger and more patient, but we also get slower. This characteristic even has a name, described as (you guessed it): old player skills.
Bill James, a famous baseball historian, studied these players and found that younger players that start with these skills fade away faster than than their peers. The players that have long careers are often those that have speed when they’re young and are able to adapt as the gifts of youth fade.
What does this have to do with small, self-funded, developer-run businesses like us?
Read more...
November 04
Derek
Posted in Business | Comments
Before Scout, my experience developing software was primarily consulting. Success was measured by delivering software on time and on budget.
With Scout, a subscription-based service, my focus isn’t on scheduling. We are self-funded and we didn’t have the luxury of a venture-backed startup. We’re focused on figuring out which pieces of development work can increase revenue the most. What follows is how we’re approaching it.
Read more...
October 20
Andre
Posted in Business | Comments
Two weeks ago I covered some of the business lessons learned from a large (~3 months) investment in new features, and the hard decision to roll them back. I discussed how you will underestimate the ongoing cost of complexity in your product, and how cool new capabilities don’t sell themselves.
Continuing this week—more insights gained from undoing development work.
Read more...
October 06
Andre
Posted in Business | Comments
We’ve been deleting a lot of code from Scout. We’re ripping out major infrastructure, and in doing so, pulling the plug on functionality which, just six months ago, we believed would be crucial to our business. Most importantly, we’re simplifying the most complex, error-prone, and poorly-performing parts of the application. At the same time, our revenue and sales pipeline is growing at a faster rate.
How did this happen? How did we get to a place where we can remove code and functionality and see our business will grow because of it?
As they say, “mistakes were made.” You don’t get the satisfaction of throwing out a bunch of cruft and performance-degrading features without having gone through the pain of:
- Building those features in the first place.
- Fighting the performance problems for a few months before you realize its all untenable and come up with alternatives.
So yes, mistakes were made. But also, lessons were learned.
Read more...
