Mike Lewis
New Member
Clare,
I would discourage you from using a shared spreadsheet in Google Docs or similar. Such as spreadsheet is "shared" only in the sense that more than one person can access it and edit it. It wouldn't support true multi-user processing, that it, is wouldn't prevent different users from making conflicting entries or overwriting each other's data.
The other problem is that it wouldn't properly support all the queries that you need. For example, it might let you determine which members are due for renewal, but it would simply present the results by highlighting the relevant rows in some way, when what you really need is an automatic way of generating renewal notices that can be sent to the members.
In short, you'd be stretching the software and trying to make it do things it's not designed for.
I still believe that your ideal solution would be to try to find an off-the-shelf membership package if at all possible. But you have obviously tried that approach and not found anything. That leaves the possibility of commissioning a custom product. That might well turn out to be beyond your budget, although you might find someone who can do it for an affordable price.
If you did commission a custom product, you'll find that the developer will have his or her onw views as to the choice of database and programming language. Different developers have their own preferences in that area, and know the strengths and weaknesses of their preferred products.
If you get that far, and you would like some comments on the developer's choice of language and database - or, indeed, on their overall approach, do come here and ask. I'm sure Stuart and myself (and perhaps others) would be pleased to advise.
Mike
I would discourage you from using a shared spreadsheet in Google Docs or similar. Such as spreadsheet is "shared" only in the sense that more than one person can access it and edit it. It wouldn't support true multi-user processing, that it, is wouldn't prevent different users from making conflicting entries or overwriting each other's data.
The other problem is that it wouldn't properly support all the queries that you need. For example, it might let you determine which members are due for renewal, but it would simply present the results by highlighting the relevant rows in some way, when what you really need is an automatic way of generating renewal notices that can be sent to the members.
In short, you'd be stretching the software and trying to make it do things it's not designed for.
I still believe that your ideal solution would be to try to find an off-the-shelf membership package if at all possible. But you have obviously tried that approach and not found anything. That leaves the possibility of commissioning a custom product. That might well turn out to be beyond your budget, although you might find someone who can do it for an affordable price.
If you did commission a custom product, you'll find that the developer will have his or her onw views as to the choice of database and programming language. Different developers have their own preferences in that area, and know the strengths and weaknesses of their preferred products.
If you get that far, and you would like some comments on the developer's choice of language and database - or, indeed, on their overall approach, do come here and ask. I'm sure Stuart and myself (and perhaps others) would be pleased to advise.
Mike
