Inbound marketing is one the best marketing tool for a startup. The easiest way to make that happen is by investing your time and effort in leveraging the internet (your website) to enable a sale.

Getting your first few customers is not a catch-22 situation. You also don’t need the biggest brands as your first few customer to prove that your product is great. Selling a SaaS-based application offline could be hard and expensive. Learn what your prospective customers are looking for and searching for. Get them when they want you. You’ll save yourself from out-of-scope feature requests and get real relevant feedback.

Focus on great customer service instead of cold-calling.

Our first customer for our help desk software, volunteered for translating it in German language out of the love for the product. This in a way is a true power of a good product and inbound marketing.

The best business lessons are learnt while not at business. The subconscious mind is continuously learning things from our day to day activity we perform and indirectly help us do better at work. I couldn’t help mulling over the hiring process while shopping for vegetables at a grocery store. My dad was instructing me how to handpick quality vegetables and I followed every single tip he gave me. So, there is more than just recipe to all the good food that mom cooks. Quality Ingredients.

A product is a collective effort of a group of people. Product is output, people are input. At a startup execution of an idea is key. There are no processes in place governing quality, people are entrusted. Hence, it is important to hire the right set of people. A good hire delivers, is easier to retain and attracts more people to join.

From what I learnt while picking up the right ingredients for a good recipe, I could connect some of those factors to the hiring process.

Freshness:

Look for the most recent experience they have had. The past 6 months can play a key role. Know what they have delivered, learnt and contributed. They should show a sense of excitement with how they have spent their past 6 months professionally despite any constraints they might have had with the employer.

Readiness:

If you are diving into a new technology, check for the willingness and their belief in the technology you have chosen. Just the way, good aptitude always doesn’t guarantee great programmers, availability of skill doesn’t mean they are the best fit. Are they open minded, see your goals as theirs and ready to plunge on the opportunity?

Quantity:

I love the idea of a startup staying lean. But ask any startup and they would say they have so much to do and not enough people. It’s very important to understand for a startup (cash rich or not) growing number of people does not proportionately increase output or business. In fact, startups with large overheads and excess in people make them lose their risk appetite. Knowing how much to hire and spend time hiring is extremely important. You cannot hire for the imaginative future. Keep team size to minimum. It is easier to do better under constraints.

Cost:

One of the best way to keep costs low is to hire people with different experience levels. Experienced, Freshers and Interns. Avoid being on a desperate look out for Rockstars that you think you cannot do without. A good team composition will give you better sustainment capabilities.

Alternatives:

Not all the time you would manage to find people in hirable position and at times you can do without hiring. Never miss out on thinking about the alternatives. Outsourcing, crowd-sourcing and help from friends and family. These are short term alternatives you can experiment.

Source:

Campus Placements, HR consultants, Job Portals, Networking, LinkedIn, References and Blog/Website are all sources that bring in new people. Not all of this works for everyone. In my experience, references and our website has attracted more quality people ready to work for us than any other source. You should be able to pick the right source for you typically depending how much and how soon.

Quality

This is the part where you actually want to evaluate skill-set and attitude. Quality can be brought in perspective with what you have in hand currently. Make sure they are at par or above. Every hire is a unique interview process at startup. Don’t interview a designer the way you would interview a developer. Allow people to exhibit skills and get beyond the resume.

Put to use:

Having people at work who are eternally waiting for something else to happen to take up their job more seriously is dangerous. Everyone at a startup has enough to do, a sales guy does not have to wait for the product to release before he could do anything valuable. If you have people not yet put to right use, you shouldn’t be hiring.

Conclusion & Suggested Reading

Hiring is a process the founders have to be closely involved in. It is an art that grows on you as you hire and learn from it. The next time you are involved in a selection process where you put a lot of thought, you would have learnt something new. It will help you do hiring better. If you have other analogies or experience that go well with hiring please feel free to share them in comments section.

I liked Dharmesh Shah’s take on the first few people that you should have at a startup.
Another interesting post that highlights Hiring Criteria and of course Joel Spolsky’s post on The Guerrilla Guide to Interviewing

Image handling is a common task in an application and for Ruby on Rails we have quite a few plugins like rmagick, minimagick, paperclip, attachment-fu etc available to effectively do the same. Paperclip is by far the most loved and popular plugin used to attach images to a model in a rails application. It makes life easy with good documentation and screencasts available to guide through. But at an advanced level, the challenge comes in when an api interface to upload and download images needs to be provided for the model. As paperclip does not support this by iteself, and there is not much help or guide available to help solve this problem, this post makes life easier for ROR api developers, who have to provide a way to attach images sent through xml to the model.

Lets start with a model person that has an image attachment photo. The model will require the following fields in the migration.

/app/models/user.rb

