Top 10 tips for writing successful Software as a Service

Essential skills for ensuring that your SaaS project finishes on time and under budget


Software provided as an online service, rather than a desktop-based application, continues to grow in popularity at a exponential rate. I've been involved with a number of businesses centered around SaaS. And during that time, I've assembled 10 key elements specific to software development that can determine whether an SaaS application becomes successful and — in many cases — whether it makes it to release. These tips are intended to provide an enlightening perspective on SaaS-based development.

1. Make UXD your most valued asset

With the advent of the Internet, attention to user experience went out the window. However, there has been a clear and evident push-back toward this important characteristic of successful software in recent years. This return was marked when the term Web 2.0 first became a buzzword, eventually evolving into something more meaningful: rich Internet applications (RIAs). I intentionally place user-experience design (UXD) in the No. 1 position in this article because user experience is the one identifiable characteristic that immediately causes a computer user to choose one application over another.

Figure 1 and Figure 2 demonstrate two interesting UXD techniques. Figure 1 illustrates a concept known as stay on the page. Because this is a thin RIA client application built using Adobe® Flex, there are obviously no pages. However, the technique is still valid. The use-case scenario is a user who wants to change his personal account settings. Instead of leaving the current state (or page) of the application, an overlay window is displayed that allows the user to make the necessary changes, then close the window and go back to the task at hand.

Figure 1. Example of UXD technique known as stay on page
Figure 1 illustrates a concept known as stay on the page
Figure 1 illustrates a concept known as stay on the page

Figure 2 displays a closer view of the window brought up in Figure 1, but in two modes. This use case is more specific in that it is assumed that the user wanted to change the Company Information values specifically and, therefore, selects the respective title bar. Window 1 displays the state of the window when it is first displayed. Window 2 shows the state of the window after the user has clicked the Company Information bar. This technique is referred to as an accordion menu because of the way panels slide up and down like an accordion when their respective title bars are selected. This behavior enhances the user experience because it makes it easy for the user to quickly and easily locate and update one or more values when many settings must be categorized.

Figure 2. Accordion panels
Figure 2 displays a closer view of the window brought up in Figure 1, but in two modes
Figure 2 displays a closer view of the window brought up in Figure 1, but in two modes

2. Adapt to changing requirements

If there is one inevitability in software development, it is that the client, customer, or product owner will change the requirements of the project after all the designing, planning, diagramming, and prototyping have been completed. Most project managers are trained in traditional methodologies, and part of that training includes resistance to change; the result is a dangerously increasing level of "thrashing" the closer the product gets to its first official release.

Software development evolves so rapidly that it is not uncommon to find the core project management methodology changing several times throughout the lifespan of the initial development process. As a result, be prepared to implement new developmental methodologies or variants of existing methodologies with every project.

3. Adopt open standards

Companies based on SaaS must consider adopting open standards because compatibility with other devices, platforms, services, and Web applications translates to less coding in future iterations and greater consumer adoption of the product. Consumers appreciate and gravitate toward an SaaS application that allows them to accomplish multiple tasks. For example, Figure 3 shows TweetDeck, a cross-platform application that uses the Twitter and Facebook open APIs in one interface. TweetDeck is quickly becoming one of the most popular Twitter clients, largely because Twitter users can also view the status updates of their Facebook friends without switching applications.

Figure 3. Popular TweetDeck application uses open APIs of Twitter and Facebook
Figure 3 shows TweetDeck, a cross-platform application that uses Twitter         and Facebook open APIs in one interface
Figure 3 shows TweetDeck, a cross-platform application that uses Twitter and Facebook open APIs in one interface

Financial cost to a business can be significantly decreased using tools based on open standards because licensing fees are eliminated, and the cost of resources decreases because you have a starting point that is ahead of where you would be if you were building from scratch. You can then allocate resources to modifying the source code to meet the business needs and challenges. For example, the makers of TweetDeck can focus on building user experience features into the application, rather than having to work on the Twitter and Facebook APIs, which would be cumbersome.

Consider this: What would happen if Twitter and Facebook charged money to use their APIs? TweetDeck would likely have to charge monthly usage fees to consumers so the company could pay Twitter and Facebook to use their APIs. Or users would have to pay Twitter and Facebook a monthly fee just for using the TweetDeck application. The resulting effect to TweetDeck, Twitter, and Facebook would be detrimental, and TweetDeck could no longer be considered a successful SaaS application.

4. Wireframe before design

A wireframe is simply a conceptual visualization of a specific state of a software program's UI from a functional standpoint, as shown in Figure 4. Notice that no fancy design is involved. The purpose is to avoid being distracted by design elements so the focus can remain on the business function. Once the business functions of the application have been established, the design team can have at it; but software has to be functional before it can be pretty.

Figure 4. Wireframe provides conceptual visualization of a UI
Figure 4 shows a wireframe

