Pricing changes incoming

NearlyFreeSpeech.NET was founded with no intention of ever turning a profit. There are no investors to pay off, no debt to service, and no short-term-focused shareholders measuring ROI with three-month horizons. NearlyFreeSpeech.NET exists because I want to provide as many people as possible with affordable hosting free of “big company” restrictions that come from pleasing investors, debtors, and shareholders. Therefore, all the fees we charge are designed to cover the costs of the resources it takes to provide the service.

One of the things we are running into with our pricing model is that the resource-based pricing we currently use doesn’t take everything into account, and doesn’t always do so accurately. That’s something we need to address.

For example, the price for storage is problematic, because it’s a machine resource we can measure, whereas CPU and RAM are (currently) not. It’s not that this charge is too high, as people sometimes like to use apples-to-oranges comparisons to claim, it’s that it’s improperly apportioned. People with large, static websites pay too much and people with small, CPU-intensive websites pay too little. This is a measurement problem more than anything, and it’s one we’ll address over time as we roll out the “arbitrary server process” technology that’s been under development for so long.

However, although that’s a good example, we have a more immediate problem that is not only keeping us from solving it but also gaining significance as we continue to grow. In addition to CPU and RAM, there is another hugely expensive resource that we are not recovering costs for: people. Since we are small organization that is very efficient and low-overhead, this comes in two forms: member support, which scales with the number of members we have, and system administration, which scales with the volume of services we provide.

Our service was designed with no “human” cost component because, at that time, I was the only person involved and I didn’t get paid. Support was intended to be limited to helping members when the system was broken, or with things that our system prevents them from doing themselves, and the service was priced accordingly. However, that was a long time ago. Now we have reached a point where over 50% (and approaching 75%) of our support requests do not fit the original design: they are from people who want to pay our prices but still get unlimited technical support and assistance. And we have to pay people to handle them. On average, each support request costs us $3.30, so that’s just not sustainable.

On the system administration front, our members (rightfully) expect us to provide a server environment that is carefully monitored, ruthlessly secured, relentlessly kept up to date, continually enhanced with new features, and where even the smallest performance and downtime problems are detected and responded to immediately by experts 365×24. But, despite that expectation, our members do not pay us to do so because here again, the prices were designed back in 2002 when I was the only person involved.

Therefore, as with support, the now-immense costs associated with system administration go unrecovered. Unlike support, the consequence is that we’re seriously understaffed in this area, and every NearlyFreeSpeech.NET member has in some way or another felt the repercussions: downtime, suboptimal performance, and endlessly delayed new features. As we continue to grow and the workload increases, the rate at which our list of unfinished to-dos expands simply accelerates. That, too, is unsustainable.

In order to properly staff NearlyFreeSpeech.NET to the level where we can provide the quality of service and support that our members expect, and get research and development of the new features everybody wants off of the 0-2-hours-a-week back burner, we need to start recovering an average of $2.50 more per member per month.

We’re going to do that, and we’re going to do it very, very soon. The only question is how we go about it. We want to be very careful not to repeat our storage pricing mistake: we want to apportion costs among our members as fairly and accurately as possible in proportion to their resource usage. That means imposing at least two new charge structures, one for support and one for system administration.

That’s because a whole lot of our members never use support at all. We strongly feel that they should not have to subsidize the other extreme: people who submit “high” priority support requests in the middle of the night demanding that we answer questions they could have just as easily found in our FAQ. So, what we’re leaning toward is a three-tier membership model:

– A “basic” membership, which carries no monthly charge but has no included support eligibility. Support requests can be submitted at normal or low priority for a $3.30 charge.

– A “standard” membership, which has a $1.00/month charge and includes one support request at normal or low priority per quarter. Additional support requests can be submitted at any priority for a $3.00 charge.

– A “premium” membership, which has a $2.50/month charge and includes one support request per month. Additional support requests can be submitted at any priority for a $2.50 charge.

In addition to support requests, our forum will remain free-to-post and we plan to implement a system to compensate the dedicated forum participants who we recognize are volunteering their time to make our service better by helping out their fellow members.

On the other hand, every single member needs us to have sufficient system administration resources to keep things running. The best plan we’ve come up with so far is to consider the “objects” that form a person’s services. As we define it, each of these is one object:

– one web site
– DNS for a single domain
– one MySQL process
– email forwarding for one domain

We’re considering applying a one-cent-per-day-per-object system administration surcharge to each account. The average member has 5 objects, so that would be an increase of about $1.50/month to them. That seems pretty reasonable in exchange for ensuring that we have the staff needed to keep an important website secure and available. But for people who need to squeeze out the maximum hosting-per-penny, it’ll still be possible to host a site in our domain (or with 3rd party DNS) that uses SQLite and limit the system administration surcharge to one penny per day.

Neither of these plans are finalized, but we’re moving rapidly in that direction. I’m posting this now for two reasons. First, because we’re committed to transparency in a way that nobody else can touch, and that demands we do so. Second, because we want to get as much constructive, helpful feedback as we can about how we can fairly distribute these costs over our member base.

Threats to cancel if we do (or don’t do) XYZ will be ignored. Simple economics dictates that any increase in prices will decrease demand; we already know that whatever we do will cause some people to stop using our service.

Some people may genuinely not be able to afford any increase; to those who are not able to rearrange their usage under whatever plan we come up with to reach a cost structure they can afford, we apologize that we are likewise not able to afford continuing to subsidize them. But we expect the loudest complaints to come from a small subset of members who voraciously consume our time and feel entitled to do so for free. This latter group is essentially strangling our business, so although converting such people to have sustainable, success-aligned goals (where they and we both gain) is our first choice, eliminating them as members if they are unwilling to cooperate is an inferior but acceptable alternative.

