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?
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.
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?