This facet ties in heavily with UXD, the first element of successful SaaS. The difference is that for SaaS to be successful, UXD must be part of the entire software development life cycle from concept to production. When it comes to wireframing, I consistently find two mistakes that cause SaaS to fall short:

  • The team jumps too quickly to design, and creating the application's design theme suddenly becomes part of the wireframing process, because the stakeholders want to see something that looks pretty instead of functional.
  • Key states of the application are missing from the wireframe collection (that is, only parts of the application get wireframed).

Interestingly, the second of the two reasons is most detrimental to an SaaS project. The most fascinating thing about wireframes is that you can depend on them to expose gaps in the comprehension of product requirements. They are known to expose core architectural design deficiencies well before development begins. With that in mind, it isn't difficult to imagine how making sure the wireframing process is complete could save the business a lot in regard to time and resources.

A completed set of wireframes may well include 100 or more documents. Each wireframe should be associated with a one- to two-page description at minimum to help the stakeholders understand what they are looking at when reviewing the wireframes. Keep in mind that these wireframes will need to be revised before stakeholders sign off on them. It's better to identify discrepancies during wireframing than after the functionality has already been coded.

Note: After the design process takes place, the complete set of documents that now define the UI is often referred to as the picture book.

5. Provide SaaS with a cloud infrastructure

At first, to suggest that network infrastructure can make or break SaaS may seem like a no-brainer. However, most SaaS applications on the Web are running on insufficient hardware tied to an infrastructure that cannot be scaled on demand. As developers, we have access to self-scaling cloud systems often referred to as Infrastructure as a Service (IaaS), yet adoption of such superior technology is surprisingly slow.

This slow uptake can be attributed mostly to a lack of knowledge on the subject. For example, Amazon Elastic Compute Cloud (Amazon EC2) has the potential to offer massive savings to businesses running SaaS applications, but the general lack of knowledge about the Amazon Web Services (AWS) infrastructure causes many to fall back on legacy systems because that is what they know. However, the constant increase in bandwidth available from ISPs is as a guarantee that any successful SaaS applications will require more advanced network performance in terms of automated on-demand resource scaling.

6. Produce complete design documentation before starting to code

Software works the same way businesses do, and a major characteristic of successful SaaS companies is a healthy respect for the planning stage of the development process. High-quality design documentation serves as a road map for those responsible for executing the design and has the potential to accelerate the coding of the software substantially. That is why successful SaaS applications are usually projects that come in on time and under budget.

When SaaS applications go over time and over budget, it's because poor communication of architectural design principles for the project. To maintain code consistency throughout a large SaaS application, it is critical that a complete set of applicable design patterns and conventions be established and effectively communicated throughout the development team. An excellent way to communicate such principles is by using the visual cortex.

Using the visual cortex

A staggering number of clinical studies on human thinking and learning conducted over the past 100 years suggest that humans learn faster when more than one of the five senses are engaged in the learning process. Engaging the sense of sight in addition to hearing makes learners nearly seven times as likely to remember the subject matter. It is no wonder, then, that visual cues such as diagrams and flow charts are so effective when it comes to technical software documentation.

As Figure 5 shows, software architecture and micro-architecure diagrams are useful for establishing and communicating a foundation for an RIA client and provide development teams with an outline to follow when organizing code. These diagrams also establish a set of guidelines and expectations from a structural standpoint.

Figure 5. Loose, high-level view of a program's structural design patterns
Figure 5 shows diagram depicting architectural design
Figure 5 shows diagram depicting architectural design

Flow diagrams are also particularly useful for conveying a process or series of events. In many cases, the more creative you can be, the more effective flow diagrams become. Figure 6 demonstrates how creativity was implemented into a flow diagram used to provide a visual depiction of how the open source Swiz Framework for Flex implements Inversion of Control (IoC), object introspection, and dependency injection.

Figure 6. Flow diagram of the open source Swiz Framework for Flex
Figure 6 shows diagram of Swiz Framework
Figure 6 shows diagram of Swiz Framework

If you've ever assisted with, filed for, or otherwise been involved with creating a method patent, the diagram in Figure 7 may look familiar. It is especially useful for showing a process or method where there is more than one possibility. A good example of this is a process that involves a number of functions, some of which include one or more conditionals, such as if - else and switch statements. Functional description diagrams are extremely handy for outlining technical business processes as well as software. For example, this type of diagram would be optimal for outlining the process of committing code to the company's central source-code control repository.

Figure 7. Functional description diagram, used for walking through a conditional process or method
Figure 7 shows diagram of functional description
Figure 7 shows diagram of functional description

7. Be obsessed with unit tests

In general, SaaS front-runners are usually fairly large applications constructed by many. When it comes to large applications and unit testing, the data is consistent: Projects that implement unit tests as an afterthought fail miserably. At the opposite end of the spectrum, successful SaaS developers write unit tests and even run them before they write the code. For example, if I were tasked with writing a class called ServiceController, I would not start by coding the class. Instead, I would write the class that runs all the unit test cases against the methods in the class. Then I would even take it a step further and run the test cases, even though I know they will fail because I haven't actually written any of the code for it.