Likewise, exhortations not to change anything “because its fine the way it is” will also go unheeded, because it is not fine the way it is. We are not happy with the system quality we are able to deliver at current levels, so our options are to raise prices for the people incurring the costs or start zeroing in on members that we lose money on and terminating them, just like a lot of web hosts already do. And if that’s not enough to convince you, head over the the feature voting page and take a look at how far behind we are.

NearlyFreeSpeech.NET is not on the precipice of doom or anything; we balance our checkbook at the end of every month without going into the red, just like we’ve always done, and there is usually money left over for pizza. That, by us, is success. But we can see that if we don’t take corrective action, the quality of our service will inch downward until it reaches a threshold of “it’s cheap, but it sucks” that we’re not willing to approach, let alone cross. Knowing that we need to do something, the responsible approach is to do it as soon and as well as we can. So here we are.

Currently, we have to draw money out of our service and hardware budget to pay our human costs. With these changes, human costs will be paid for by the new charges instead. If things turn out the way we expect, we plan to use part of what that frees up from existing revenues to accelerate our service buildout (software and hardware) and we plan to return part in the form of reduced costs on some of our services. But first, we have to see things turn out the way we expect. So the changes outlined above aren’t intended to be the final word on the subject: things will get a bit more expensive, and then they should get a bit cheaper again.

As I said at the beginning, NearlyFreeSpeech.NET is not designed to turn a profit, its fee structure is designed to recover the costs of providing the service in the most fair and straightforward manner. That will remain true, even as we make the necessary adjustment to include the human cost in our fee structure. “As cheap as possible, but no cheaper.”

Thanks for your time, for being a member of NearlyFreeSpeech.NET, and, I hope, for your valuable feedback as we contemplate the best way to implement this change together.

We want the response to this to be a discussion, and blog comments don’t allow the easy quoting and attribution needed to facilitate that — I cringe every time I have to edit someone’s comment to add a response — so we are closing comments on the blog post and directing follow-ups to this thread in our discussion forum. That discussion is going to move fast, decisions will be made quickly, and changes will follow sooner rather than later. So if you want to be heard, now is the time.

Update

Based on the feedback we have received, we have made several significant changes to the plan. A summary is presented here for people who don’t want to read the whole discussion thread. This is getting close to being finalized, but is not yet set in stone, so please feel free to provide additional feedback. We would like to announce the final plan to all members via email sometime around the weekend, if possible.

Pricing Changes

Support Pricing

With this change, most support will be provided through the use of “support points,” which can be purchased in increments of 10 for $5. Unused support points do not expire and can be “sold back” when a membership is closed.

Submitting a support request will require you to have at least 1 support point. Each response you receive will be assigned a cost from 0 to 10 support points based on the time and complexity of the request, as determined by us, which will be deducted from your support points balance. If your support request requires multiple responses (e.g. back-and-forth exchanges), each response from us may carry a separate point cost. If you run out of support points, open tickets will be suspended until you add more, and new ones will not be able to be created.

Certain requests will default to zero points until they are implemented as features in the UI. These include:

– SSH key management
– Your first IP access control modification in a given week
– Chowning files from the “web” user to your site UID.
– asset transfers between members/accounts
– Canceling membership

We plan to implement “stub” features in the UI to open tickets for these types of requests without the need to obtain support points. If additional help is needed with such a request (such as troubleshooting a non-working ssh key), we may assign point costs as appropriate to cover our involvement.

The option to mark a request as “high” priority will be available. This will require 2 support points during our business day and 5 points at other times. This is a way to bump your request to the front of the line. While we frequently respond to “high” priority requests submitted outside business hours, we cannot guarantee any specific response time, only that they will be handled no later than first the following day.

To prevent people from having to pay a fee to report problems, we will implement a “problem report” option that will allow opening a ticket even if zero support points are available. To minimize misuse, our responses to such will be minimal, possibly stock answers, unless we need more information. In cases where misuse is a recurring problem, we reserve the right to block individual members from submitting problem reports. We intend to treat problem reports as high priority requests unless the rate of false positives proves problematic for us.

The estimated effective date for new support charges is August 1st – 15th.

Hosting Pricing Changes

Our new table of hosting service fees will be as follows:

– Bandwidth – $1/GB “or less” (existing sliding scale)
– Storage – $0.01/megabyte-month*
– Web Sites – $0.01/day/site
– First MySQL process – $0.02/day
– Additional MySQL process – $0.03/day
– InnoDB MySQL – $0.01/day/process
– DNS service – $0.01/day/zone
– RespectMyPrivacy – $0.01/day/domain
– Email Forwarding – $0.03/day/domain
– Domain Registration – $8.59/domain/year

Two discounts will be available when this change takes effect.

With respect to DNS, if the domain is registered with us or if www.(domain) is pointed at a site hosted here, then the DNS object pricing will be cut by a factor of 3 ($0.01/3-days). If both apply, then the DNS object pricing will be cut by a factor of 9 ($0.01/9-days). (This is a bit of a conscious effort on our part to reward people who are using our DNS and domain registration the way we intend — with our hosting.)

With respect to the per-site charge, sites using the currently-experimental “static content” site type will be exempt from the fee, as we will be handling those sites in a way that requires significantly less overall maintenance on our part.

*It is our intention to reduce storage pricing and add a “workload” billing factor to account for CPU/RAM resources used. It is our intention that this change will be revenue-neutral with the current storage charge but will more accurately apportion the machine costs of providing the service between individual sites. Specifics and timeframe are TBD.

The estimated effective date for new hosting charges is September 1st – October 1st.

No Comments yet

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.