Recruiting Partners

I am starting a portal development business and I am thinking about recruiting two or three other programmers. I am having a tough time deciding how to pay these people. I developed one portal that has been field tested and is currently working. However, it needs a lot more work. So, If I recruit others and thy polish it up and then we sell that version to someone let's say for 100 units, how do I pay these people? Additionally, with little more work we could sell the new portal to someone else for the same price.

I could give them something very little but that wouldn't be fair. I would really appreciate it if you have any ideas or suggestions to help me with this issue.

Thanks,

Pay them by how much progress they get done. If the portal has alot of files, pay x dollars for every page completed. If there isn't many, pay them x cents for every line written.

-Jordan

There are lots of decisions you get to make as a hiring manager, the least of which is exactly how much to pay by what measurment. First you have to decide how you are going to ask them to do the job. Ever read RFCs? They are bloated documents painful to read because of the apparent tedious detail where every little microscopic topic is covered in depth. Guess what? That is what you need to do to provide unambiguous instructions on how to write what you need. Think it is faster to write it yourself? Probalby is. On the other hand, if you provide vague general 'do this' instructions, expect that each programmer on this planet (and probably the majority of alien programmers as well) will implement the code differently, each with different assumptions and each with different behaviour. There is a decent probablility that the majority of these different implementations will be a correct interpretation of your vague instructions, so how do you evaluate which is best? How do you even test them? Once you have ironed out how much free will your developers will have, you get to decide how much supervision you are going to give them. Closely supervised developers (who don't just quit) tend to be very risk averse individuals and are never likely to put any changes into production as they don't want the responsiblity if something goes wrong. Lightly supervised developers are very likely to put stuff into production without bothering to inform you, potentially providing massive support and customer relation nightmares. Once you have waded through these decision trees then you get to decide what sort of developer you are looking for. The market place tends to set prices for the different classes of developers, though finding developers who will get paid in some unknown point in the future when working on closed-source projects is generally quite problematic even if you specify a much larger rate to compensate for the risk.

Generally speaking, you get what you pay for. Pay little, expect less.

Thank you for your comments. I have to spend some time defining their accomplishments and how they will be measured.

I was thinking about tying their comensation to their coding (comments, clarity, efficiency, modularity), to the bugs they might produce, how well their code fits with the overall project etc.

Thanks,