Article
Turn a Client Site into Saleable Software
Imagine you're a Web developer (you may not have to think too hard!), and you've been hired to develop an ecommerce module for -- say -- a bed and breakfast.
You've spent months preparing a site that will let guests book rooms and submit their credit card deposits online, and allow the bed and breakfast staff to manage their own online content. The company that hired you is a small, typical, independently owned bed and breakfast, and it's certainly not the only one in the market for such a product. Sounds like an opportunity!
Opportunity Knocks
A marketable product can offer your organisation better economies of scale than straight consulting work provides. Software costs lie almost completely in the product's development, and increase little whether you sell that product to six people or to sixty. A successful product gives you a better return on your investment than can standard consulting, and frees up your time to focus on larger issues.
If the potential product is a module you've developed for a client, you've done a lot of the work already. In the case of the bed and breakfast ecommerce module, you've already had a company finance its development. If you've done a good job, you've already got a happy client and a glowing reference. From there you can easily develop a case study to support your product. You already have a familiarity with the bed and breakfast industry, so you can relate to your target clients.
You already have a lot of elements working for you, and you haven't even started!
Before You Commit
How do you know if it's worth quitting your day job to sell the product you've developed? Here are a few key questions that you should ask yourself before you take the plunge:
Who owns the intellectual property?
Did you secure the rights to the code you developed? Was this clearly spelled out, one way or the other, in your legal contract?
How specific is the niche?
Is the product you've created general enough to be attractive to many companies? You've created a product that's useful to bed and breakfast accommodation owners; could it also be useful to boutique or small chain hotels? Or is what you've created too specific for use by anyone other than people who run bed and breakfast accommodation?
Is the market big enough?
Is the potential market for your product large enough to keep you in business? Obviously the more generic your product can be made, the better -- but if there really are enough bed and breakfast owners clambering for your product, then go for it.
Is the market accessible?
Many factors can affect the accessibility of a given market, so make sure you do your research first. There may be thousands of people wanting cheaper diamonds, but when De Beers controls nearly all the known diamond mines in the world, you may not have much luck meeting that demand.
How saturated is the market already?
There may be a need within the market, but someone else may already be filling it. Do a Google search for the type of product you want to offer. Will you have five or five hundred competitors? If there are enough potential buyers to go around, you may be fine. But make sure you have a plan that allows you to stand out from the herd.
What's special about your offering?
Whether you're attempting to fill a currently unmet need, or you're trying to break into an existing market, ask yourself, "what do I offer that's unique? Why should buyers pick this product as opposed to a tried-and-true brand name alternative?" A new product from an unknown company needs to have an edge on the competition in order to succeed.
Where is the market going?
Sure, there may be a market for your product now, but is it just a fad? Look at how much the cell phone industry has evolved in recent years. Samsung has recently released a phone that incorporates a seven-megapixel camera. Imagine what would happen to a company that still focused on offering superior battery life! Obviously it's still an important feature, but it's not driving the market anymore. To stay competitive, you've got to keep changing with the market, or, better yet, lead the change. Again, do your research. To be successful, your product must meet not only the market demands of today, but market demands in the years to come.
What resources are available to you?
Be honest with yourself. Do you have money to invest in marketing a new product? Do you have investors willing to back your product until it takes off? How much time can you devote to this new venture? 100%? 50%? Do you have marketing experience -- or someone in mind who could give you sound advice? And is this really the best time for you to launch a new product? You may not have all the strategic answers just yet, but being realistic about your resources will prevent some costly false starts should you decide to take the plunge.
If you've thought through all these questions and still feel confident in your product, the only thing left to do is to get out there and do it! Once you've decided to launch your product, it's time to start thinking about how you'll do so. And that's where the fun begins.
Choosing a Business Model
So you've got your product and you've decided to put it on the market. Great! Consider, though, that software is a complicated commodity. To market your product successfully, you need to select the right business model.
There are nearly as many business models out there as there are companies that use them. The trick is to find a basic model that fits your needs and highlights your strengths, then customize it to suit your product. Let's take a closer look at the major types of business models.
1. The Professional Open Source Model
In an open source model, you basically give away your software. Anyone who wants to use it can download the product for free, and because the source code is open and visible, users may be able to edit your software -- though this depends on the licensing scheme you've chosen. Among the many open source license schemes available are the GPL, LGPL, BSD, and many more. The issues of open source licensing are intricate and specific, and as such, these legalities won't be explored here.
Now, you might think that open source licensing doesn't sound very profitable, but it can be. You're still the creator of the product, so you're the one users will turn to for training and support. And because you're giving away the initial product, you may not need a lot of up-front capital to invest in marketing and sales. JBoss, a highly successful international open source software company, has been profitable from day one because founder Marc Fleury created a business model that met the need for an alternative to the high-priced application server software that was on the market at the time.
Giving away quality software is a great way to develop a large user base because it involves less financial risk for the consumer. Many consumers are cautious about buying from a small company for fear that it will go out of business and leave them stranded with a buggy product and no support. Giving away the source code can help to negate those concerns.
Offering an open source product often also entails increased user investment, which can reduce the development costs for you: because users can tweak the source code themselves, you have the opportunity to create a strong development community around your product. With more people working out the bugs, writing plug-ins, and adding features, the costs of continued development and programming efforts are much more manageable.
Of course, by providing users access to the product's source code, you make public any special secrets you may have used in writing the software. Depending on how you choose to license the software, it's possible that users may be able to modify your software to create a new, competing product. Because they can see the source code, malicious users may more easily be able to find the holes and hack your product (though this doesn't discourage hackers attacking the proprietary products that are frequently their targets). And if your product is exceptionally good and easy to use, you may find that you have many users, but no one ever comes to you for training or support.
2. The Traditional Model
This model is called traditional for a reason: most software companies use some form of the traditional model to launch their products. With this model your source code is compiled into binary format, to keep it hidden. The resulting proprietary software is then sold as-is, and the original creators maintain control over -- and responsibility for -- any modifications or patches that are required and/or developed.
It can take a lot more time and resources to get started using the traditional model: developers have to aggressively market their products to make sales, particularly in the case of brand new products from unknown companies. But the benefit is that you do have the advantage of making money directly from those sales, and you may have better control over the ways in which customers use your product.
In some cases, keeping your source code hidden can be very important. JBoss didn't worry, because they weren't doing anything revolutionary with their software; their success was due to the fact that they did it well, and were the only ones distributing it for free. But if you're product is really unique, you may decide that it's best to protect the source so that other companies can't see how you created the software.
Hiding your source code can, in some cases, more effectively protect the product against the efforts of malicious users. That said, an approach that promotes security through obscurity should not be relied upon -- the dedicated hacker will often find a way into well-protected products. Hiding your source can also make your job harder: it can be more difficult to find weaknesses in the build if the code is inaccessible.
Under the traditional model, the product's owner is the only source of the product, which can make that company more attractive to large buyers than a professional open source company might be. However, because you control exclusive rights to the source code, it can be an expensive and daunting task to keep the product current. Since you don't have independent users submitting patches or add-ons, you must employ a team of developers to fix the bugs and improve functionality.
You'll also have your work cut out for you convincing skittish consumers that your company will be around to provide support and upgrades in the years to come. If they're going to invest money in your software, customers need to know you're not about to go out of business and leave them stranded.
3. The Free Express Versioning Model
A variation of the traditional model occurs when a company creates two versions of its software: a full version for purchase, and an express version, with limited features, for free distribution. If your software lends itself to the easy development of an express version, this can be a useful marketing tool. As an example, think how many computers have the free Adobe Reader installed, and how useful and powerful that has made Adobe's purchase product, Adobe Acrobat.
The potential downside, of course, is that many users will simply stop with the express version and never bother to purchase the full product.
4. The Hybrid Model
Not all successful software companies have such clearly defined business models. Depending on the nature of your software, it may be best to use some form of hybrid model.
One such model involves selling the actual source code for your product. In this model, you still make money up front, and you'll still have the expense of marketing the software, but your consumers will rest a little easier knowing that, if all else fails, they've got the source code to your product. It also provides the opportunity for users to fix their own bugs and add to the growth of the product as a whole.
Using this approach, you still maintain control over the licensed version of the product, and although you run a greater risk of having someone rip off your source code than you might under a traditional model, you have some legal protection against unlicensed versions of the product.
Australia-based Atlassian has created a highly attractive issue-tracking software package, and has had success selling the source code along with the product. Because the product is targeted at highly technical users, the ability for clients to customize their installations of the software via the source code is a strong selling feature. Also, since it's not a product that's useful to private individuals, Atlassian doesn't have many concerns about a deluge of unauthorized users taking illegal advantage of the open source code.
The opposite model to this? Give away your product, but protect the original source code. With this approach, you lose the benefits of user input that are inherent in open source models, but you maintain proprietary control over your product, which can be seen to increase the value of your company as a whole.
5. The Hosted Model
A final model that works well for certain types of software is the hosted model. When you host your own software, you are essentially leasing access rights to outside users. By acting as host, you retain full control over the source code and any updates or improvements. If the product is intended only to run on your own servers, you need not worry about excessive compatibility issues to make your software marketable.
Charging a monthly leasing fee offers the financial advantage of a more consistent income than does the traditional lump-sum-at-point-of-sale model, and offers improved economies of scale: typically, you can host many clients at the same cost as hosting one.
However, hosting the product means that you have the added responsibility of ensuring that the host servers are up and running twenty-four hours a day. You'll also have to work a bit harder to convince consumers that your business is stable. Consumers who are cautious about purchasing a software package from a young company will be even more hesitant to place their trust in your continued ability to host their valuable data.
Which Model is Best?
Which of these options is the right one for you? Obviously, the answer to that question depends on a variety of factors. There are highly successful companies running on each of the business models we've discussed. They are successful, in large part, because they took the time to weigh their options and select the right models for their endeavors.
When evaluating your options, here are some questions to ask:
- How will you fund your product? Do you have capital already set aside, or investors lined up to support your product's launch? If not, the traditional or hosted models may not be the best options for you. If you want to sell, you have to spend, and if you cannot spend, it may be wisest to look at an open source or hybrid model in which you can build a user base quickly and cheaply, making money from support once you have a userbase that has invested in your product.
- Who are your competitors? The level of competition in the market makes a difference! If the software you've developed is, for example, a new operating system that will compete against Microsoft and Apple, you'd probably be wise to take Linux's lead and go the open source route. If, however, your competition is largely fragmented and comprised of medium to small companies, a traditional model may well be the best way to go.
- How unique is your code? Have you hit on something truly unique? Is your software dependent on a "special sauce" you'd like to keep secret? If you're worried about losing control of your product, it might be best to use a traditional or hybrid model that would keep your software proprietary.
- Does your product lend itself to hosting? Hosting has its advantages, but it's not always appropriate. Adobe Acrobat, for example, would simply not work as a hosted module. But if you've written email-marketing software, or a content management system targeted at mom and pop stores, leasing the software and hosting it yourself may offer the best solution for your users.
- Who will use your product? Never forget to keep asking -- and reminding -- yourself who will use your product. This, perhaps more than anything else, should guide you in deciding how to present and distribute your software. Will you target technical users who would want to have access to the source code, or business users who'd rather just type in a password and start using the product? Is your software useful for individuals, small businesses, or large corporations? Will users need to access a hosted version of the product online, or is yours an application that will be best installed locally on each user's computer?
As you ask yourself these questions, it should become clearer which type of business model will work best for your product. Remember that these are not ironclad rules: the above is just a series of guidelines. Do your research on other companies in your field. What do they do right? What could they do better? Is there a need that's not being met by current business models? Many companies have had a rough start and turned out OK, but that doesn't mean you can't learn from their mistakes and give yourself a winning edge!
Once you've chosen a business model, it's time to take the next step, and consider how you'll market your product.
David is the founder of