And now, the expenses begin...

[jducoeur]

Yesterday, Aaron and I bought the server hosting for CommYou. We're starting modestly, of course, with a single machine that should take us through alpha. But it does make everything much realer: we're now putting several hundred dollars a month on my Visa card for the server. And that'll only go up, frighteningly quickly. One reason why we're going to have to figure out how to bring in some reasonable income quickly is that we could easily wind up spending a couple hundred thousand on the eventual server farm if we're successful. (I saw the numbers for Facebook yesterday: they are currently running roughly thirteen *thousand* servers. Intimidating.)

The scariest part of the CommYou project is a very simple question: can we make money at it? This isn't a cute hobbyist project, it's intended as a serious, if modest business. And the odd advantage of doing it ourselves is that we can't lie about the money. Most serious startups take a million or three from venture capitalists, which gives them the luxury of pretending that the income doesn't matter much. But in our case, we're going to have to be in the black pretty much by the time we release the system, because we can't afford to scale it up otherwise.

The flip side, of course, is that we don't have to make nearly as *much* money as a VC-backed company eventually needs to, which will hopefully shield me from having to make some of the moral compromises that they often do. Those "free" Internet companies always have strings attached: since they're pretending not to make money, they often have to be kind of underhanded in how they actually do so. (Which is where you wind up with things like the ill-fated Facebook Beacon project, which tried to share your purchasing data.) I'm hoping we can do this the way I like to do things: being very upfront and honest about it.

But we'll see. The Internet is awfully addicted to "free", and people don't like being confronted with the harsh reality that this stuff is never *actually* free to run -- somebody's paying for it. The question is, what is the best and most honest way to get a modest contribution from each user, so that we can run the thing...

Comments

[oakleaf-mirror.livejournal.com]

You've probably already considered this, but just in case...

As you've mentioned, a large part of your target market is conditioned to expect some level of "free" service. If you require up-front payment, you'll likely turn away a significant portion of them before they even take a close look. It seems you'll want to go some combination of two main ways - either a free trial period (by person) where they can explore what you're offering without having to pay anything, followed by a subscription model if they want to keep using it, or a two tiered service where you offer something useful for "free" and something nifty for money. The later is not unlike LJ's options. The risk is where you draw the line.

[mindways]

Yeah. Heck, I *know* it takes resources to offer these sorts of things, and I still tend to want a free level of service - usually in the "try before you buy" sense, a la Flickr.

(Flickr's actually very clever about their free service - not so much about what they disable (or don't), though those decisions are generally good, but because of the "200 pictures in photostream" limitation. By the time most users hit that limit, they've been using the service for a little while, so it provides a...the right word isn't coming, so I'll just say critical event - a line-has-been-crossed event which causes the user to revisit the notion of paying for the service. which they wouldn't do right off but now might because they're involved enough with it.)

[jducoeur]

That's a good plan, although I don't love it for CommYou -- hard limits feel a bit arbitrary to me. My current theory is that the ad-serving system is going to have a good deal of intelligence, so that light users see essentially none and heavy users see some, along with the occasional "Want to get rid of these ads? Subscribe now -- it's cheap and easy, and supports the service." We'll see how that works...

[jducoeur]

I confess, I'm rather philosophically biased against the part-"free" model, at least for the reasons espoused by Brad in the early days of LJ. It's very much built on the notion of "producers" and "consumers" of content, on the theory that you have the free accounts to make the "producers" happy. But as far as I'm concerned, this society I'm trying to create is a pretty level one, and I don't really distinguish between these two classes. (This reflects the fact that CommYou is a bit more oriented towards conversation, and less towards broadcast, than LJ.)

That said, we'll see what's practical. There will in all likelihood be mild Gmail-style advertising from pretty early on (for non-subscribers); we'll see if that brings in enough money to be worthwhile. The current theory, yet to be tested, is that the advertising will be set up so that casual users essentially never hit it, and heavy users hit it occasionally -- that's similar to the "free trial period", but instead biased based on usage, which is what really matters from a cost POV. The notion is that, if you're using the system a bunch, you either get some ads or you pay for a subscription.

