1. how complex will the statistical calculations be? is it just a matter of figuring out one big formula or is there actually a ton of number-crunching involved?
2. since clients will be able to access the data, i'm assuming this requires security, login checks and registration etc. correct? basically there will be a publicly-accessible front-end and an administrative backend?
3. will the report interface be in html or do something like pdf generation?
4. how many administrative pages will they need to be able to add/edit data? for example, they'll obviously need to be able to enter student records and the accompanying data. but what about editing the dropdown menus of schools and that kind of thing? or will you be pre-entering that info directly in the database yourself and not have it editable by the client?
5. and on a fairly basic level, how many pages do you think the site will consist of?
that's the kind of info i'd try to get out of a client before putting together a bid, so that will help me give you a good guess! :)
1. Most of the calculations will probably not be *that* complicated, but there will be a large number of them.
2. Security and login checks are necessary, most definitely. User registration will be done on the administrative side, however. (When a user is created for entering their data, they will be given a username and password). Also, and this is important, they must be able to specify which reports are available on a per-user basis. For example, if he is only helping a student apply for schools and not handling their financial situation, all the financial breakdown reports would be irrelevant. Or, a type of report may be available, but a set of data may be unreportable. For example, they might record the data associated with a financial award for internal tracking purposes, but not wish to show this to a client for whatever reason (perhaps a bad award that they are still negotiating).
3. Report interface can be in html to avoid the added complexity of pdf generation. However, these reports should not be completely crappy when printed.
4. They will have to enter student data, school data (which changes based on fiscal year), application data (matching up school and student, along with all information specific to that application, such as whether or not they were accepted). They will definitely need access to editing the dropdown list of schools and such, or I'm going to end up having to go in and change it by hand constantly.
5. Well, let's see. Clients will have a reports interface, with probably only a couple of reports available. They may be able to review their data in case of any inaccuracies (SAT score, etc.), see their list of applied schools and the status, and finally (if they are the right kind of client), see reports on each financial award from all the different schools. If they have multiple awards, they should be able to compare them side by side. Perhaps they will have the choice of which ones to see side by side.
On the administrative side, they will need a data entry page for each table, they should be able to see the reports that clients will be able to see, a report that summarizes all the data for the fiscal year (organized by school and organized by student -- really 2 different reports), displaying some of the more basic statistics, and then probably 2 more reports with less data displayed but with more statistical analysis, again by school and by student. Possibly more later if he asks for more functionality once it's in place, which is likely.
So, I guess that would be at least 12 pages, roughly.
the admin area seems pretty complex for a small site. the big items there are granular security on a per-user basis and the ability to be able to administer their own menus and such. also, designing nice printable reports in html can be tricky, so i'd rate that pretty high as well.
if this was a client i knew could afford it, i'd probably bid a little under $3000. however, since you said it's someone who's used to you working for a lot less, and also the fact there will probably be continual work involved, i'd probably shoot for more in the $1000-1500 range. you could also estimate your time at $25ish an hour and see if it falls within that as well. i find that even estimating $25/hr (which is really low for dev work, but on a freelance project that's standard), you'll probably find you only come up with half that amount. that's why hourly sucks. ;)
After typing out the requirements, I think I'm inclined to go with something closer to the first number you gave me. Especially since I think I will have a friend help me spiff up the interface for a cut. It's going to be a lot of work. I will try to show him the work that needs to be done to make something like that (or offer a scaled down version without all the bells and whistles for less money). If he doesn't like it, oh well. I mean, I'm interested in doing freelance, but I really wouldn't mind passing up this job, as he is kind of a pain in the ass...
Actually, first, I think I'm going to ask him what kind of budget he is looking at for something like this, and if he lowballs, I'll just tell him I can't do it. If he's close, we'll negotiate.
Once the work is complete, do you offer a support contract? I'm just afraid that once it's done, he'll still ask for updates and changes all the time (especially if they don't cost him anything), because he's like that.
no subject
Date: 2005-05-24 11:29 pm (UTC)1. how complex will the statistical calculations be? is it just a matter of figuring out one big formula or is there actually a ton of number-crunching involved?
2. since clients will be able to access the data, i'm assuming this requires security, login checks and registration etc. correct? basically there will be a publicly-accessible front-end and an administrative backend?
3. will the report interface be in html or do something like pdf generation?
4. how many administrative pages will they need to be able to add/edit data? for example, they'll obviously need to be able to enter student records and the accompanying data. but what about editing the dropdown menus of schools and that kind of thing? or will you be pre-entering that info directly in the database yourself and not have it editable by the client?
5. and on a fairly basic level, how many pages do you think the site will consist of?
that's the kind of info i'd try to get out of a client before putting together a bid, so that will help me give you a good guess! :)
no subject
Date: 2005-05-25 12:05 am (UTC)2. Security and login checks are necessary, most definitely. User registration will be done on the administrative side, however. (When a user is created for entering their data, they will be given a username and password).
Also, and this is important, they must be able to specify which reports are available on a per-user basis. For example, if he is only helping a student apply for schools and not handling their financial situation, all the financial breakdown reports would be irrelevant. Or, a type of report may be available, but a set of data may be unreportable. For example, they might record the data associated with a financial award for internal tracking purposes, but not wish to show this to a client for whatever reason (perhaps a bad award that they are still negotiating).
3. Report interface can be in html to avoid the added complexity of pdf generation. However, these reports should not be completely crappy when printed.
4. They will have to enter student data, school data (which changes based on fiscal year), application data (matching up school and student, along with all information specific to that application, such as whether or not they were accepted). They will definitely need access to editing the dropdown list of schools and such, or I'm going to end up having to go in and change it by hand constantly.
5. Well, let's see. Clients will have a reports interface, with probably only a couple of reports available. They may be able to review their data in case of any inaccuracies (SAT score, etc.), see their list of applied schools and the status, and finally (if they are the right kind of client), see reports on each financial award from all the different schools. If they have multiple awards, they should be able to compare them side by side. Perhaps they will have the choice of which ones to see side by side.
On the administrative side, they will need a data entry page for each table, they should be able to see the reports that clients will be able to see, a report that summarizes all the data for the fiscal year (organized by school and organized by student -- really 2 different reports), displaying some of the more basic statistics, and then probably 2 more reports with less data displayed but with more statistical analysis, again by school and by student. Possibly more later if he asks for more functionality once it's in place, which is likely.
So, I guess that would be at least 12 pages, roughly.
no subject
Date: 2005-05-25 02:33 am (UTC)if this was a client i knew could afford it, i'd probably bid a little under $3000. however, since you said it's someone who's used to you working for a lot less, and also the fact there will probably be continual work involved, i'd probably shoot for more in the $1000-1500 range. you could also estimate your time at $25ish an hour and see if it falls within that as well. i find that even estimating $25/hr (which is really low for dev work, but on a freelance project that's standard), you'll probably find you only come up with half that amount. that's why hourly sucks. ;)
no subject
Date: 2005-05-25 04:17 am (UTC)Actually, first, I think I'm going to ask him what kind of budget he is looking at for something like this, and if he lowballs, I'll just tell him I can't do it. If he's close, we'll negotiate.
Once the work is complete, do you offer a support contract? I'm just afraid that once it's done, he'll still ask for updates and changes all the time (especially if they don't cost him anything), because he's like that.