5 Technologies Every Software Company Must Build or Buy to Launch a Software Product - Successfully

Irrespective of the size and stage of your company, if you are bringing a software application to market, there are 5 pieces to the picture that must be mastered - built or bought - to get the job done right. 

Whether targeting consumers, businesses or government,  for purposes of productivity, entertainment, security, development or services infrastructure, 'code' running on computers has to be properly developed, delivered, installed, used and understood - all in support of a business model and satisfied customers.  

Reflecting on the last 28 years of building and running software/web businesses (5 of them), and delivering roughly 30 core software titles spanning commercial shrink wrapped titles, web-based applications/services and enterprise software platforms to millions of users, I see with great clarity a set of  5 requisite components for product completeness and viability. I also speak of direct experience on the coding side, having personally written and delivered the first and second-gen versions of many of these applications.

While some of these elements may take on larger or smaller roles in support of a business model, they each must be addressed and given adequate consideration early enough to not only meet launch schedules and budgets, but most importantly to ensure a rewarding and successful user experience - one that sustains customer satisfaction - and your business model. Said differently, a breakdown or inadequacy in any of the following 5 areas will result in lost opportunity and reduced market share.

Each of these 5 technologies is worthy of a book of content (each topic is, in fact, the subject of many popular how-to books). However, my goal here is to recognize this as a collective set of requisite elements of the software commercialization life cycle - where each is approached with the respect and design preparation as if it were a unique technology component of a software product overall. 

Here they are, and perhaps with the exception of the application itself, not necessarily in order of importance:

1) The Application - Whether the platform target is Windows, Mac, mobile device or the web, the application needs to be secure, bug-free, and intuitive. Whether the application is written in basic, visual basic, vb.net, c, c++, c#, php, java, html, javascript, perl, python, embedded code or combination of the foregoing, quite simply, the application must do what a customer has been lead to believe it should do, and result in value through its use.  

If the application runs locally as a stand-alone client, or client speaking with server counterpart, or full cloud application with local interface and control, the application must also be free of code that allows infiltration, compromise and security breach by the bad guys.  

Being bug-free is a tall - but required - order as well. Defensive coding combined with thorough alpha and beta testing programs will nail 90-95% of the bugs, but typically your customers tend to find them quite quickly as well. Being responsive to those customers when they find issues with the application, is the end-cap measure to a bug free program.

As for being intuitive, well there are no prescriptions or etched-in-stone principles to deploy. However, smart and sufficient use of tool-tips, hover hints, logical imagery/icons, menu structure, feedback mechanisms, undo-redo, persistent global vs project settings, most-recently used file lists, context-sensitive pop-up menus, left vs right mouse click actions, drag-drop, application notifications, shutdown-recovery, etc.., can go a long way to meeting customer expectations and maximizing end-user productivity with your application.

It may not be necessary or appropriate to have all of these features present, but careful consideration of each should be made at design time relative to target platform and overall anticipated usage context of the application.

2) The Installation. AKA... software deployment. This is the set of processes - typically initiated by the user - that make your software available for use. It includes commands for execution and places all supporting systems for the application in place. Simple or complex, and highly dependent on the target host environment, the essential trigger(s) to instantiate the application must be made available to the user. Typically this is done either by placing icons on the end user desktop, start menu, application menu, installed as browser add-ins, mobile applications on the device or perhaps just a link or bookmark to a website. 

In the shrink-wrapped world, this is mostly the product of using popular installation tools such as InstallShield, Wyse, XCode command line tools for the Mac or Microsoft's installer on Windows. (of course there are many others) Today, with the explosion of web-based software and mobile applications, installation has become a device or browser specific process, sometimes governed by the rules of the device or the pseudo 'walled-garden' environment the application is designed to run in - e.g. Apple iOS.

 It is important to recognize that the installation is the initial enabler or organizer of the operating environment for the licensing system to function. For instance, requesting a serial number, and storing installation/uninstall information and system identification data to the registry or device app manager needs to be done.

3) The Licensing System, This is one of the tougher ones. It certainly isn't rocket-science, but it is tricky. Most companies that provide software do so to create or support a revenue stream and business model. If that business model is to be protected, the IP that is the software must be protected from unauthorized use, and ensured that where use, perpetual or termed, is paid for and that money has actually been received. While licensing is almost inextricably tied to e-commerce and payment systems and processes, those are so broad and normally entirely outside the application context that we can treat them as a peripheral technology - not a piece of the software. (I do recognize that many games now have integrated payment models within the game itself to remove advertising or purchase player upgrades).

Licensing systems essentially need to accomplish 2 fundamental things: 1) anti-piracy and 2) adherence to usage model. This is a combination of rules and enforcement - both interpreted and managed at the code level. This is what makes it so tricky. On the one hand the software is now mostly on the end-user system - which the end-user owns, but the software must be managed as if it is not the property of the end-user. And, quite frankly, it isn't. Most, if not all commercial software applications and certainly web-based applications remain the sole property of the software company or developer. When purchased, the software is merely 'licensed for use' by the end-user. Usually, and again almost always, what the end-user 'produces' with the licensed software is, and will remain, the sole property of the end-user. This is the distinction that is made clear in all those End User License Agreements "EULA" that you so rapidly click through on installation.