There may well be additional features for subscribers -- again, I rather intensely dislike that on philosophical grounds (I would rather that everybody have access to all features), but it might be necessary to have such come-ons. There are a few specific and unusual things which might be subscriber-only -- for example, the sort of high-frequency API access that costs a lot to run (and really can't have any ads) but may be useful for building mondo-powerful clients.

Lots of experimentation is called for, I suspect. Out of the entire system, this is probably the area where I am least sure of where it will wind up going...

[siderea]

Something you may have already thought of, but in case you haven't:

If you're doing anything at all right, the interest this will pull is going to ramp very hard and fast. You will not have time to plan/shop once it starts. I recommend, if at all possible, have your server-growth plan -- and written -- complete to one million users, so you (or someone you hire, and tell, "here, read this") can just execute the decisions.

If your product fills as much of a niche as you think, you have as much to fear from being swamped with interest as anything else (q.v. Zip drives).

[alexx-kay.livejournal.com]

See also many multiplayer computer game launches. The classic form of the mistake is as follows:
* Build capacity for X simultaneous players.
* Print Y copies of the game, where Y >> X.
* Be an instant hit, and immediately have congestion issues, leading to bad press and poorer-than-optimal player retention.

It seems intuitively obvious to *me* that one shouldn't make it possible to sell more than X copies on day one, but lots of otherwise smart companies have made this error. If you build in some mechanism that lets you put limits the rate of growth (such as LJ used to have with the invite mechanism), then you can mostly avoid this problem.

On the flip side, being able to grow too *fast* risks you miscalculating when demand peaks, and then sitting on a bunch of capacity that you can't sell. (Lots of notable examples here from comic book publishing and CCGs.)

[jducoeur]

Yep. It's also a standard set of risks on the Internet-startup side, enough so to almost be a cliche. Pretty much no matter how much I plan, I'm guaranteed to have *some* kind of scaling problems (it's a complex and subtle issue), but I'm giving it a fair amount of thought and sweat now...

[jducoeur]

Oh, I'm well aware of that. I can't say the scaling plan is as detailed as I would like yet, but it's well in process: I'm already starting to plan how memcached is going to fit into the equation, and thinking through the horrible compromises I'll have to make to the DB structure in order to make it scale. I'm fairly sure I have a little while before that becomes relevant -- the initial release really is just a toy, and I don't think it's going to get serious uptake yet -- but I'm working on the assumption that at some fairly unpredictable point in the next 3-6 months, scaling is suddenly going to completely swamp all other concerns for a time.

That said, one serious problem I have is that I have no damned idea what the real load issues are going to be with one million users -- I have guesses, but nothing more. Hence, I actively want to get about a thousand users in the not-terribly-distant future (a month or two), so I can figure out the reality of the loads involved, and get the planning dead-right.

One thing I am actively keeping in my back pocket is the possibility of locking things down for a time, taking no new users until we can cope. This is actually very common for Internet startups, to have large but strictly limited betas, for precisely this reason. I don't at all *like* the idea of doing that -- it'll cause some medium-term social issues, and will probably cost us some medium-term growth -- but I'm quite prepared to do it rather than collapse under the load if things suddenly go exponential.

But of course, this is also why I care so passionately about getting the monetization right from the beginning. It's Just Plain Impossible for us to scale if we don't have the income for it, because the costs involved could easily put us out of business, very quickly. Indeed, the scaling moment is the time when we are likeliest to take money, because we may simply have no choice, but the better we're doing at being self-supporting, the less of the company we'll have to sell to do that...

[siderea]

On the plus side, schemes like invite codes seem in their way to drive adoption by making the code seem like a valuable and coveted resource. Artificial scarcity can be good marketing.

[jducoeur]

Yaas. I'm slightly leery of traditional invite codes simply because they're a bunch of work to implement properly, and because they warp the social fabric somewhat weirdly, but it's an option I'm keeping in the back of my brain. (Not least because it's a *great* way to get free publicity from TechCrunch. One of the standard rackets is to give TC a hundred invite codes, which tends to get Mike Arrington to write about you...)

[cellio]

You're building a social site. Would you rather have (to pull a number out of thin air) 100,000 singleton users, or 100,000 users in clumps of friends who already know each other? Invite codes can help if the answer is the latter. (LJ did invite codes way back; don't know if you were around back then.)

[jducoeur]

They *can* work that way, but it has to be set up right. Keep in mind that there are a variety of ways that invite-code schemes work, and not all of them are as well designed for fomenting the social network.

We'll see. *If* I do invite codes, it needs to be done right. I'm pondering the option fairly carefully, not least because this discussion has gotten me thinking about it...

[alexx-kay.livejournal.com]

I actively want to get about a thousand users ... so I can figure out the reality of the loads involved, and get the planning dead-right.

Extrapolating from a thousand to a million will get you a much better guess. But it's likely to still be quite a distance from "dead-right".

[jducoeur]

Fair enough. But it'll give me enough data to be a *lot* more confident in my guesses than I am now...

[qarylla.livejournal.com]

Most the sites that I use (and am willing to pay for) have a certain small proportion of their services free, but if you want to do more there is a free.

Initially I paid for LJ for the extra icons. I paid for Typepad after the one month free trial was over (and after a lot of spam issues with hosting my own Moveable Type on f2o). I have a wiki that I'm not paying for, because it was largely an experiment (for learning about wikis). Etc. The most successful services for me had either a free trial that was at least 2 weeks long or offered something extra for a small monthly or yearly fee.

[jducoeur]

Hmm. Useful food for thought. As I mention in another comment in this thread, we may well have something similar, although more oriented towards free for casual users and ads or subscription for heavy ones, rather than a trial period per se...

[cellio]

My experience is similar. On LJ I started with a free account, moved to a paid account to get access to the faster servers (that was a key point of difference in 2001), and, after using it for several months, bought a permanent account in the next offering. I would have kept the paid account otherwise, but half a year was enough for me to see that I would want to use this for a long time, so the permanent account was both supporting a site I liked with a cash infusion and cheaper for me in the long run.

I've bought accounts at a couple other sites that offered a limited free version that was not time-bound. In general, I don't do well with the fixed-length trial period; I want to use a tool or service naturally, not under the gun, and evaluate it that way (This isn't online, but: one of the reasons I haven't signed up for NetFlix yet is that when I get reminded the next two weeks aren't a good time for the trial, and when it's a good time for the trial I don't remember to sign up for it. If, instead of a 14-day free trial, it were N free/cheap rentals over the course of a couple months, I'd be all over that.)

[jducoeur]

In general, I don't do well with the fixed-length trial period; I want to use a tool or service naturally, not under the gun, and evaluate it that way

I think that's natural, and it's why I'm currently planning a fairly phased approach involving ads in the middle. Truly casual users won't see any ads -- that is, the first conversation or three you read in a session won't show any. If you start reading more deeply than that, there will be occasional ad inserts when the client deems it plausible that we can serve out an ad that might be interesting and relevant. And occasionally, instead of an ad, it'll serve out a, "Want to get rid of the ads? Subscribe today: it's cheap and easy, and helps support the service".

That seems like a reasonably phased approach. We'll see if it brings in enough money (and whether it's as easy to implement as I hope), but the hope is that it's gentle enough to not turn people off while quietly encouraging them to subscribe...

[serakit.livejournal.com]

Advertising?

[jducoeur]

In the plans, but I'm being deliberately both cagey and cautious about it. I am convinced that having a *lot* of advertising is counter-productive: people simply tune it out. And there is ample evidence that spewing advertising inside social networks just plain doesn't work, and the amount of money you can get for serving those ads is *pitifully* small.

That being the case, I'm focusing on the Gmail model, which is one of the few places where *I* actually tend to notice the ads sometimes. The current theory is that non-subscribers will see *occasional* ads, rather than frequent ones -- still not annoyingly obtrusive, but more visually distinctive than they would be if they were always there.

Also like Gmail, the ads will probably be contextual, related to what's being talked about. This should, in theory, make it more likely that the ads will be relevant and useful, and in turn improves the odds that people might actually click on them occasionally. The amount of money I get per click is *vastly* higher than the amount I get for simply showing the ad -- on the order of a hundred to a thousand times as much.

So the theory is that, by showing far fewer but more useful ads, I get the best chance of a bit of money, while minimizing the annoyance factor. We'll see if that theory is correct...

[sichling.livejournal.com]

Have you looked at the possibility of using Amazon Web Services for hosting/dealing with CommYou? I'm not sure if it would make sense and don't have a good feel for how the numbers would work out in comparison.

Figuring out a decent business model to make money is hard :-(
Does trying something with Google-style ads mingle in decently? They, at least, have the affiliates program which might make it easier to do some basic monetization.

[jducoeur]

I *believe* that AWS, like the Google Engine, is non-relational. Given the nature of the data, that's a bit tricky to design around, so I think it's unlikely. And I don't love the likely effect on latency. Refreshes are going to be super-frequent here, so I'm looking at much more frequent, much smaller hits on the server. Systems like AWS are somewhat better-suited to more traditional web pages, with occasional heavy hits. So a good memcached architecture is likely to matter more to me.

Also, my impression is that the cloud-based services aren't that great a deal once you get up to scale, and it's very hard to break away from them. (All the analysts agree that this is why Google is getting into this particular racket and offering it cheap or free at the low end: when you get big, they make pots of money, and the lock-in effect is very strong.)

Does trying something with Google-style ads mingle in decently?

Yep -- that's explicitly part of the initial theory. Gmail is my best model for advertising that doesn't *totally* suck (not too obtrusive, but useful and smart enough to occasionally be worth clicking through), and I'll likely have a modicum of such for non-subscribers.

There are scads of unanswered questions, especially with relation to how much I can expect from a privacy-protection POV and how good the context-sensitivity is for affiliate ads. But I'm working under the assumption that I can at least run some Google ads for some conversations without betraying my users...

[sichling.livejournal.com]

Ah, so there is a difference between using Amazon's EC2, which is basically just a virtual machine that runs Linux, and buying in totally to their database and storage. Granted, you do need some type of permanent storage and there are the bandwidth charges.

At the same time, the flexibility of testing it/throwing it out there with larger scale when needed and getting multiple geographic areas for reliability might be interesting.

I wouldn't suggest it, necessarily, at scale, b/c if you think about the hour charges and so on, it may get absurd - but to start?

Anyhow, I've learned a bit about AWS, if you do get interested.

What Google is offering is a bit different, tied as it is into the services more and without offering the access to the compute platform (as I understand it).

[jducoeur]

Anyhow, I've learned a bit about AWS, if you do get interested.

I'll give it some thought -- thanks. I'm concerned about finding myself locked into an architecture that I can't "bring home" easily, and the amount of work involved might be prohibitive (since the system is deeply based on Hibernate right now, switching to something that isn't a conventional RDBMS may be tricky). But it's worth pondering, especially since we may find ourselves labor-constrained when trying to scale up...

EC2 and storage

[metageek.livejournal.com]

Amazon has said that they're working on providing persistent storage for EC2. (At present, anything you store on EC2 is lost when the instance shuts down.) The plan is to make it available as a raw block device, so that you can run any filesystem, or database, you want.

[lecil.livejournal.com]

There seem to be two ways to start a company:

Start with a PANT LOAD of VC, and hope the spagetti sticks.

Start with very little capital, work your pants off because this is your *house* financing the venture, and with a little luck, lots of sweat, you have a going concern before too long.

I suspect the second business plan is likely work better in most circumstances. Congrats on taking the server plunge, and good luck!!! Let me know if you need a beta-tester who is still trying to figure out what Twitter is all about... :}

[jducoeur]

Thanks -- we'll be looking for people to start actively playing with the thing and telling me where it sucks in the not-terribly-distant future...