What should I bid to implement a fairly simple Python scheduling system?
June 10, 2013 3:42 PM Subscribe
Tomorrow morning I'm meeting with someone to talk about implementing a local scheduling/database application. Most everything I know about the project suggests it's something I could do in my sleep. Thing is, I desperately need the money, I don't know how much to "bid," and I have a long history of undervaluing my work. How much should I ask for?
Without going into too much detail, the project in question involves keeping a database of people, their schedules, and some miscellaneous flags about them.
The end user has a number of templates he can request, each of which stored internally. Basically, the templates themselves should be stored in a separate database, and be kept just as modifiable as the person list.
When a template and a time is requested, the program will look up the necessary flags by number and type in the template list, then select that number of people in the people database by which flags they have and availability. Then the list will be presented to the user, with contact information etc.
Visible to the user, the program has to:
- Have an interface for entering, modifying and otherwise maintaining people's data.
- Have an interface for entering, modifying, and otherwise maintaining the templates.
- Have an interface for applying templates to the person list and getting an appropriate number of people for the event.
Of course, the program has to be designed, written and documented. I'm implementing it in Python, because it's easy to use, relatively easy to read, and is almost made for this kind of thing. The number of people is not large enough, I think, to require the use of a database solution, so I was considering just using pickle for persistence. Scalability is not an issue, to my knowledge.
They are not concerned, to my knowledge, about platform, the program is to be local and not web- or network-exposed, and they haven't said anything about user interface so I'm assuming at this point that a console window is appropriate. They just need something that works, and very soon.
I have no earthly clue how much money I should ask for to do all this. The guy was considering "outsourcing the work to India," but is convinced he should ask around locally first. Thing is, I've got a big car expense that needs to be handled soon. This also has the potential to blossom into part time work for them. I'm sick of working in pizza delivery and need something else (such work being ultimately responsible for my car troubles), so I don't want to bid too much and wreck my chances. But I don't want to bid too little, if I can help it, because I need the car repair and it'd be nice to be able to leave Dominos for a bit.
Nothing about this project seems out of reach for me; if something unexpected crops up, I know enough to search for solutions. Any of you who are more experienced with this kind of work, what should I be asking for? If it turns out the project requires a reasonable GUI, how much more?
Without going into too much detail, the project in question involves keeping a database of people, their schedules, and some miscellaneous flags about them.
The end user has a number of templates he can request, each of which stored internally. Basically, the templates themselves should be stored in a separate database, and be kept just as modifiable as the person list.
When a template and a time is requested, the program will look up the necessary flags by number and type in the template list, then select that number of people in the people database by which flags they have and availability. Then the list will be presented to the user, with contact information etc.
Visible to the user, the program has to:
- Have an interface for entering, modifying and otherwise maintaining people's data.
- Have an interface for entering, modifying, and otherwise maintaining the templates.
- Have an interface for applying templates to the person list and getting an appropriate number of people for the event.
Of course, the program has to be designed, written and documented. I'm implementing it in Python, because it's easy to use, relatively easy to read, and is almost made for this kind of thing. The number of people is not large enough, I think, to require the use of a database solution, so I was considering just using pickle for persistence. Scalability is not an issue, to my knowledge.
They are not concerned, to my knowledge, about platform, the program is to be local and not web- or network-exposed, and they haven't said anything about user interface so I'm assuming at this point that a console window is appropriate. They just need something that works, and very soon.
I have no earthly clue how much money I should ask for to do all this. The guy was considering "outsourcing the work to India," but is convinced he should ask around locally first. Thing is, I've got a big car expense that needs to be handled soon. This also has the potential to blossom into part time work for them. I'm sick of working in pizza delivery and need something else (such work being ultimately responsible for my car troubles), so I don't want to bid too much and wreck my chances. But I don't want to bid too little, if I can help it, because I need the car repair and it'd be nice to be able to leave Dominos for a bit.
Nothing about this project seems out of reach for me; if something unexpected crops up, I know enough to search for solutions. Any of you who are more experienced with this kind of work, what should I be asking for? If it turns out the project requires a reasonable GUI, how much more?
You need to estimate it before you can price it. There are two general ways of approaching this sort of thing, hourly, which is usually referred to as time and materials, and fixed-bid. If you don't care so much about a particular hourly rate, fixed bid is the way to go, but you still want to try and determine what your hourly rate will be before you agree to it, just in case you might find yourself short of motivation to spend those last few low-paid hours fixing bugs caused by dumb requests, etc. A common structure is fixed bid plus time and materials for changes. Regardless of how you structure it, get as much of the requirements in writing and agreed upon as you can possibly get before you sign anything or say yes. If you can't nail it down now, you're in for pain. It's hard to charge time and materials for changes when you can't agree on whether or not a particular request represents a change, so keep that in mind.
posted by feloniousmonk at 4:08 PM on June 10, 2013
posted by feloniousmonk at 4:08 PM on June 10, 2013
Do you actually have to give him a number then and there? Position this as a fact finding exercise, tell him you need to price it fully after the conversation, incorporating the additional information you've gathered and then come up with a time budget and cost it properly.
Use the conversation to talk to them about different options you could build into this thing - bare bones, more functions, fancy...with different numbers attached to each.
Also, if they want to bring down the price don't give them something for nothing. They want to pay less you get better payment terms or else drop something that is nice to have but not required for this thing to work properly.
Finally, if he's talking about getting quotes from India do not position yourself somewhere where you try to beat these. You, being local, are a completely different business proposition - they can talk to you, you are readily available for other jobs and can use your understanding about their organisation in that way, you can guarantee there won't be any language, cultural problems, you're in the same timezone and you can guarantee continuity what with it only being yourself....
posted by koahiatamadl at 4:12 PM on June 10, 2013 [1 favorite]
Use the conversation to talk to them about different options you could build into this thing - bare bones, more functions, fancy...with different numbers attached to each.
Also, if they want to bring down the price don't give them something for nothing. They want to pay less you get better payment terms or else drop something that is nice to have but not required for this thing to work properly.
Finally, if he's talking about getting quotes from India do not position yourself somewhere where you try to beat these. You, being local, are a completely different business proposition - they can talk to you, you are readily available for other jobs and can use your understanding about their organisation in that way, you can guarantee there won't be any language, cultural problems, you're in the same timezone and you can guarantee continuity what with it only being yourself....
posted by koahiatamadl at 4:12 PM on June 10, 2013 [1 favorite]
In my experience, scheduling and calendar apps have a nasty way of being trickier than they first look.
posted by thelonius at 4:17 PM on June 10, 2013 [8 favorites]
posted by thelonius at 4:17 PM on June 10, 2013 [8 favorites]
Best answer: Does this exist? Something off the shelf that he hasn't come across?
If not, or you think there's major room for improvement in what's out there, and there is a niche market, look at this as an opportunity to create something to sell to others.
Since BOTH of you are inexperienced in development, how about structuring it as an hourly project, with very small increments and constant feedback.
You retain rights to the code, and he is free to take the work product to others to continue.
So maybe start off with a billable 4 hours - 1 for a meeting and 3 for design documents/mock ups/logic flow charts.
Then have another meeting which starts off with you being paid. Go over what you have, give him a copy, and agree that you will bill for X hours to produce Y part. Make it as small an increment as feasible, such as just the initial person data entry form.
Meet again, get paid, test what you've done, agree on the next thing to implement, lather rinse repeat.
Think about what can go wrong 5 or 7 years from now when he calls you saying he did nothing different but it's now broken.
posted by Sophont at 4:44 PM on June 10, 2013 [1 favorite]
If not, or you think there's major room for improvement in what's out there, and there is a niche market, look at this as an opportunity to create something to sell to others.
Since BOTH of you are inexperienced in development, how about structuring it as an hourly project, with very small increments and constant feedback.
You retain rights to the code, and he is free to take the work product to others to continue.
So maybe start off with a billable 4 hours - 1 for a meeting and 3 for design documents/mock ups/logic flow charts.
Then have another meeting which starts off with you being paid. Go over what you have, give him a copy, and agree that you will bill for X hours to produce Y part. Make it as small an increment as feasible, such as just the initial person data entry form.
Meet again, get paid, test what you've done, agree on the next thing to implement, lather rinse repeat.
Think about what can go wrong 5 or 7 years from now when he calls you saying he did nothing different but it's now broken.
posted by Sophont at 4:44 PM on June 10, 2013 [1 favorite]
Response by poster: This is recognied thelonius, yes. I'm helped a bit, though, by the fact that everything they've said so far suggests that the system only needs to treat schedules in terms of raw availability, i.e., going by what hours people say they're available when turning up people in searches. If it turns out the project needs more actual scheduling features I'll be sure to change the bid appropriately.
posted by JHarris at 4:47 PM on June 10, 2013
posted by JHarris at 4:47 PM on June 10, 2013
I'll second thelonius on that one.
(Also, and I know this is skirting the edge of the question, I'll suggest that you use an actual database backend for persistence, even if it's just SQLite. There is an awfully good chance you'll otherwise wind up doing from scratch a lot of what that'd give you for free.)
posted by brennen at 4:48 PM on June 10, 2013 [3 favorites]
(Also, and I know this is skirting the edge of the question, I'll suggest that you use an actual database backend for persistence, even if it's just SQLite. There is an awfully good chance you'll otherwise wind up doing from scratch a lot of what that'd give you for free.)
posted by brennen at 4:48 PM on June 10, 2013 [3 favorites]
Response by poster: So maybe start off with a billable 4 hours - 1 for a meeting and 3 for design documents/mock ups/logic flow charts.
This, and other requests to look at it in terms of hours worked and multiplying by a cost-per-hour, sound like a useful pricing strategy. Except I don't know how much I should be charging to be competitive, generally.
posted by JHarris at 4:50 PM on June 10, 2013
This, and other requests to look at it in terms of hours worked and multiplying by a cost-per-hour, sound like a useful pricing strategy. Except I don't know how much I should be charging to be competitive, generally.
posted by JHarris at 4:50 PM on June 10, 2013
Best answer: Seconding the "do not try to beat offshore developers" advice. koahiatamadl put it very well.
If you haven't done something extremely similar to this before, I'd go with hourly pricing. I don't think you can do this in your sleep, not because you're not a good programmer, but because there is a lot of potential for ambiguity and scope creep in what you've described.
Here's a way to go about coming up with an estimate and proposal:
Start by determining what the skeleton of this app will entail. That skeleton should do the bare minimum for your client to be able to try it. e.g.:
Keep doing this until you have enough iterations to fulfill the all of the basic needs that your client stated he needs. It's fine if an iteration seems "thin." Although it might feel like there's not much work there, when you add to a system there's always a certain amount of refactoring and retesting you need to do to fit new functionality into existing code. This is often not trivial.
Plan on having the client try each iteration. This has a few different benefits:
Go through each iteration and estimate how long each will take and make sure you pad those hours, not because you're being dishonest, but because software estimation is a black art, especially for a first-time consultant. You are almost certain to underestimate.
Pick an hourly rate. Something like $30/hour sounds very reasonable for a domestic developer. More is still reasonable, but if you're uncomfortable about asking for money, just start with a nice average price like that. Don't bargain yourself down in advance.
When you put together your proposal, state your rate and estimates for each iteration. List the deliverables that the iterations are intended to ultimately reach. However, keep the descriptions of the iterations beyond the first very loose and brief and state that they may change as you and the client work through them.
I'd even offer to let him drop out at any time, although he still has to pay you for the work you did. I'd avoid just letting him pay as soon as everything's done. Either ask for biweekly payment or for half of the estimated cost up front, then the rest at the end.
posted by ignignokt at 5:02 PM on June 10, 2013 [5 favorites]
If you haven't done something extremely similar to this before, I'd go with hourly pricing. I don't think you can do this in your sleep, not because you're not a good programmer, but because there is a lot of potential for ambiguity and scope creep in what you've described.
Here's a way to go about coming up with an estimate and proposal:
Start by determining what the skeleton of this app will entail. That skeleton should do the bare minimum for your client to be able to try it. e.g.:
- A user will be able to enter data (just each person's first name and last name for now) for people via a command line interface.Then, work out what the next pass at the app will contain, for example, being able to enter person fields other than first and last name or being able to define a template by specifying fields in a particular order. Keep in mind that this iteration should be demoable.
- A user will be able to apply a basic fixed template to a list of people that they select from the command line.
- The result of the application of the template to list will be displayed in the console.
Keep doing this until you have enough iterations to fulfill the all of the basic needs that your client stated he needs. It's fine if an iteration seems "thin." Although it might feel like there's not much work there, when you add to a system there's always a certain amount of refactoring and retesting you need to do to fit new functionality into existing code. This is often not trivial.
Plan on having the client try each iteration. This has a few different benefits:
- It gets the client invested in your work and creates empathy for you and gets you in touch with your client's needs.(This is usually called an "agile" development process, which your client may like if he's into either modern project management and/or buzzwords.)
- It diffuses suspicion that you're not doing anything or that you wasted time.
- It allows the project to change course when a feature turns out to be too expensive for the amount of value it provides or if unanticipated needs are discovered.
- It is something offshore developers cannot do easily.
Go through each iteration and estimate how long each will take and make sure you pad those hours, not because you're being dishonest, but because software estimation is a black art, especially for a first-time consultant. You are almost certain to underestimate.
Pick an hourly rate. Something like $30/hour sounds very reasonable for a domestic developer. More is still reasonable, but if you're uncomfortable about asking for money, just start with a nice average price like that. Don't bargain yourself down in advance.
When you put together your proposal, state your rate and estimates for each iteration. List the deliverables that the iterations are intended to ultimately reach. However, keep the descriptions of the iterations beyond the first very loose and brief and state that they may change as you and the client work through them.
I'd even offer to let him drop out at any time, although he still has to pay you for the work you did. I'd avoid just letting him pay as soon as everything's done. Either ask for biweekly payment or for half of the estimated cost up front, then the rest at the end.
posted by ignignokt at 5:02 PM on June 10, 2013 [5 favorites]
Most everything I know about the project suggests it's something I could do in my sleep.
I'm a software engineer. I've managed project teams and have also done a bit of freelance work in my time. One thing I'll say, is that "could do it in my sleep" is how a lot of projects look before you've really sat down to seriously evaluate them.
If you haven't sat down to map out the project, you could be in for a lot of pain.
Personally, I didn't like setting prices until I knew how many hours I was looking at (which I know seems backwards to some folks, but that's how I liked to do it).
posted by toomuchpete at 5:13 PM on June 10, 2013 [2 favorites]
I'm a software engineer. I've managed project teams and have also done a bit of freelance work in my time. One thing I'll say, is that "could do it in my sleep" is how a lot of projects look before you've really sat down to seriously evaluate them.
If you haven't sat down to map out the project, you could be in for a lot of pain.
Personally, I didn't like setting prices until I knew how many hours I was looking at (which I know seems backwards to some folks, but that's how I liked to do it).
posted by toomuchpete at 5:13 PM on June 10, 2013 [2 favorites]
Response by poster: I understand toomuchpete, that's why I said suggests. I am fiercely on the lookout for things that could broaden the scope and take it into Intractable Quagmire territory. But it seems they really need something very soon, that could help me in keeping it under control.
posted by JHarris at 5:19 PM on June 10, 2013
posted by JHarris at 5:19 PM on June 10, 2013
Response by poster: And I have been mapping the project, and have even written a few lines on my own time. So far any terrible difficulties ahead in the project have yet to reveal themselves to me, but I am vigilant.
posted by JHarris at 5:20 PM on June 10, 2013
posted by JHarris at 5:20 PM on June 10, 2013
Best answer: If neither you nor they are very experienced doing consulting programming, there's a couple things you should really focus on doing. Otherwise: misery.
1) Find out up front what the minimum useful product is; the absolute least functionality you have to get up and running to make them see value from the project. No bells or whistles, the absolute minimum.
2) Estimate the hours to build that, ask for a quarter up front, bill for half on demo (so that's 3/4), and bill the rest of it on delivery of something they can run on their own.
Okay you do this because it gets them something fast, it gets you money fast, and it gets both of you accustomed to working with each other in a low risk kind of way.
Proceed with further development following the same pattern: what is the minimum set of "next" features necessary? Estimate that. Charge up front, on demo, and on delivery.
Short cycles.
Very important: never EVER start work on the next cycle until you've been paid for the previous cycle. And never deliver working product with less than 3/4 of the cycle's billings in your pocket. That keeps your receivables under control, their billings under control, and also makes sure that your post-delivery risk is only 1/4 of a cycle quote if they flake.
Small bites, baby steps, whatever you want to call it. Take it super easy.
posted by seanmpuckett at 6:15 PM on June 10, 2013 [3 favorites]
1) Find out up front what the minimum useful product is; the absolute least functionality you have to get up and running to make them see value from the project. No bells or whistles, the absolute minimum.
2) Estimate the hours to build that, ask for a quarter up front, bill for half on demo (so that's 3/4), and bill the rest of it on delivery of something they can run on their own.
Okay you do this because it gets them something fast, it gets you money fast, and it gets both of you accustomed to working with each other in a low risk kind of way.
Proceed with further development following the same pattern: what is the minimum set of "next" features necessary? Estimate that. Charge up front, on demo, and on delivery.
Short cycles.
Very important: never EVER start work on the next cycle until you've been paid for the previous cycle. And never deliver working product with less than 3/4 of the cycle's billings in your pocket. That keeps your receivables under control, their billings under control, and also makes sure that your post-delivery risk is only 1/4 of a cycle quote if they flake.
Small bites, baby steps, whatever you want to call it. Take it super easy.
posted by seanmpuckett at 6:15 PM on June 10, 2013 [3 favorites]
seanmcpuckett's suggestion is basically how agile development was initially conceived. The notion is that clients often don't know what they want until they try a prototype and see what's missing (or how much they can do with what they have). Billing in short, week-to-month-length chunks, with a chance for the client to evaluate the software at each step, is a good value for the client. It's also good for you, because you can (a) get paid as you go and (b) make sure you're building what you want, so that they're more likely to hire you again in the future.
posted by novalis_dt at 7:10 PM on June 10, 2013
posted by novalis_dt at 7:10 PM on June 10, 2013
In my industry, projects are used budgeted at $150k per software engineer per year.
Assuming 40 hour weeks and 50 weeks per year, that's $75 an hour. Start there for an hourly fee?
posted by sparklemotion at 7:11 PM on June 10, 2013
Assuming 40 hour weeks and 50 weeks per year, that's $75 an hour. Start there for an hourly fee?
posted by sparklemotion at 7:11 PM on June 10, 2013
Pick an hourly rate. Something like $30/hour sounds very reasonable for a domestic developer. More is still reasonable, but if you're uncomfortable about asking for money, just start with a nice average price like that. Don't bargain yourself down in advance.
I'd say $30/hr is bargaining yourself down pretty far to start. This is going to vary some by region - any idea what's "normal" in your area? I'm mostly familiar with rates in NYC and SF/bay area so I can't help you much with specific #s here. Overall seems like you're getting good advice, I'd emphasize demoing early/avoiding scope creep where at all possible.
posted by ethand at 7:24 PM on June 10, 2013
I'd say $30/hr is bargaining yourself down pretty far to start. This is going to vary some by region - any idea what's "normal" in your area? I'm mostly familiar with rates in NYC and SF/bay area so I can't help you much with specific #s here. Overall seems like you're getting good advice, I'd emphasize demoing early/avoiding scope creep where at all possible.
posted by ethand at 7:24 PM on June 10, 2013
In my industry, projects are used budgeted at $150k per software engineer per year.
Assuming 40 hour weeks and 50 weeks per year, that's $75 an hour. Start there for an hourly fee?
That's all well and good, but the original poster is taking this job as a step up from a pizza delivery job. With respect, people coming off a pizza delivery job don't bill $75/hour.
Anyway, the thing is, the shorter a job is, the less of a big deal underbidding is - if you're working a full-time salaried position, then you're locking yourself in for a year or more, but if with this job, the worst thing that can happen is you get underpaid for a month or something. You'll be able to renegotiate things if you end up doing part-time work for them.
Also, I would just assume you're going to have to do a GUI and bill appropriately, unless these are computer people; the average person looks at a dos prompt and gets weirded out, and then there's all the usability issues around cutting and pasting, backspacing, etc. Not worth it.
posted by inkyz at 7:38 PM on June 10, 2013 [2 favorites]
Assuming 40 hour weeks and 50 weeks per year, that's $75 an hour. Start there for an hourly fee?
That's all well and good, but the original poster is taking this job as a step up from a pizza delivery job. With respect, people coming off a pizza delivery job don't bill $75/hour.
Anyway, the thing is, the shorter a job is, the less of a big deal underbidding is - if you're working a full-time salaried position, then you're locking yourself in for a year or more, but if with this job, the worst thing that can happen is you get underpaid for a month or something. You'll be able to renegotiate things if you end up doing part-time work for them.
Also, I would just assume you're going to have to do a GUI and bill appropriately, unless these are computer people; the average person looks at a dos prompt and gets weirded out, and then there's all the usability issues around cutting and pasting, backspacing, etc. Not worth it.
posted by inkyz at 7:38 PM on June 10, 2013 [2 favorites]
Response by poster: It's been a month, here's an update:
1. Meeting with them to talk about it, the project morphed into Access and Visual Basic, instead of Python. I'm sure I can handle it though, and told them. They seemed to be enthusiastic.
2. But then they said they'd get back in touch with me "in a day or two." Something about having to communicate with a home office in New Mexico or Arizona or somesuch. I called back in two days and they said they were running a "background check" that could take a week. I called back a week later and THIS time they say that actually there was no guarantee they had gotten the contract for the project for which my work would be done, but they should know "by the end of July."
I feel like I've been bait-and-switched. They keep stringing me along, but they haven't actually said no yet. Meanwhile I keep delivering pizzas.
posted by JHarris at 1:16 PM on July 11, 2013
1. Meeting with them to talk about it, the project morphed into Access and Visual Basic, instead of Python. I'm sure I can handle it though, and told them. They seemed to be enthusiastic.
2. But then they said they'd get back in touch with me "in a day or two." Something about having to communicate with a home office in New Mexico or Arizona or somesuch. I called back in two days and they said they were running a "background check" that could take a week. I called back a week later and THIS time they say that actually there was no guarantee they had gotten the contract for the project for which my work would be done, but they should know "by the end of July."
I feel like I've been bait-and-switched. They keep stringing me along, but they haven't actually said no yet. Meanwhile I keep delivering pizzas.
posted by JHarris at 1:16 PM on July 11, 2013
Response by poster: Anyway, the result is, I don't really know how useful the information I've gotten here is, since it seems disassociated with whether I'm getting the work or not.
posted by JHarris at 1:18 PM on July 11, 2013
posted by JHarris at 1:18 PM on July 11, 2013
Response by poster: (If I sound annoyed, please keep in mind that this is basically the story of my life. Getting strung along by possible employers from which nothing ever comes. At least Dominos is giving me slightly-less-than minimum wage.)
posted by JHarris at 1:19 PM on July 11, 2013
posted by JHarris at 1:19 PM on July 11, 2013
Doh. I'm sorry that fizzled out. But at least they didn't stiff you after you had already done a lot of work for them!
If you'd like to get started on programming work, maybe trying a job on elance is a good way to go. They require escrows, so you know that clients are at least serious and have some money.
posted by ignignokt at 9:53 PM on July 12, 2013
If you'd like to get started on programming work, maybe trying a job on elance is a good way to go. They require escrows, so you know that clients are at least serious and have some money.
posted by ignignokt at 9:53 PM on July 12, 2013
This thread is closed to new comments.
posted by oceanjesse at 4:00 PM on June 10, 2013 [1 favorite]