We won’t be going through the HTML views here, as this is already well documented and available. We are more concerned with the API point of view, so here’s how the controller’s create method would have been if xml responds to is not yet introduced…

Though, we can observe the xml render statements present there, this isn’t quite going to work for us. Well to make it work first we need to decide how do we specify the images in the xml document ?

one way, is offer a separate URL endpoint that allowed direct uploading for just the one image. But this solution requires more than one HTTP call to create or update the model attributes and also will require as many as the number of images in the model, which is not very efficient.

Another way is to embed the image in the xml, where the image is encoded as the base64 encoded string. So the xml will be of this format

when this xml is sent to the create method we need to decode the encoded string in a temporary image file and then assign this file object to the model’s paperclip::Attachment object. The modified create method will now be

Having done the create method you might be wondering how to render these photos back to the client application. Now to get the image for the api request, again just rendering the model object will just give the database columns i.e photo_file_name, photo_content_type, photo_file_size, photo_updated_at but the actual image will be missing.

Here again we have two options…
One is to render the path and url of the variable by building the xml using builder.
/app/views/person/show.xml.builder

But this again is not very efficient, as the url and path are relative to the server address, which in turn raises security issues.
The second option is to embed the image as the base-64 string and send it in the xml file by building the xml

/app/controllers/persons_controller.rb

/app/views/person/show.xml.builder

So here we have images downloaded and uploaded to a model via xml for the purpose of API. This should also apply the same way to api using json too. Please feel free to leave your suggestions as comments.

This post is a part of the series of articles about choices available to a rails developer. Previously we discussed about the choice of databases. This time it is about application and web servers. We can make the choice of an application and a web server separately, but as they are so closely related that it is better to look at them together.

Web Server

It is well known what a web server does, but for starters - the web server receives the HTTP requests first, and then responds by either serving the page requested or directing the request to our rails application server. The major web servers market-share wise (survey graph below) are Apache, IIS(Microsoft), nginx, GWS(Google) and lighttpd. We as rails developers are interested in all these except IIS and GWS. Not IIS because it is closed source and proprietary and not GWS because it is used internally by Google. Apache, nginx and lighttpd are all popular among rails developers.

Apache

The most popular web server  in use. It supports a wide variety of features, and is reasonably fast as well. Many of the essential features are provided as compiled modules that extend the core. These include support for server side scripting languages like perl, php, tcl, python; support for authentication; support for ssl and tls  and compression support.

The only issue with apache is that because it is process based, it spawns too many threads when there are too many simultaneous requests. This leads to excessive memory usage, so the performance can drop in restricted environments under heavy load.

Nginx

The light-weight and high performance web server. It has most features that any good web server should have, but surely lacks a few that apache has. The major differentiator with nginx is the performance. Because of the event-based architecture, it gracefully handles tens of thousands of concurrent requests. There is limited english documentation (which is improving), as it was developed for russian portals . The adoption rate is very high – it has quickly become the third most deployed web server (after apache and IIS).

lighttpd

Lighttpd another light-weight, efficient web server with low memory footprint. It also has an event-driven architecture that is optimized for a very large number of parallel connections. Most rails applications that use it run as  lighttpd + fastcgi configuration. The concept is that lighttpd receives the HTTP requests, and it spawns our rails app instances using fastcgi. In comparison, nginx and lighttpd are almost equally good in performance (some benchmarks), and some people find lighttpd easier to configure. However, there is a perception that lighttpd may not be stable because there are some very old memory leak bugs in it.

web-server market share statistics from netcraft

For more information on the comparison, the wikivs wiki is a good place to start. There is an interesting  stackoverflow discussion also on this.

Application Server

Application server answers requests to the application and is mostly not meant to serve static content. In rails context, the app server runs our rails application code, on requests from a web server. The web server and the app server generally communicate via some standard communication protocols like FastCGI or HTTP.

The first server we come across when starting with rails is Webrick – it starts on a script/server command in development environment. It is a ruby library  for providing http web services and a server. It can be used only in very simple circumstances like development, and anything beyond that, like the production environment of the same rails app, should be run on one of more specialized servers like mongrel, thin or passenger.

Mongrel

Mongrel is the first contender for a production environment application server in rails. It uses plain HTTP to talk to the web server, and is reasonably fast because it uses the Ragel compiler. (More on Ragel: wikipedia page,  mongrel creator’s essay). A very popular way of running mongrel is to run it as clusters behind an apache server using mod_proxy_balancer for load-balancing. It can also be made to run as clusters behind nginx or lighttpd. The only flip-side of mongrel is that it is a little tough to administer the server, especially when operated in clusters.

Thin is yet another web server that has the same philosophy as mongrel (uses the mongrel  parser), but uses the event machine to make it run faster than mongrel. Like mongrel, it is intended to be run behind apache or nginx web servers as clusters.

