In this type of transaction both parties end up achieving their goal going into things. The seller wants to sell, and the buyer wants to buy. Both parties likely disagree with the potential of the product.
With that in mind, a question for the buyer - What do you understand about the business that the seller doesn't that makes this seem worth while? And for the seller - What aspect of the business makes it a target for sale rather than growth?
> What do you understand about the business that the seller doesn't that makes this seem worth while?
We were guessing that the seller was getting too busy running his day job at Drip to devote enough time to Codetree. It seemed reasonable because we'd been following Drip via Rob Walling's podcast and blog for years and Drip sounded like it was doing well.
We'd been in a similar spot with a previous business we sold. A seller may want to sell for a variety of reason, not just because the business is destined for failure.
But broadly, we think the PM market is huge, GitHub is huge and seems as good a partner as you could want given the platform risk, if "Software is eating the world" is true (we think it is) then the # of devs is only going to increase and they're going to need tools. And we're devs and love serving devs. So it was a good fit.
The bottom line for me was time and focus. If I had more hours in the day, I would have kept Codetree and grown it. My other business Drip was experiencing crazy growth and Codetree had always been a side business, taking the back seat to the needs of Drip. At the time of sale, I had at least 50 different feature ideas/growth opportunities written down but very little time to implement them. Rather than watch the product slowly fade away, the next best outcome for me was to see someone else realize that potential.
One size certainly does not fit all, however, my one take away is that this is huge benefit to paying close attention to what works best for you and optimizing your life around that. When you focus on productivity and happiness (often the 2 are linked) ignoring, when possible, schedules dictated upon you your quality of life will improve.
Valid feedback, not an excuse, but we drafted this with a lawyer ages ago and haven't had the funds to properly revise. That said - it's not an excuse, and I have nothing to say but we're sorry. It was an launch oversight.
We will look to revise this to get rid of the yucky stuff. Lawyers can't be that expensive :/
That said, you can opt out of all emails, and we obviously the link stuff is just dumb and not enforceable.
We're currently running an all javascript (coffeescript) stack. In the backend we have a variety of node.js servers. We have the following "types" of servers:
- Metagame: handles our web api requests
- Game: handles all the game logic, on the server. no client side game logic. Because we're all JS - client is effectively open-source.
- Notification: routes messages and notifications to the users, utilizes 0mq between servers.
- Matchmaker: takes in requests for game searches, keeps requests in memory, and finds matches.
- Overseer: orchestrates where all the servers live. Want to know the address of a server? talk to the overseerer. Need to spin up a new game server? Overseerer.
- League: Handles league management.
We currently have physical 6 servers (2 metagame, 2 game, 2 for the others). The metagame mixes web-sockets and standard web requests. The game server is web-socket only. These are the only two servers that talk to the clients. All other servers just network between themselves.
The Metagame, and Game server are fronted by nginx which acts as a reverse proxy, does ssl termination, caching policies, etc.
All our assets (images, etc) are stored on Amazon Cloudfront, and cached forever. All filenames encode the MD5 signature of the file to ensure that we can cache everything forever, speeding up the clients.
We were also accepted into the Rackspace (http://www.rackspace.com/) startup program which provides us a lot of free servers for a year. While we don't need all 6 servers right now, we can test out the infrastructure and launch this way, allowing us scale up easier. Free for a year was a good reason to move away from AWS - where we previously resided.
We went with nodejs - largely because of the "fun" factor. When we started we didn't have a ton of familiarity with it, but we wanted something different, and node had a lot of buzz at that time. While writing it in C, Java, or Erlang would of been more in our wheelhouse, we knew this was a hobby project and wanted to learn something new and enjoy ourself. It turned out to be a good choice, node is great. It performs well, and is a joy to work with. I've always felt that server side performance just needs to be good enough, you can optimize and optimize and optimize, but at the end of the day your stack needs to be architected such that it can run on 100s of computers at a time. You can only run with 1 server for so long, so creating something is scalable in hardware is more important then squeezing a single server for all it's worth. Node, combined my 0mq (for us) makes this a snap. My 2 cents anyhow.
Mongo was chosen for a similar reason. It has nice aspects to it, and is a great compliment to an all JS system. For us, we're not query heavy so it was a good choice. That said, as we add features, I can see partitioning our data into mongo data and more traditional RDBMS data. Mongo is good for certain classes of data, but you need to know what you're getting into.
If you'd like me to talk to anything else, let me know.
Love the product, and while the grandfather'd pricing is nice - it only lasts for 6 months. If we were to continue using it past these 6 months Intercom would cost, on a monthly basis, more than our servers and other add-on services we already pay for combined. Pricing based on active users might make sense if your ARPU is high enough, at which point it's just a question of return, but at lower ARPU's it simply prices itself out of the equation - at least for us.
As someone who has been working for the better part of 2 years on a browser-based game, I hope your predictions come true. In particular I've found the blending of what's expected in typical web-apps and how games function to bo some of the more interesting benefits of approaching development from this angle.
The ability to seamlessly persist game state across devices is a powerful construct that really enables you to play everywhere. While being a simply useful mechanism, it also really helps users stay mentally engaged in the game experience if they can access it at any time. This fact builds upon itself if they can do so in small bite-sized chunks.
Additionally, the ease of acquisition of such games (we're using a DOM based approach, however, Canvas also applies here) is also a big win. We've seen our game gain tremendous traction in various offices where people wouldn't normally play games as you a) don't need to install anything and b) can play in 30 second intervals.
These two unique factors combined gives you a devious means to provide compelling game experiences regardless of where you and what type of computer you have access to.
With that in mind, a question for the buyer - What do you understand about the business that the seller doesn't that makes this seem worth while? And for the seller - What aspect of the business makes it a target for sale rather than growth?