Archive for August, 2007
We closed our first round of funding without giving up any equity as we mentioned in our last post, “why sell a profitable website?” After the sale, our company is financially set for at least awhile, so what did we learn? We learned why everyone says getting funding and closing the deal is so hard. In the end, we think it was worth all the trouble but that doesn’t change the difficulties of closing a deal.
“In the startup world, closing is not what deals do. What deals do is fall through. If you’re starting a startup you would do well to remember that.”
– Paul Graham
Selling an asset turns out to be very much like the way Paul Graham describes getting VC or angel investments. It takes a lot of time and work. In the end, we were in and out of talks to sell our site for over three months before we had a check in hand. The deal almost fell through multiple times, in which case not only do we not get the investment, we lose all the time we spent pursuing this deal. That is a scary thought when you’re a bootstrapping startup.
The point Paul Graham makes is that the negotiation never stops until the closing. This hit close to some of our struggles with completing this deal. After a verbal agreement was made, we wanted nothing more than getting back to full time work on our new product Seekler. In fact for awhile we stopped taking on new advertising contracts (not wanting them to complicate the terms of the sale agreement) which turned out to be a mistake, wasting time and losing out on additional revenue. Unfortunately, as some delays to closing came up we realized we needed to make some final improvements on the old website to close the deal. In the last few weeks we put more time and focus back into the old site – increasing traffic, fixing bugs, pursuing additional revenue streams (renewing contracts we had been delaying), and improving the site’s visibility on search engines. After this push to really hit the value of the deal home, we found the legal documents getting pushed around quickly to finish everything up. We learned not to delay any contracts, revenue, or slow down the development until you have a fully signed legally binding deal in hand.
With ink on a few pieces of paper, Pretheory has at least jumped from small losses to a funded start up. We are risking a small but steady income for the chance at solving a far larger and more interesting problem at Seekler – collecting and sorting the world’s opinions on everything.
It isn’t time to start celebrating (Pretheory doesn’t have assured success yet) but we have closed our first round of funding. The best part of us closing this deal is that we got to keep all our equity and secure funding that should ensure a beta release. After our beta release, it is likely we might have to start seeking funding again if we see the chance for rapid growth. That said, it is nice to know that our company will have enough money to at least bring the initial version of our vision to the market.
How does a startup acquiring funding without giving up equity? We didn’t take loans, beg family, or empty our retirement accounts (although up to this point, we have been self funded from our savings). Instead, we sold a small website that we have been slowly making money from for awhile. We found a company that was interested in growing and expanding in that market. So we sold the asset for the revenue it would make over a couple years to get access to that money now.
Since we started, Pretheory has run a older website because it made us a profit. When we began negotiations for selling the site, many people questioned our motivation to sell a small and profitable website that takes relatively little time to manage. In a future post we will explain about negotiating and closing the deal. Here we will focus on why we sold our site in the first place.
The site didn’t take much time to manage, but did require more task switching. If your trying to keep an entire program in your head, it becomes much harder when you have to switch to another task for 30 minutes a day. Task switching can hurt your productivity even more when the time of the switch isn’t always in your control. Sometimes meetings about the site, traffic spikes, or interviews would occur in the middle of the day. Many problems that arise on a site need to be dealt with quickly. Being able to properly focus on a problem is a major gain for a small team that already has to work on many different tasks infrastructure, marketing, application code, and others.
Selling the site also makes sense for us financially right now. The site does make money, but not enough to maintain a company. If we want to succeed as a company we need to focus on something with a larger potential profit. If we could make a decent amount of money from this site, but it would take years to amass a significant sum. There are many advantages to selling the site to get access to the majority of that amount now. We have costs related to developing and releasing our new product Seekler, and getting the funding to get it to market the way we would like as soon as we can could be a huge advantage. The financial growth of the old site was rather limited, even if we worked to expand the site’s offerings, while our new product has a far larger market potential.
While it might seem scary to give up our only current source of income, you can’t create the future when you’re holding on to the past.
As anyone starting a website knows, picking a domain name is a very time-intensive and difficult task. We spent a ton of time to come up with both Pretheory and Seekler.
While we were in the process of trying to come up with Seekler, we stumbled across PickyDomains. The idea is that you submit the key concepts you want in your domain name as well as any specific restrictions you have (e.g. whether you want hyphens or not). Then users can suggest names. If you like one, you let them know, and then you are free to go buy it.
In our case, PickyDomains didn’t actually give us any names we liked. This may have been because we spent so much time working on names before we tried PickyDomains, so we had already considered a lot of the word combinations that were suggested. It did however, give us some good ideas. Often we would run through the list of names and then start brainstorming from there, which would often result in some better names.
Even though PickyDomains didn’t produce a name for us, I would recommend it to anyone. Why? Well, first of all, it’s only $50. So even if there is a small chance that you will get a great name, it’s such a small amount of money it’s worth giving it a short. Even better – it’s risk free. If you don’t end up picking one of the suggested names, you can easily get your money back. At the very least, it’ll give you some free ideas that you can use to kickstart the creative process, and at the very best, you might get a great name at a bargain price.
We know this blog has needed some usability and design attention for a long time. We finally decided to put a little bit of work into it. We are trying to keep this blog as simple and easy to read as possible. So, the biggest change is that we are now using more clear, larger, and easier to read fonts. The fonts along with a few splashes of color hopefully give the blog a much nicer look. Let us know what you think, any suggestions are welcome.
Lately, we’ve been working on getting Capistrano set up so we can have easy, predictable deployments. If you’re not using Capistrano (or some other automated deployment solution), I highly suggest looking into it. It’s a no-brainer like automated tests or source control management. However, if you’re not using it, this post won’t be of any interest to you – it’s simply a little gotcha that we ran into.
One component of Capistrano that you need to provide is a so-called spinner script. This is the script that actually starts your app. In our case, it starts a Mongrel cluster like so:
./script/process/spawner -a 127.0.0.1 -p 8000 -i 3
This starts three instances of Mongrel (on ports 8000,8001, and 8002) and binds them to localhost.
When we would run Capistrano, we would see the following output:
* executing `deploy:start'
* executing "sh -c 'cd /var/www/seekler/current && nohup script/spin'"
But the actual Mongrel servers would not be running (i.e.
ps aux | grep mongrel showed nothing). We would ssh into the server as the Capistrano user and run the same command and everything would work fine. Huh?
The problem turned out to be that spawner calls
mongrel_rails (the program that actually starts the Mongrel instances) and that program was not in the PATH when Capistrano executed this code (although it was the in PATH if we remotely logged in and ran the spin script manually. Sudo on Debian can play some weird tricks with your PATH).
Compounding the problem was that the spawner code silently fails if it can’t find
mongrel_rails – which made it much harder to diagnose the issue.
We solved the problem by creating a symbolic link to
mongrel_rails into /usr/local/bin
ln -s /var/lib/gems/1.8/bin/mongrel_rails /usr/local/bin
and then everything worked.
However, your PATH may be different. To find out, temporarily edit spawner.rb (the path on my machine was /var/lib/gems/1.8/gems/rails-1.2.3/lib/commands/process/spawner.rb) and add the following line at the beginning
system('env') # DON'T LEAVE THIS IN! REMOVE WHEN YOU FIGURE THE PATH OUT!
That will print out all the environment variables as the script is run, including the PATH. Then you can create a symlink to
mongrel_rails in the appropriate directory.
Hope that helps!
So you’re having a problem with your computer, eh? Yes, you’re right, I do know something about computers and yes, I was a computer science major. Will I fix your problem?
I’ll certainly try. I’m more than happy to help you to the best of my ability. You’re a friend and I’m glad I can help you. I know you’d do the same for me and in all likelihood, I’ll be hitting you up for free financial/legal/medical/automotive advice in the near future. I happen to have an area of expertise and I genuinely don’t mind helping you out.
That said, here’s some friendly advice that will make this experience as painless as possible for both you and me:
1. I probably don’t know the answer off the top of my head. So please don’t get annoyed if I can’t answer your question if we happen to be at a bar, driving around town, or anywhere else I’m away from my computer. You may be surprised to discover that my first step will almost certainly be searching Google. My only real skill in this situation is that I have enough domain knowledge to follow the directions I find on Google.
2. Speaking of Google, I’d really appreciate it if you would try searching before you ask me. I get a lot of computer-related questions, and it’s somewhat aggravating when the answer to your question comes up on the first page of search results. Don’t spend all day, but take five minutes and do a search. If you happen to find your answer, you’ll save us both time, and you might even learn something cool that you’ll be able to apply in the future.
3. If Google doesn’t solve your problem, feel free to ask me. However, please understand that it’s nearly impossible to diagnose a large percentage of problems over the phone or through email. I know you feel like you’ve described your problem adequately, but it’s actually very difficult to accurately describe a computer problem if you’re not exactly sure what to look for.
4. If I drop by to work on your computer, please don’t talk to me the entire time. I know you’re just being polite, but your problem is likely somewhat tricky and I need to concentrate. I almost certainly have never run into your particular problem before, and if I have, it’s not something I fix every day. That means that I’m probably going to need to read up on the issue, and my reading comprehension goes down the toilet when you start telling me about your weekend.
5. However, if you feel like bringing me a drink or a snack, that would be very much appreciated.
6. Please be realistic about the time it will takes to fix the issue. This isn’t the movies – I’m not going to type super-fast for thirty seconds and fix everything. I need to figure out the issue and then work on a solution. It might take half an hour or even an hour. So please don’t invite me over when you have to be somewhere in twenty minutes.
7. If it does take longer than you expected, please don’t repeatedly apologize about taking up my time or ask me to stop because “it’s taking too long.” I really do appreciate your concern, but this doesn’t help at all. First of all, I had a pretty good idea of how long it would take before I came by and I scheduled my time accordingly. Secondly, by the time you say this I’m probably already engaged in the problem and I hate nothing more than leaving problems unsolved. I’ll let you know when I get fed up and decide to quit, but until then, let me be the judge of whether I’ve done enough.
8. On the other hand, please be realistic about my time. If I tell you I can’t fix it in any realistic amount of time, don’t guilt me. If it’s going to take three hours to fix, guess what – I have stuff to do. There are people who get paid good money to fix complex issues like this, and I’m not one of them.
9. If I can’t fix it, comments like “I thought you knew computers” really don’t help. I know the software I use i.e. mostly Unix programming tools, not desktop publishing software written for Windows 98. There’s a lot of software out there and I know the intricate details of a very small percentage of it.
10. Here’s another unhelpful comment: “I thought you majored in computer science.” Computer science is not about fixing computers. It’s much closer to math than it is to tech support.
11. Finally, and most importantly – don’t keep rebuilding your house in a flood zone. If I get done solving your problem, please listen and follow any advice I have for preventing the issue in the future. Nothing is more annoying than solving the same problem over and over, especially if it can easily be avoided. In college I recovered at least three papers for a girl who lived next door. Every time I told her she needed to install anti-virus software, and every time she ignored me. I’m happy to help, but everyone’s altruism has limits.
Sounds pretty reasonable, right? Great. So what seems to be the problem?
UPDATE: Thanks everyone for all the feedback! There’s also a discussion going on at programming.reddit.com if you’re interested.
Our deepest apologies for the lack of posts, but we’ve been busy:
1. We picked a logo
2. We picked a graphic designer and we’re starting to work on the site design
3. We’ve launched seekler.com!
Admittedly, it’s not much right now, but you can see our logo and read the first public announcement of what exactly this grand secret project is all about.
Over the next month or so, we’ll be going into more detail about Seekler on this blog. We’d definitely love to hear your feedback, so keep checking this space!