In any case the anti-piracy mechanisms, and this is a sweet spot for me, having helped pioneer the digital rights management "DRM" wave for software back in 1992-98, by developing one of the earliest DRM  software development kits for windows - called TimeLOCK. It was this period of time that I was fortunate to get involved with industry leaders, chairing the Software Information Industry Association's e-commerce and DRM advisory board for 2 years, to help set some of the earliest standards for digital content licensing, customer privacy, and end-user system 'friendliness'.

The bottom line was that using encryption and stored licensing status on the end-user system was good but not sufficient for the hacker and cheater world. And with the dot-com boom of the late 90's, most DRM systems for application software (running locally) ended up becoming one based on product activation. I am sure you are familiar with that. The product activation approach simply puts the primary licensing status and validation mechanisms in the cloud - usually on the software company servers. This is quite a scaleable model, widely adopted and secure. If your application is targeting traditional client environments such as on the Mac or Windows, you will at least need to consider this approach, among others if you want to minimize threat of piracy and wholesale theft by download. 

If the target system is in the cloud, as many web-applications are, then your world got a little safer, but still remains in need of an "access verification" mechanism. But in this case, you create and control the gate. A little fancy secure PHP and SQL code to manager customer rights, information and passwords, and a minimal access control system is in place.

If the application is in the banking, payments, insurance, national security domains, the minimal system is not sufficient. But in these cases, there are numerous and significant access control protocol and mechanisms that can be administered - and should. 

4) The Help System - How about a breather? I mean at least one piece of the puzzle that can be delivered without approaching the domain of rocket science. The help system is key to your end user finding the functionality he or she needs to be productive with the application. It is largely composed of introductions, overviews, screen shots, how-to's, tutorials and background information made and presented in a format and location the user can easily and conveniently access.

There are many documentation tools that help format and integrate these help systems, but at the end of the day, simply building the information is the brunt work here. The interesting trend over the last 10 years or so, is that almost all applications today have moved their help systems online. Also, noted is the extensive use of blog-based support and user feedback forums that are so instantly searchable and available to the end-user.

Typically, a triage approach to end-user help is most appreciated by users - that means having some immediate guidance available in the application that is context sensitive will put out the most immediate and basic need - think tool-tips, and hover hints. Second level of the triage might be local help files that cover the basics of layout and primary use of the various menu items and default action of mouse and keyboard. Lastly, would come the full enchilada of in-depth help system which is now a days much better served and maintained if online and accessible by the end-user from within the application.

If the application by the way, is popular enough and has been around long enough, you might even get third party companies calling you to develop material - multimedia or published books. Think Lynda, or book publishing sites that provide both how to books and training videos. I do recommend that the software company pursue a regular video how-to publishing schedule to establish a growing library of useful walk-through's that help users be the most productive. This is especially important if the product involves advanced technology or enables development of sophisticated systems. My current software company, TinMan Systems does just that, with its software platform for machine intelligence - videos are a must with break-through or new concepts. 

5) The Download Process - Seemingly obvious and often overlooked as being simple, this is still a technology and requires an approach and model. While it is certainly feasible to deliver an application via a zip file in response to a clicked link on a website, most efficient and scale-able software fulfillment models involve a chunk of server side code and database integration to support a smooth customer delivery experience and a way to track the success or failure of a download attempt.

Most applications today include high resolution graphics and video elements with supporting files, sample projects, and licensing elements. Delivering these in a stream of bits either from a website or physical media involves delivering a full and sufficient payload. Dealing with connection speed and continuity along with ensuring all the bits get delivered, with some server side validation, is key to a successful experience.

With adequate delivery, web based customer and partner relationship management systems - along with web analytic systems - can be updated in real-time to provide tremendous insight to the company for adequately supporting the customer and the product, as well as maintaining the web systems that are responsible for delivering the product. 

Here again, a key process can be administered quite effectively with a well-designed use of a typical web stack - such as HTML and JavaScript on the front end and Perl/PHP/MySQL (or derivative) on the back end - serving a centralized licensing system, customer relationship management system and web analytics system.

CONCLUDING: In conclusion, I have presented above what I believe are the key pieces of the software equation as not only a way to reflect on a long and learned career in computer software, but also as a way to appreciate all those late nights for software developers, product management folks, entrepreneurs and even those 800 pound gorilla teams that produce the software we all just expect to ... work. 

Please feel free to reach out to me personally with comments or questions - or if you would like some advice based on my experiences.

And please check out my current company, TinMan Systems, and its rapidly growing software platform for building and deploying intelligent systems - and how about that Internet of Things, sensors, robotics and autonomous vehicle software? I will soon begin publishing the ongoing and learned path on these things. Website: www.tinmansystems.com 

Thank you, Karl