Passenger

Passenger is the ‘mod rails’ for the apache web server. It is fast, easy to configure, is technically sound and very stable. For example, apache with passenger doesn’t crash if our app has to crash. It is recommended officially, and is praised by the creators of rails. It can run with nginx as well, and is supported on all unix-like operating systems – it does not work on windows! It is also easy to configure and administer.

Some performance benchmarks -

Various performance benchmarks are available for comparison. The summary is that Thin is faster than mongrel, and passenger is almost as fast or sometime faster than mongrel.

source: Thin website

source: Passenger documentation

Our take

We run apache with passenger. Vinay has written a series of useful articles about passenger & apache optimization. Do have a look if the internals of the server interests you.

Conclusion

Rails application deployment survey 2009 (source: http://rails-hosting.com)

Going beyond the default, if you are expecting  high concurrent load on your website, you can use nginx web server with passenger or mongrel clusters.

This post is a part of the series of articles about choices available to a rails developer. It is inspired by a blog post by Josh Susser, where he asserts that there are too many choices available for a new ruby-on-rail developer now, which can get him scared/confused. This series is not about “choice or no choice?”, and not about “are the defaults correct?”. It just answers the newbie developer’s curiosity of what lies beyond the defaults. Lets begin with databases.

Database

Rails is used for writing database backed web applications using the MVC design pattern. The choice of database depends on the kind of capacity you expect from the database and the budget. If you are developing a large enterprise application, you might need to research Oracle/MS-SQL and the like, along with those described here. Another choice you might have to make is whether to go for a relational DBMS. The rails framework provides adapters (programs that connect your app to the database) for three popular open source relational database management systems – sqlite, mysql and postgresql. So if you are looking for an open source RDBMS, you have have the best to choose from.

Sqlite

Is the rails default. As the name suggests, sqlite is light-weight sql. Unlike the other two, it doesn’t work on the client-server model. It runs as a single library, attached to the executing rails app. Due to this, it saves the overhead of client-server communication, hence lite. A common perception is that it is suitable for development environments only and for live websites, it is a small tool (official perception). But lot of people swear by its usability in production – they say it is fine if your site receives up to 100k hits a day. Also, as it is light, it is the best suited database for/as embedded systems. Sqlite is used by some big names like Apple and Firefox. A more complete list can be seen on the sqlite website. More on sqlite performance -a stackoverflow question , official figures. However, as sqlite is not designed to handle heavy concurrency – it might not be a good choice if your app has 100 users per second all performing database operations.

mysql

Mysql is client-server based, fast, easy to use and very popular. It is available for most platforms (look at this comparison on wikipedia – mysql is all green), and adapters and tools are widely available. Quite full featured, can be configured to run well for different goals and environments through its 9 storage engines. And works reasonably fast by default. Do look at this discussion on stackoverlow if you are torn between mysql and sqlite. The only catch with mysql is in the license. Its free and fine for use, but if you are planning to distribute mysql with your close-sourced product, you may have to pay license fee. Some useful information on the licensing can be found at stackoverflow, wikipedia and the official website

PostgreSQL

PostgresSQL is another great RDBMS (actually an O-RDBMS) available for rails developers. It is almost as good as mysql, with some differences in technology, and notable difference in license. Architecture is different (this has a single engine), so is ACID compliance (full here, partial in mysql), and there are some feature differences (partial indices are supported here, not in mysql) as well. The license in postgres is a much simpler MIT style ‘postgres’ license. So which one to go with – mysql or postgres ? Most people who have used both are inclined (see this stackoverflow discussion) towards postgres. Mysql has some limitations (like – no partial indices), which should be understood, especially if your application might need some hard-core database operations, like, say multiple level sub-querying. Plus, postgres is controlled/supported by the developer community, while mysql (now) belongs to Oracle. A few more good comparison resources – tarangana blog, wikivs. Some relevent stackoverlfow questions – pros/cons,  mysql-> postgres switch, reason for mysql popularity.

Our take

Conclusion

Someone asked me what I do and I had to decide whether to say “I work for a small product development company” or “I work for a web based startup company”. Invariably, the former received “ho hum” replies and the latter received “aah ooh” replies. The kick of “aah ooh” replies not withstanding, the question is still very real in my head. Are we still a startup?

The way I see it, there are two definitions for startups. The term startup company according to Wikipedia :

“A startup company or startup is a company with a limited operating history. These companies, generally newly created, are in a phase of development and research for markets.“

This is the strict definition based on certain statistics about the company that many people consider as correct. Lets check its validity.

Take Google Apps for example, it was in beta (‘phase of development’) until July 2009. Does that mean it was a startup until then? The fact is that software these days is continuously under development. So that cannot be part of the criteria determining the definition of startups. Nor can age or size of the company because well, Steve Jobs described Apple as the “Biggest Startup on the Planet” at the D8 conference this year. Some say that once a startup becomes profitable, it becomes a company. Twitter has been ‘in operation’ since 2006, still has not figured out a business model and has a user base thats probably second only to Facebook. Now where does that leave Twitter? Lets face it. Definitions based on turnover, size and age just don’t work anymore.

The expression startup company now evokes an emotion that goes beyond numbers and figures.

Culture

Startups are expected to have a clearly distinguished cool culture. Bureaucracy is definitely frowned upon and so are cubicle farms. Work clothes are usually t-shirts and jeans and everyone is a decision maker in the company. Work and fun are interchangeable. Millions of Kilobytes of text have been written about startup culture. For starters, take a look at Brian Halligan’s (CEO and co-founder of Hubspot) “Startup Culture Lessons From Mad Men” and Greg Gottesman’s “Thirteen key characteristics of a great startup culture“. The reason many people still consider Google to be a startup is because of its famous work culture. Not because its products are ‘officially in beta’ forever.

Funds

Startups always function with restricted funds. They are always trying to cut costs by using open source tools, having fewer employees, doing more things at the same time and working longer hours. This can be true for various reasons. The key though, is that even those startups that find millions in funding through VCs and Angel investors don’t ever splurge money on 6 figure executive bonuses and private jets. Expenditure is disciplined. You will find more startups spending money on keeping a well stocked fridge and a foosball table in the office than on getting a new mahogany desk or chandelier. Again, the culture is what drives this habit. Making work fun for everyone takes precedence over luxurious spending. Its so obvious that big corporations should write it on a big hammer and bang themselves on the head with it for missing it.

Nature of operations

It is possible that a new product in development in an old company functions like a startup. A lot of development and research will be going into the product and business model. A handful of people will be in the team and the goal would be to make the product a business in itself. Take DoAttend, our event organizing tool, for example. Although its a product of a 9+ year old company, the DoAttend team still functions like a startup and is itself only a few months old. So think about it. You may be working for a company thats been around for a while, but what is the nature of your work? Are you part of a newly formed, small and tight team with a specific product to make? Are you looking to make it a profitable business in itself? Are you and your team self motivated and driven toward the common cause of making the product successful?

Startups are no longer merely a category of companies. They reflect a whole new work culture and nature of operation that is inspiring the next generation. Startups mark the arrival of a new Renaissance in work culture. The internet and the success of startups has shown that small companies can be disruptive on a large scale. This has in turn sunk into society so much that you would rather call yourself a “startup” than a small company now. Its a lot more media and employee friendly. Think about it, a true definition endures as an emotion. So what emotion does the word “startup” evoke in you?

Its no surprise therefore, that although we are going to be 10 years old soon, Tenmiles is still a startup at heart. We believe in, function under, follow and promote startup culture.

My mind is now at rest. I will continue to say that I work for a web based startup. I can now enjoy the “aah”s and “ooh”s with a clear conscience.

How else do you think the definition of a startup has changed? Feel free to let us know in the comments.

Prelude

In the previous article, we went through the basic architecture of Apache and Passenger. Now I’ve been told that its a bit too much to digest in one shot but it’ll all make sense when all the 3 articles are read together. If not, you’re always welcome to drop a question in the comments section and I’d be happy to help.

Assumptions

In this article, we will be looking at the primary directives in Apache and Passenger for optimization. The rest of the series is specific to the case where a single RoR application is running on the server (say, TweakMyApp).

Apache Directives

The Apache directives that can be set for the pre-fork MPM are listed here with brief descriptions and suggested values.

StartServers – The number of child processes (workers) to start on Apache startup. The default 5 is good.

Apache will spawn child workers to handle multiple incoming requests. This directive specifies how many such child processes are required by default when Apache itself starts up. When Apache starts up, a main control process spawns the workers and is responsible for delegating requests to them. You can refer the previous article or the Apache docs for details about Apache’s achitecture.

MinSpareServers – Minimum number of idle spare children to keep ready for expected requests. A high number is rarely good. Anything from 3 to 5 is fine.

Say this number is set to 3. This will tell Apache that even if there are no requests, keep at least 3 child workers alive for expected requests at all times.

MaxSpareServers – Maximum number of idle spare children to keep ready for expected requests. Again, a high number is rarely good. Anything from 8 to 10 is fine.

Say this is set to 10. This tells Apache to keep at most 10 children alive to process expected requests. MaxSpareServers and MinSpareServers define a range of idle children to keep and Apache will kill or spawn children in order to stay within this range. These directives are important mainly to specify how much of your server’s memory is allowed to be hogged by Apache’s idle children.

MaxClients – Maximum number of child processes that will be launched to serve requests. The default of 150 is usually good.

One thing to remember in this directive is that, say one instance of TweakMyApp consumes 90MB of RAM, it does not mean that you are allowing (90*150) MB of RAM as the maximum request setting for the server. Apache processes consume much less memory than that. We will look at that in detail in the next post. Also, if you want to set this at anything above 256, then you need to tweak the ServerLimit directive first.

MaxRequestsPerChild – Sets the limit on the number of requests each individual child process will handle. Default of 0 (infinite) is perfect.

If you change this number, you give each child a finite number of actions before it will die. In effect, you are freeing memory by reducing the number of processes that are running when the server is not busy. Freeing memory for what? Maybe there are other applications on the server that could use the memory. But its not likely that they’ll require that extra memory only when the server is not busy. So leaving this setting at 0 is best, especially based on “our assumptions”.

Passenger Directives

The Passenger directives that are used for optimization are listed below with brief description.

PassengerMaxPoolSize – The max number of RoR application instances that may run simultaneously.

This is the total number of application instances that the Passenger Application Pool will hold. Since we only have TweakMyApp running on our server, this number is essentially the number of instances of TweakMyApp we have ready in the Application Pool to server requests.

PassengerMaxInstancesPerApp – The max number of instances of each RoR application that may run simultaneously.

This is not relevant to us as we have only one application, TweakMyApp, to consider.

PassengerPoolIdleTime – The max number of seconds for which an application instance can remain idle. This can be set to 0 (infinite) for our case.

This needs to be set at a finite value only if you have multiple applications. Say there is another application, IntrudingApp, that runs on the same server and needs another instance to serve incoming requests, and say TweakMyApp instances are sitting idle, then Passenger can shut down idle TweakMyApp instances and use the memory to spawn IntrudingApp instances. Since we only have TweakMyApp running and need it to be available at all times, 0 is perfect for us.

PassengerMaxRequests - The max number of requests a given application instance will process. Again, this can be set to 0 (infinite) for our case.

This directive is very similar to the Apache MaxRequestsPerChild directive and is best left at 0 for us.

PassengerStatThrottleRate – The frequency with which Passenger should perform its file system checks. I’m leaving this at the default of 0.

This setting tells Passenger how often it needs to perform its filesystem checks like checking environment.rb and restart.txt . If you have an application that you dont intend to change much or one in which changes in the code can take effect slowly, then you might want to set this value to something higher. It will help free up some memory. But I’m leaving it at 0 here under the assumption that you have a highly dynamic application.

PassengerHighPerformance – This setting increases Passenger performance at the cost of reduced compatibility with certain other Apache modules. Im going to go with the default of “off” here.

This setting improves Passenger performance but affects compatibility with other Apache modules like mod_rewrite and mod_autoindex. Im leaving this off to be on the safe side.

Passenger Global Queueing is another useful concept that could potentially speed up processing of requests further. Im leaving it off in my case because I have not tested it yet, but you could turn it o” at your own discretion. It is of special relevance if you are running multiple application on the server.

References

A similar, very useful blog post here

MaxClients and ServerLimit – Check the comments section here

The discussion in Passenger’s Google group

Check this discussion for more Passenger directives, highly recommend it

Global queueing discussion in Google groups

Multiple Apps

Most configuration for managing multiple applications on a server will be done using Passenger directives. For example, you may want to tweak the PassengerMaxPoolSize and PassengerMaxInstancesPerApp directives. There are other directives and concepts like Global Queueing also which can help you, but I’m going to point you to the Passenger Documentation for that.

In the next article, we will use what we have learnt so far to get to the nitty gritties – gathering metrics and tweaking configurations. Until then, ciao and feel free to drop in your comments.

So here’s my problem. I’ve written an RoR application and I’ve managed to get a server up and running with Apache and Passenger. Im paying quite a bit for my server, but I have no idea if my application is effectively using the server’s resources. How do I gather metrics to make sure that I can configure my web server(Apache) and application server (Passenger) optimally to serve my application?

I realized that there are 3 parts in the answer to this question. First, we need to understand how Apache and Passenger are designed to handle incoming HTTP requests together. Second, we need to understand what the various directives available for Apache and Passenger mean. And finally, we need to see how we can gather metrics and tweak these directives to the optimal setting.

Im going to address each of these 3 parts in 3 blog posts. So lets get started with the first, how Apache and Passenger are setup to work together.

There is an explanation in the Passenger docs on Passenger’s Architecture but frankly, I could not digest it in one read. So I’m going to summarize it for our purposes here.

mod_passenger sits in the control process and every child process of Apache's

Apache has an architecture wherein modules can be plugged in to add functionality to it. Passenger provides the mod_passenger module which allows Apache to act as an application server. The above diagram (taken from the Passenger docs) represents Passenger’s architecture when the default prefork MPM is used with Apache.

The mod_passenger module sits in the main control process and every worker process that Apache generates. It also maintains 2 other things - a spawn server and an application pool.

The Passenger Spawn Server further, has 3 components – Spawn Manager, Framework Spawner and Application Spawner. Now according to the Passenger documentation,

“A particularly interesting thing to note, is that a lot of the memory occupied by Ruby on Rails applications is spent on storing the program code (i.e. the abstract syntax tree (AST)) in memory. This is observed through the use of the memory statistics function in Ruby Enterprise Edition. Also, a lot of the startup time of a Ruby on Rails application is spent on bootstrapping the Rails framework.”

This means that performance can be increased considerably if the Rails Framework code and your application code can be cached and reused. This is primarily what the Framework Spawner and Application Spawner do. The Framework Spawner spawns and caches an instance of every Rails version that your applications use. Similarly, the Passenger Application Spawner spawns instances of your application to serve requests. The diagram below (also taken from the Passenger docs) represents this.

Each of the top 2 layers is responsible to handle only its immediate children

The application pool is simply a pool of application instances that can be used to handle incoming requests.

So when an HTTP request comes in to Apache, it passes it on to mod_passenger, which checks out an application process from the pool and marks it as busy. If all app instances in the pool are busy and the pool limit has not been reached yet, then mod_passenger will place a spawn request to the spawn server/manager. The spawn manager will pass on the request to the correct Framework Spawner Server. The Framework Spawner will then forward it to the correct Application Spawner Server which will then spawn a new application instance to serve the request. The lifetime of this application instance is then maintained directly by mod_passenger.

So that, is typically how Apache and Passenger dance together. For a more detailed run through however, I recommend the Passenger Architecture Document. It is definitely an interesting read. A couple of other pages that you might like to refer :

Apache MPM modules – http://httpd.apache.org/docs/2.0/mpm.html

Ruby Enterprise Edition – http://www.rubyenterpriseedition.com/

In the next article, we’ll take a look at a few basic directives for Apache and Passenger.

SaaS: Software As A Service has become widely accepted and is a popular choice among businesses. Businesses consuming SaaS applications favour the low upfront cost and zero infrastructure headaches. Also, SaaS applications being deployed online have the advantage of being available anywhere, anytime and even on any platform. Businesses developing software have embraced the SaaS model with open hands. The emergence of Cloud computing, subscription ready payment gateways and success stories of the likes of SalesForce and Google Apps makes it an easy model to follow.

Clearly SaaS applications have adopted a different pricing model than the traditional one-time license fee based desktop or web applications. There is a definite recurring cost per user in the hosted model that warrants the need for a different pricing approach. You not only provide an app but also manage users data.

Let’s dive into a few of the popular pricing strategies to understand the available models and what could fit your next SaaS application.

FREE

There is actually no free model when it comes to SaaS applications, unlike desktop or deployable web based apps. The Free model is actually an Ad-Supported model or something that helps a business leverage/popularize another brand or product. YouTube is a good example that falls into this model. No user ever pays to upload or consume the videos. The revenue generated for the business is using Ads. Other services that follow similar models are popular Networking Sites like Facebook, Twitter & Orkut.

Facebook - Free Social Networking Service

The free model can scale quickly and you need to achieve critical mass to make sense of running on an Ad driven model. You would need to have a lot of cash in your pocket to scale up the infrastructure to support a large user base before ad-revenue starts pouring in. The free model works well for business-to-consumer (B2C) rather than business-to-business (B2B). While businesses do leverage these applications quite well they have no control, support & one-to-one relationships with the service providers.

Ads shown on youtube.com homepage

The most successful Free SaaS applications have their own Ad Networks. Think Facebook, Twitter & YouTube (Google). Other apps that don’t have their own ad networks end up sharing their profits with their advertising network partner (such as google adsense) making it even more difficult for the business to survive purely on ads. Recently, Ning the popular Social Network provider decided to close their Free offering and price their service instead.

There are startups that use the Free model while offering their service in beta. They are likely to move to other pricing models.

Freemium

This is probably the most popular pricing model for SaaS applications. There are plenty of B2C and B2B apps that use this model effectively. The idea of Freemium is to offer a Free plan along with paid plans. Paid plans usually offer some benefits over the free plans. Free plans become a great starting point for users.

CodeBaseHQ's Free Plan - With the limits clearly stated

Flickr is a great and the simplest of example that follow this model. You can upload pictures and share with a free plan but with a limit of 200MB uploads per month ,unlimited viewing of your images but would have ads on the page. If your usage is going to go above that limit you can consider upgrading to their PRO plan (for an annual fee you can upload up to as much as 100 times more content).

FlickR offers PRO plan at $24.95/year

Premium plans are usually selling more usage, features, priority support or sometimes even additional data security and back up. To arrive at what could be premium in your SaaS application could depend on the market segment you are addressing to and/or the costs to enable you to provide the additional services. Free plans help the business generate more word of mouth and attract small businesses early on.

Free Trial, Paid Only

Try before you buy. A more serious, built-for-business pricing model. Applications are usually available for anywhere between 7-60 day trial but are full featured. Apple’s MobileMe and Hubspot are good examples that use this model effectively.

Apple's Mobile Me Service at $99.95 per year with 60-days trial. No Free Plans.

You probably need to have a product that stands out, has limited competition or is perceived as an extremely useful app. Many services indeed require you to submit your credit card information when you sign up for the trial period and start charging you as soon as the trial is complete. While this could prove an entry barrier for users it surely helps you minimize non-serious trial users.

Arriving at your pricing model

Having discovered and determined various segmentation that can help you price your service (what to charge for) the next big question is how much to ask and how often. How much quite often determines the entry barrier while how often determines retention ability. IMHO, How much is of course the bigger challenge. The real number could be arrived by studying competition, market size, target audience, perceived value of your service and many other factors. However, there is a clear choice you can make, between having a Single Plan or Multiple Plan.

Single Plan

Evernote, Flickr, MobileMe use a single plan strategy; Premium/Pro plan.

Single Plan offered by Evernote

They are essentially selling more storage space and bandwidth, targeted towards individuals rather than businesses. Their product does not involve multiple users within a single account and can be categorized in to B2C. Hence, the rationale behind a single price point.

Multiple Plans

It is important to evaluate if your market could be segmented. For instance – Small, Medium and Large Enterprises, Open Source and Proprietary software vendors, Freelancers starting out and well established freelancers. The goal of multiple pricing plans is to charge more to customers who use your service more and vice-versa. For instance, if you are selling a project management solution, you can easily segment your target audience on either the company size or number of projects. Businesses often may experiment with the most low end plan before they think the solution is fit for the entire company.

From Free Plans to $99/mo plan. Key segmenting factor is number of projects and storage space.

LinkedIn offers separate pricing for Job Posters (Companies) and Job Seekers.

LinkedIn - Pricing for Job Posters (Companies)

LinkedIn - Pricing for Job Seekers

Another excellent example of segmenting is GitHub. It segments different business sizes and offers free plan to only open source projects. Making it a popular choice among the large opensource development community.

GITHUB - Keeping it FREE for Open Source Projects

No Plans – Pay as you go

If your end users don’t have a definite usage pattern and are unlikely to commit for a specific time period it might be a good idea to have a pay as you go plan. DoAttend and Campaign Monitor are good examples of pay-as-you-go pricing models.

DoAttend works on a transaction model charging customers a very small fee when transactions happen. The customers are invoiced monthly based on their actual usage. Ideally, an Event Organizer who does one event a year will never want to pay monthly or yearly when he/she only uses the system for a maximum of 3-4 months.

DoAttend - Transaction based pricing - Pay As You Go

In a similar way, Campaign Monitor charges 1 cent per email sent out along with a fixed fee of $5 per campaign. Customers are charged 100% in advance everytime they choose to send out a mail campaign. Their pay-as-you-go pricing model appeals to customers who send out mailers once in a while with a varied number of subscription lists, which makes monthly plans a lot more expensive.

SlideShare uses Pay As You Go model for lead generation. Their latest LeadShare Program basically charges their customers only when a lead is generated from the presentation hosted on slideshare.

Leadshare by Slideshare - Pay per lead program

How often to charge

Monthly, Yearly and Pay-As-You-Go pricing models are what most applications adopt. Applications billing on Quarterly or Half-Yearly basis are quite rare. It is not uncommon to use more than one of these payment intervals. Evernote uses both Monthly and Yearly option. Mail Chimp uses both Pay-As-You-Go and Monthly plans.

MailChimp has both Monthly & Pay As You Go plans

Canceling subscriptions and upgrading/downgrading plans are assumed available by most consumers and you should be very clear about it to ensure better conversions. The best way to judge if your payment interval is ideal for your app is by keeping a track on customer retention ratio. Another handy number to have is average value and retention period of your customer. If you are offering a service for $5/mo and realize that average retention period is only 7 months it might be a good idea to offer a discounted yearly plan (besides improving your application to increase your numbers) and see how your new customers choose. If you are offering a yearly plan that is priced high, it would be a good idea to introduce a monthly plan to see if that reduces the barrier to entry.

Setup fees are very rare too, Hubspot charges a fee during sign up referred to as Mandatory Quick Start Program Fee. If every account on the system has a fixed cost to get started or if you think the value provided in your service is the maximum during the first few months rather than an long on-going usage, you can consider a setup fee.

Hubspot Charges a Compulsory Fee on Joining - referred to as Quick Start Program

Popular infrastructure

The SaaS ecosystem has grown really quickly, solidly and cost effectively. Cloud hosting, modern billing systems and availability of excellent frameworks have made this possible.

Cloud Hosting

Amazon Web Services: Amazon offers a large variety of cloud solutions. The most popular being Amazon Elastic Compute Cloud (EC2) and Amazon Simple Storage Service (S3). There are no major upfront costs and their pricing is hourly or by space consumed (in GB). It’s fairly easy to setup and a highly scalable solution.

Rackspace Cloud: Rackspace the leader in Dedicated hosting bought a cloud hosting service called Mosso and are aggressively marketing their cloud service as Rackspace Cloud. They offer cloud Servers (self-managed, starts at $10.95/mo), Cloud Sites ($149/mo) and Cloud files ($0.15/GB/month).

Slicehost and Linode are popular VPS hosting companies. These services are popular among ruby on rails (ror) and Python django developers. Pricing starts at $20/month.

EngineYard focuses on Rails hosting. One-click code deploys, application cloning, data automation and gem management.

Heroku is another ruby-rails hosting company. They have a free plan (great playing field for your 1 week old app on the cloud) along with paid plans starting at $15/mo.

Other hosting companies worth a mention are MediaTemple, Joyent and Aptana.

Billing Systems

Authorize.net (US only), Paypal, Amazon Flexible Payments Service, BrainTree (US only), Beansteam (US & Canada only) and 2checkout are some of the popular payment gateway that offer subscription services. You don’t have to store any credit card information on your servers and in most cases don’t even require PCI compliance. Spreedly and Chargify offer services on-top of the payment gateways to make upgrade/drowngrade/renewals available without you having to code anything to enable these features (for rails developers you have Rails Kit, ready-made code to plug into your rails application).

Frameworks

If you are building apps you might already be well aware of the popular frameworks available. These frameworks significantly reduce development time and make maintaining code easy. Server Code: Python Django, Ruby On Rails and CodeIgniter for PHP. For Client End Javascript – Prototype and jQuery are the most popular choices with many other awesome Javascript libaries around. Blueprint for CSS is very handy too. It is a good idea to compress your Javascripts and CSS for better performance. You can even consider using Google APIs to off load the JS load from your server.

The bottom line

Pricing is no rocket science if you rationally arrive at it. Experimenting early on, staying flexible and listening to your customers can really help you nail down the ideal pricing model that works for your business. Allow customers to upgrade/downgrade and even exit without any penalties. Don’t simply underprice for the sake of looking more affordable than your competitor. Keep your conversion and retention ratio in check to back your pricing decision.

Have more ideas/resources to share? Add them in the comments.

Are you turned on by great ideas and beautiful code? If yes, we want you. Here at Tenmiles, we are driven purely by the excitement of building our own products and making them simply awesome for our customers. And beautiful code is the next obvious step to getting there. We have rolled out 3 Rails products so far and are best known for DoAttend. We are hiring experienced developers, freshers with some personal programming experience (any language) and interns.

What are we looking for?

You must be a daring programmer who can get things done. You should be able to pick up new approaches and learn new techniques quickly.

You must be self-driven and self-motivated. We want to see you come up with ideas for products and features, want to hear you talk about them passionately and want to be convinced that they’re simply rad!

You must have a startup mindset – taking responsibility for the product, and working as a team to do what it takes and make it a success.

Experienced Developers: You must be exceptionally good in programming and have a very good domain knowledge in Rails. Experience no bar. Show us some code or links to projects you have completed.

Freshers & Interns: Hunger to code, excellent aptitude and logical skills. Experience in Rails/Ruby not required but exposure to some programming language with personal programming experience would be required.

What do you get to do?

You will officially be in charge of development and upkeep of one of our Rails products.

You will also be a part of the Rails team as a whole and will be contributing to its evolution – building the domain knowledge in the company, establishing best practices, coming up with more product ideas and delivering Rails apps to customers. We still function like a startup and so your involvement will help form the culture and practices in areas that you work on. We encourage you to take responsibility and initiative and get things done. Oh, and of course, you’ll be working on a Mac

Now if you read the above and feel more adrenalin pumping through your body, it most likely means that you think you’re perfect for this role. And that most likely means that WE will think you’re perfect for the role.

How can you apply?

Email us your resume to jobs@tenmiles.com. Please send your resumes in PDF format only. Do not send cover letters, instead, please list your experience (professional or personal) with Rails, JavaScript and HTML+CSS. Link projects that show your experience. The more great code you show us, faster the interview process and the easier it will be to floor us.

Got questions? Leave us a comment or get in touch with us by email or twitter.