if it is a web app, then you will need use a setup table, which flag the features for different users. something like different level users. or, use user roles, and limit roles' access rights. but, if there are too many customized versions, the app will be too complex to control.

good luck

david

Hey John,

Long term, application development is about saying no more than saying yes! 37 Signals have published a book called Getting Real which covers this in detail - it's also a pretty interesting read

Getting Real: The Book by 37signals

If the app is web based, and you really do need to customise versions, it's possible but needs a little work to get it right.

Can you be more specific about what the app does and an example of a customisation?

Hey thanks for sharing that link.

Its a real estate web app - turnkey site that allows full management of properties as well as staff/content etc

Im finding it too difficult to try and "customise" each application per user. Trying to stay on top of each different version is starting to do my head in!

Try this: TortoiseSVN | The coolest Interface to (Sub)Version Control

Per-customer customizations will become impossible to manage pretty fast. You have to balance being responsive with staying afloat.

Start thinking about what kinds of features you're willing to put on your product's roadmap for future development. Listen to all the feature requests you get, but only implement the ones that fit your roadmap. For each new feature, think about whether everyone will want it. If some customers won't, implement in a way that makes it configurable. Have an administration layer where the customer can configure how they want your software to operate, and make application behavior conditional based on configuration.

Put out releases, and train your customers to look forward to them. Unless a customer is dead in the water, don't make on-demand fixes that cause your customer base to become out of sync with the production version of your software. Whenever you make an emergency change, track it carefully so you don't accidently leave it out of your next release.

Decide how many prior versions you're going to provide support for. Train your customers to install your releases regularly. If you're still supporting a prior version, they'll assume they can upgrade directly from whatever version they're running to your current version without going through all the in-between upgrades.

I think you need to change the way you think about your core work. In a large software company, developers for the baseline application usually aren't the same people who implement and customize. (And you always hope you don't have to customize.) Your top priority has to be working on your baseline, to benefit your future customers and grow your business.

Try not to use the word "customize" with your clients. That's what brings up your "how do I ask them to pay?" issue. It's okay to ask a client to partner with you, to fund your new development. Otherwise you might not prioritize that feature high enough to implement it near-term. For them, the advantage is getting to have lots of input on the spec, and getting to beta test it, and implement it first. They're your PARTNER. It's your software; customization on the other hand just makes you a programmer on their staff.

(Version control to manage your source code is a must, but it sounded to me like you were asking more release management, configuration management, product management type questions.)

Patey88

Hey thanks everyone for your input - Ive learnt a LOT just from this thread.

Im going to eliminate "client customisations" completely - and focus on "product features".

Ill itemize what I feel are the core features of the product, develop those and for any other "change requests" Ill simply say no. For what its worth, Id rather not be dealing with difficult clients and multiple versions just to make a few extra dollars - its just not worth the stress.

Thanks again for your thoughts and suggestions. For anyone else who is experienced in this area, Id love to hear your opinions also.

Thanks! WF kicks ass!

One additional question - how is it possible to have members paying a monthly fee for upgrades? What if there isnt an upgrade for the month?? How do I handle/implement this?

There are two approaches to software management of this kind. The "out of the box" option where you customer adapts to the software and the "enterprise solution" where your software adapts to the customer. Both have their pros and cons but ultimately work. What won't work is trying to do both.

In your case I'd suggest the "out of the box" option where your customers are forced to adapt to the way the software works would be far more appropriate. That's not to say you don't improve it over time to provide a better experience but you define "the way" and teach people how to use/do that.

And now on to your most recent question about charging -

Old style business software (the kind that actually got setup/installed in their office before this "interweb" thing came along) was sold for a setup fee and then a yearly support and maintenance contract (usually about 20% of the initial software fee). This covered the cost of the initial work that was required and then paid for upgrades and support over time (plus profit if you did it right).

Modern web-based software rarely needs setup work or if it does then it tends to be stuff that the user can do for themselves given reasonable documentation. As such no one expects to pay the initial upfront fee, although you should certainly consider it if you are providing training/configuration or any kind of "get going" service. Then most people charge a flat monthly fee or a simple set of monthly fees in tiers depending on the level of functionality people want. See the 37Signals collection of web-apps for great examples - Simple small business software, collaboration, CRM: 37signals

With this in place you need to balance feature releases to keep as many people happy as possible. That includes existing and potential customers. Existing customers will expect to see improvements in the system, even though arguably they are paying the fees for the system as is it's still a given expectation. Potential customers have reasons for not already using your software. That could just be that they don't know about it but once they do it's probably because "your software doesn't do X". Those X-features should generally be what drives you development since you are knocking down the barriers for more and more people to get on board.

And on the subject of keeping existing customers happy. You *have* to apply the 80/20 rule to this and accept that some won't be happy. Let's say you have 10 customers. 8 of which want Widget X but are generally happy and the other 2 want Widget Y and Widget Z respectively and are threatening to leave if they don't get them. Build Widget X and accept the loss of the high maintenance customers otherwise you're just training customers that they have to kick up a stink in order to get what they want.

Ideally you want to have a product roadmap laying out what's to come in the next few months. It should factor in enough time for bug fixing and support work, thus making it realistic and going some way to avoid shipping late all the time. This sets expectations with your customers (potential and existing) so they know what is to come and when. This goes a long way towards avoiding the situation where customers are constantly demanding this or that feature and putting your development into reactive mode.

Hope some of that helps,

Andy

Damn, forum ate my post - just wanted to thank you Andy!