Build, buy or borrow?
That is the question when creating Web site applications
By Scott Brinker
OK - you've decided no more wimping out on the Web with brochureware or half-baked databases. You're ready to create a site that really does something: transactions, customer service, market research, affiliate partnerships - all the meaty e-business applications.
The question now is, how do you make it happen? Do you:
a. develop these applications yourself with an internal team or an outsourced shop;
b. purchase off-the-shelf software that you operate and maintain on your own servers; or
c. link to an application service provider (ASP) who lets you rent their apps remotely?
Or, in other words, do you build, buy or borrow? The answer depends on a lot of factors: the nature of your business, the types of applications you need, your budget, your long-term strategy, competitive pressure and time to market.
On one hand, you cannot afford to relinquish a present or future core competency, nor can you surrender competitive advantage in a critical channel. On the other hand, if you get entangled in the wrong web, the distraction from business essentials may prove to be fatal.
Core, critical or cool?
Not all applications are equal in the eyes of the astute e-businessperson. There are:
- Core business applications - Web services that are the heart of your business.
- Critical business applications - Web services that provide an essential channel for your business.
- Cool business applications - Web services that enhance your business.
For example, eBay's auction technology is a core business application. Without its auctions, eBay has no business. Apple Computer's Web store isn't its core business - it manufactures computer hardware and software - but the store is a critical business application. (You wouldn't want a channel generating millions of dollars of revenue to flake out at 2 p.m. on a Tuesday, would you?) On the other hand, cool applications shouldn't be dismissed. Collectively, they add substantial value and differentiation.
The first step in evaluating a build, buy or borrow decision is to make a list of all the possible Web applications that you and your team would like to have over the next 12 to 18 months. Storefronts. Contests. Auctions. Supply chain management. Discussion groups. Questionnaires. Product configurators and calculators. Brainstorm together and let your vision and imagination run wild.
Group these applications under the categories of core, critical or cool and order them by descending strategic priority. You may want to organize them in a spreadsheet, which will make the next steps easier. If so, list the applications in one column and, next to each application, create columns for
- Target time to market
- Initial development budget
- Ongoing operations budget
- Need for differentiation
For now, assign each application a rating of 1 to 10 in each of these columns, where 1 represents the low priority or minimal budget allocation and 10 represents an urgent time to market, significant budget or major importance of differentiation for competitive advantage. This will be your guideline for matching your applications with the pros and cons of build, buy or borrow.
Building the best
If time and money were of no consequence, you'd almost always want to build your own Web applications. By creating them from scratch, you can design them to fit your precise needs and behave just the way you dream up. But, alas, custom-built applications are expensive, and they can take substantial time to complete.
Pros of building:
- Application tailored to your market
- Technological barrier to entry
- Tight integration with your systems
- Control over application evolution
- Add equity value to your company
Cons of building:
- Longer time to market
When is building worth it? Certainly in the case of your core business: If your Web application is your business, it had better be good and under your total control. And critical applications are sometimes good nominations, but not always. For instance, your phone system is most likely a critical application for your business. But did you build a totally custom telecommunications infrastructure? Probably not.
There is an ever-increasing array of off-the-shelf software products that give you "plug-and-play" Web apps. For commodities such as catalog storefronts and collaborative discussion groups, the choices are legion.
Pros of buying:
- Potentially quick time to market
- Less expensive than custom-built
- Easier to evaluate before committing
- Inherit a "bundle" of features
Cons of buying:
- Reliance on third-party for success
- Possible integration issues
- Limited customization
- Lack of control over feature set
- Minimal competitive barrier to entry
The upside of these packages is significant. When you do decide to purchase, you can pretty much have it in your hands immediately. And you (should) only pay a fraction of what it would cost you to develop the whole thing from scratch. You also probably get a lot more bells and whistles than you'd have if you built it yourself.
Unfortunately, the devil's in the details. It might be a great package, but will it integrate with all the other applications on your Web site? You're also taking a risk on the manufacturer. Will they even be around in a year or two? Will they evolve this product - and keep it bug-free - or will they discontinue it after the next release? And, of course, your competitor could go out tomorrow and purchase the exact same package. This may not matter if the application is serving a back-office role. But if it's a visible customer service, you need to weigh the value of differentiation.
Borrow the baby
The beauty of the Web is its totally distributed architecture. You can spread pieces of your Web services across dozens of different servers and visitors will never know the difference (if you maintain a consistent user interface).
This has given rise to an entirely new model of software licensing: application service providers (ASPs). They run applications for you on their servers, keeping you safe (hopefully!) from all the headaches of operating the apps yourself. This approach has many of the pluses and minuses of buying software, with a few twists.
Pros of borrowing:
- Very quick time to market
- Lowest initial cost
- Minimal operational headache
- Easy to evaluate before committing
- Inherit third-party relationships
Cons of borrowing:
- Reliance on third party for success
- Minimal systems integration
- Limited customization
- Minimal competitive barrier to entry
- Ongoing costs may get expensive
ASPs seem to make the most sense for cool business applications - non-critical opportunities to provide added value to your customers or your organization. Think low-budget, short time frame services that don't require market differentiation, like contests, polls and questionnaires.
Mix and match?
On paper, it might make sense to mix and match these different approaches. Perhaps you want to build one application and buy another.
But be careful - this doesn't magically work in real-world implementations. The two issues that must be addressed when combining different kinds of applications are: (1) consistency of front-end interface and (2) consistency of data maintained on the back-end.
Scott Brinker is co-publisher of iDecisionMaker. He has served as CEO of a software development company and most recently as president of an Internet development firm. Since 1996, he has created and implemented Internet technology solutions for clients including CBS Sportsline, Office Depot, Fujitsu, Tribune and the Miami Dolphins.