The purpose of this exercise is to rule out the possibility of actually having bugs in your unit tests that could cause them always to pass. As unusual as it may sound, it is easy to unintentionally make this mistake. Provided that all the unit tests fail, I know that I am ready to begin writing the actual code. When I have completed writing the new class, then I run the unit tests again. As long as all the test cases pass, I add the new unit test class to my unit test automation library, which gets run on every build. In other words, the entire unit test library I create for an application becomes part of my build process. In fact, before I even start building the project, all unit tests are run to ensure that the integrity of the application code has not been unintentionally compromised.

In the world of programming, I have only seen a few developers practice this process religiously. However, they are among the most well-respected, prestigious, and well-paid individuals in the industry. If you're looking for a quick route to a pay raise or a promotion, be obsessed with unit tests.

8. Tackle mountains, not molehills

The potential for performance bottlenecks is far greater with SaaS applications than with "thick" client applications that run from the desktop. Even veteran programmers will admit that when it comes to SaaS applications, sometimes performance bottlenecks are difficult to predict because of the number of variables involved. The difference between successful SaaS applications and those that fail is the way in which the development team responds to detrimental performance hits during load testing and profiling.

Generally speaking, there are only two types of performance optimizations: those that make a noticeable impact on performance and those that don't seem to have any noticeable results at all. Rarely is there anything in between. A common metaphor used in this regard is that of mountains and molehills. Nine times out of 10, developers spend the majority of time allocated to boosting performance, stomping on molehills rather than tackling gargantuan problems beating the life out of the computer's processor or memory while the application is running. The important thing to take away here is that as a programmer, you cannot see the mountain when you are too busy looking at the molehills.

The easiest way to prevent being distracted by the molehills is to profile your applications. Profiling is an important part of successful SaaS projects because it gives you the opportunity to optimize the way your application uses system resources, as shown in Figure 8. When you profile an application, you are able to see exactly which pieces of the application are taking up the most resources and implement design patterns for increased performance. For example, you may find it necessary to implement object pooling with proxies if you find a lot of object reinstantiation without the necessary garbage collection, which continuously eats up more memory for as long as you leave the application running.

Figure 8. Application profiling in Eclipse
Figure 8 shows creen shot depicting application profiling in Eclipse
Figure 8 shows creen shot depicting application profiling in Eclipse

9. Learn from other successful SaaS projects

The simplest way to learn from other successful SaaS projects is to start by picking an SaaS program you already enjoy using. Then, find two or three competitors to the software that you picked and give them a whirl, writing down specific things that grab your attention and are related to why you do or do not like the respective application.

It is rare for an application to grab my attention with regard to usability and performance, so when it does happen, I make sure to take the time to find out why because I usually learn something from it. A task-management application grabbed my attention recently, mostly because I find this genre of applications rather dull. However, the level of usability involved with this particular SaaS application was striking.

I spent about two hours navigating the application, testing its limits and evaluating the accessibility of its multitude of features. I like applications that have an extraordinary amount of features built in, yet I expect them to still be fairly lightweight. For this reason, I am critical of UI design. If the interface is not well organized, an application with many features becomes a nightmare to use, because it's impossible to find what you are looking for half the time. My evaluation of this particular SaaS application led me to conclude that it was the unique and unconventional organization of the UI compared to other task-management applications I have installed that allowed me to enjoy working with it.

10. Build usable prototypes

Is a prototype still a prototype if the same code used to build it is also used to create the final product?

The answer to this question is absolutely. In software development, the customer usually wants to see a proof of concept prior to investing in the development of the real thing. A prototype is nothing more than a proof of concept. Smart SaaS developers leverage the time they are provided for creating the prototype. Consider how much can be accomplished during this time:

  • Design and lay the architectural foundation.
  • Create the SaaS database schema by building a custom XML DTD, and use the XML as the prototype's data source. (The schema can be imported later into the database engine and converted to the real thing in a matter of minutes.)
  • Create the full-size application's organizational package, interface, and class structure, even if the files do nothing more than declare the class name and the interface it implements initially.

There are a number of advantages to this approach, but two are key to successful SaaS: You have a massive head start when the time comes to build the actual product, and conflicting design patterns and poorly designed architectures will usually show their ugly faces when the prototype is built on top of them. The necessary modifications can then be made before actual product development commences.


It is important to recognize that the world of software development evolves so rapidly that the key elements for successful SaaS development will eventually change — probably sooner rather than later. The secret is to stay abreast of the evolutionary process and position yourself to stay ahead of the curve.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=Open source, Cloud computing
ArticleTitle=Top 10 tips for writing successful Software as a Service