Simplifying Commercial Software Development?

NerdOfPrey writes "I'm nearing completion of development and testing of my first self-produced commercial application, but just beginning to appreciate the full bevy of other associated tasks ahead. There are help files to compile, end user license agreements to write, a website to create - and a secure online payment system to identify and integrate, automated installers to build, logos to design, marketing, and so on. Are there any good web-based single sources of information covering these sorts of issues? I've never had to do all of these things myself in the past; a comprehensive 'small developers guide' would be of considerable benefit." So is there anything besides "imitate, guess and pray" for all the tasks that come after the app is written?

Comments

Maybe I am spoiled

[MerlynEmrys67]

But I wouldn't consider development/testing to be done without the help subsystem (RoboHelp - nroff depending on your OS) or the Installer (./config, Wise, installshield) written. In fact those would be two subsystems that I would think were critical to even get it into testing (how did you/your testers install the darned thing in the first place)

Frankly (and thankfully) I've never hand to deal with these issues... If you are a small shop, look into the tool chains that are used to develop the systems that you need - and use them

Re:Maybe I am spoiled

[i.r.id10t]

Unfortunately, that is the way quite a few F/OSS work. So the code gets written and fixed and worked on, but no one seems to want the "lowly" job of writing good clear documentation, and keeping it current with the current release of the software.

I don't mind RTFMing as long as the FM has been written and I can find it....

Re:Maybe I am spoiled

[hey!]

Well, I agree, but there are tough choices to make. You can't do as much or as well in every area as you'd like.

How you focus your efforts depends on you customers -- it is important to know them, and it is important to choose them wisely and appropriately for the product's life stage.

Intuitively, you want as many customers as possible, and truth be known I'd never turn a customer away if he really wanted to spend money. But you have to understand the adoption cycle for new software products and target different audiences accordingly.

The first customers you get are the early adopters. No question, you need a working installer for these folks, but understand these people are people who are attracted to novelty. To meet the needs of early adopters, you need features, features that will establish your market position. These people need lots and lots of attention too. So, you focus on making a featureful, stable product that does cool things. You will focus your attention on finding customers that meet the early adopter profile, who are willing to put up with a bit more aggravation in order to be able to do something new and different.

You also have to understand that these people will want new bells and whistles and will have strong opinions about what should go into the product. It is very important to be responsive to these people without letting them dictate the contents of the product (unless they want to pay for customization). Nonetheless, it follows in this early phase that you will be adding features at the highest rate ever duing the product's life cycle.

This poses a huge documentation challenge, especially if you have a model of producing a comprehensive guide to every single jot and tiddle of the software. Furthermore this comprehensive "reference guide" only has limited value to the early adopters, who will explore every nook and cranny of the software on their own. So, if you can maintain a comprehensive reference guide to your software's features as you add them -- more power to you. At the very least it can help you with product testing. But in this product life phase, your reference documentation is probably not going to be very polished, or terribly useful to a non-initiate. In truth, early adopers are not manual readers, they're tinkerers.

What the early adopters need is something different -- not a guide to what every datbase field means or what the action of every widget is. What they need is a guide to accessing the power of your software -- the stuff that sets it aside from the competition. Thus I'd say something like a collection of success stories and recipes for doing the cool stuff in your software is a higher priority. It also can serve as marketing literature in this phase of adoption.

Eventually, your product starts to become more mature. When people say "can it do X", you no longer run into your hole and code up the changes, because it already does. Now is time to slow down the rate of change and adopt longer release cycles with more limited feature additions. Now is the time when you can attempt to create a comprehensive product manual without your documentation guy having a nervous breakdown.

The good news is now you are ready to make some real money -- in the vast majority of the market that are not early adopters. However, they won't be satisfied with just a recipe book for doing cool things. They'll want a manual they can have next to their computer that tells them exactly waht that widget in your GUI does -- they are not attracted to the adventure of twiddling it and discovering what it does. Here's where that incredibly amateurish refernce guide you put together comes in handy. Don't even think of showing this piece of crap to a pragmatic adopter (much less a skeptic). Take it to a professional tech writer, and have them produce a real manual. Rather than keeping a writer on staff before you have any revenues and while the product is changing rapidly, hire one on a project basis when the product is stabilized and bringing in money. Eventually, when you are bringing in dough on a regular basis, it will be cheaper to hire one, but for now just buy their services.

No-hoper

[hopethishelps]

This guy doesn't know which way is up.

He says he's a go-it-alone commercial developer and he hasn't a merketing plan? Well, he won't make that mistake again.

He says he's "nearing completion of development and testing", and he hasn't got any help files compiled yet? Sounds like he's not ready to start final testing.

It's so easy for somebody to write some code and kid himself he's starting a viable business. Probably happens somewhere every week. I don't know why /. eds though it was worth a story, though.

EULA madness

[valshaq]

...end user license agreements to write...

O my god! Do you want to play Microsoft or what? It is NOT needed/useful to waste your time setting up such rubbish that obstructs potential users.

Re:selling your product

[cerebralpc]

Can I ask how many units have you sold?