Architecture of developing a Software Solution

Developing a Software Solution is a great business model and a great way to make money online. A software solution costs nothing (or very little) to distribute and support, which means all your costs are lumped in the development phase.

Once you have a solid Software solution, be it a product or a service, you can start charging monthly service fees, annual license fees and possibly a support retainer, all with a very high profit margin in the 90%+

I'd like to dedicate this post to what we believe to be the correct architecture when it comes to developing a software solution.

Before you write (or hire a software development company to write) the first line of code for you, you have to make a very important decision about how you will deploy your software solution. Yes, you have to make this decision before you write the first line of code.

Here are your four choices:

1. Standalone client application
A standalone client application is an executable file that your end-users will have to install on their Windows or Macintosh machine, prior to being able to use your product.

Users will have to download the application from your website, run the Installation wizard and keep your client software installed on their machine as long as they wish to use the product.

Once installed on their machine, users will have to click the 'Start' button (in Windows), double-click a desktop shortcut or open your product from the sys-tray to run it.

Updates to the product will have to be carefully planned and deployed to users, taking versioning into consideration. By versioning what I mean is if you end up having 5 versions of your product, you will have to support users of version 1 installing version 5 (data migration tools), users of version 2 installing version 4 and so on.

Typical examples of standalone client applications include: Microsoft Office, GMail, Skype, Games, Adobe Acrobat Reader etc.



2. Standalone Server application
A standalone server application is a collection of scripts that users will have to install on an Internet server, prior to being able to use your product.

In case users don't have an Internet server, they will have to signup for a new account with a web hosting company and install your script there.

Since there are many different server configurations (unlike client operating systems where you typically only plan for Windows support), you will have to either plan a way to support all popular flavors of IIS and Linux, or make it very clear to your users which specific flavor of Linux you support.

Typical examples of server applications include: WordPress (blogging server script), VBulletin (forum server script), iSpell (server spell checker), awstat (server traffic log analyzer)



3. Third-party Plug-in
A third-party plug-in (also known as "widget") is a piece of code that integrates with an existing product, website or service.

You will typically promote your third party plug-in on the main company's product website. Users will select your plug-in from a list of available plug-ins under the main company's product website and install it.

As long as the user keeps your plug-in installed and keeps the main product running, he/she will be able to use it.

You can create plug-ins for standalone client applications (For example: Dictionary plug-in for Microsoft Outlook, AzoogleAds plug-in for Mozilla FireFox browser) as well as standalone server applications (For example: AuctionAds plug-in for WordPress, MyBlogLog plug-in for any blog website)



4. Web-based Service
Our favorite form of creating a software solution is a web-based service.

A web-based service is a solution users can start using by simply surfing to your service web page. There's nothing to install, nothing to configure and in the Web 2.0 world, you typically don't even have to sign-up before you can experience the service.

Typical examples include: Flickr, Digg, MySpace, Hotmail, eBay and Google

We love web-based services and as much as possible, we try to convert everything we do here at Software Projects into a web-based service.



--

Why do we love web-based services so much? Here's why -

Standalone client applications: Good luck getting users to install your product on their system. Did you ever notice how the average user has 4-5 products on their system tray? And how these are typically Microsoft or as of recently Google products? There are only so many application your average user is going to be willing to install. And once you get them to install, you'll have to combat support for conflicting running product, new operating system versions and servicepacks that break your product, new version delivery, data migration and a higher end-user learning curve.

Standalone server applications: Did you ever try explaining to the average user who knows very little about server side scripts, how to install PHP 4.x, MySQL 4.x and tweak the PHP.INI file? Choose this route and you'll experience this first hand. Unless you're targeting a very specific ultra geek customer niche, getting your users to successfuly install and run your script on their servers will become your biggest nightmare. Similar to standalone client applications, you'll have to deal with conflicting services, different flavours of the operating system, different flavours of core system libraries, individual system and user level restrictions, CPU restrictions (in a shared hosting environment) and bandwidth restrictions.

Web-based services: The future is here! Seamless version and patch updates, short user learning curve, high stickiness factor and lends itself to many flexbile business models.