Our campaign to find subscribers to support our service was successful, with about 3,000 of the existing "free private" project owners buying subscriptions for their teams.    Thank you very much.

We delivered on our promise to staff a full-time customer service operation.  So, contact us with any questions by phone or email.  If we don't have someone online for customer service, your calls go straight to my cellphone.  We have also continued to invest in a redundant server cluster, backup, 24-hour admin coverage, etc.    And, we increased the pace of product development and refinement.

Some of our community members had worried our new pricing would be expensive for "the little guy", but this worry was unfounded.  With an average monthly charge of $9.58, our average price is less than the lowest price from many competitors.  This tiny price covers a team, not just a single user.  Our most popular offering is a personal repository for $2.30.  Furthermore, we provide a lot of free services for public spaces.  In fact, each paid project supports about 8 free projects.

So, the little guy is covered.  We learned that we need to work harder for our biggest customers.  I started personally calling the few customers that pay more than $50/month, and I found out some things. 

• 100% of them offered to give us a testimonial.  You will see some of these on our home page. 
• Most of them have software consulting operations - like Assembla.  By using ourselves as a model, we have created an application that satisfies a relatively specialized market.
• They didn't know how to use our Portfolio features to manage multiple projects.  We need to do more documentation and demonstration of those features.
• They wanted to give their teams a fixed price bundle.

We used "metered billing" because it allows for lower cost plans and it allows us to add premium tools from partners.  In the metered billing scheme, we charge you at the end of the month, based on the resources that you use.  However, we are seeing the advantages of fixed price bundles.  Users like them, and they deliver more revenue.  They are billed in advance (so you pay sooner), and buyers to not have an incentive to trim a few dollars from the bill by reducing usage.  Our buyers are more aggressive about trimming than we expected.  So, we will be phasing in fixed-price plans as an option.

We designed our first fixed price plan to meet the needs of bigger users.  We are offering the Max plan at $1,800/year (only $150/month), for up to 100 users and 1000 spaces, with hands-on assistance in setting up the portfolio.

Even at these low prices, there are some competitors that are cheaper, especially if you are looking mostly for repository services - our most popular tools.  Low prices are a distinctive feature of the new "Software as a Service" generation of online services that we participate in.

Some competitors cost much more.  The well respected "Jira Studio" package from Atlassian costs $50/user/month with a 5-user, $250/month minimum, which is more than our maximim.  Atlassian is probably pricing their online package relative to their installed products, which typically cost about $5K, so this provides a good indicator of the change in pricing since the last generation of installed software.

The story of the software industry is a story of declining prices and increasing productivity per dollar. The same story of "deflation" and "excess capacity" is affecting a lot of other sectors of our economy, and I think they can learn from the software business.  They call it recession.  We call it progress.

The new generation of cloud-based software that is different in several ways from the last generation.  Here are some points of difference.

* Rapid adoption.  Every application is one click away from the best competitors available.  So, an application needs to deliver value fast, before a new user goes away.  This is actually a HUGE improvement over most enterprise software, which is characterized by a high cost of adoption, and a high risk of failure because people will often refuse to adopt.

* Application integration.  Teams on the Internet tend to combine tools from several vendors into one workflow.  We are supporting this behavior with specific linking tools, such as the Github tool and the Twitter tool, with generic event exchange in our new Webhooks tool, API's, and with our tool extension architecture.  We will incorporate true cloud services from other vendors, such as virtual servers that are packaged into project spaces, deployments to Google App Engine and Azure, etc.  On Internet, you are just a piece of someone else's whole.  The ideal service in this environment would do things like insert itself into other applications as a widget.

* User integration.  Many users would be perfectly happy logging into Facebook, and then using the rest of the Internet as one big extension to that app.  They don't particularly understand why they should have to maintain a lot of different user accounts.  We haven't quite caught  up with this trend, but we will.  We took the first step by designing Assembla so that you can use one user account for all different subscriber spaces.