It depends a lot of you size and your project scale. But here are a few advices. Do not pay by day/hour if you can avoid it. Define small deliverables then ob

It depends a lot of you size and your project scale. But here are a few advices. Do not pay by day/hour if you can avoid it. Define small deliverables then objective tests to validate them and attach fixed price to each piece. You don't have to come up with it out of thin air, the contractor is supposed to do that with you. You don't have to define all of them up front neither. In fact, they will probably change during the project and the contractor will adjust the price knowing better about the project after the first few deliveries. Do not let the definition of success be blurry. But don't set everything in stone. Do include a clause about the code license. If you have zero IT skill, get the help of somebody who does to do so, as well as set your expectations and filter the contractors. Sometimes it's best to hire a contractor... to hire a contractor. I know, I know. In my book, a good contractor will: - not sell you the moon, but will tell you what's possible, what's not given your constraints, and the relative cost of it. I regularly tell my customers to chose a better, cheaper solution than hiring me. - help you set a priority list rather than a schedule. I'm not an oracle, I can't give you an exact delivery date for each component. But I will make sure we get them in the most valuable order. - not give you answers right away, especially deadline and price. I can take several (sometimes billable) hours up to several days with a customer to understand the project and assess this. - will tell you honestly "I don't know", "I will have to look it up", "It's not in my skill set, I'll need the help of X". I may tell a customer I'll need a designer, and a week to research a topic before starting to code. - communicate clearly. Bad communication is a red flag. There are very good coders that are bad at communicating. As a contractor I don't just code, I extract your needs, wants and constraints to adjust the work regularly. This is what "agile" mean. Not tooling, scrum, or other gimmick. Regular proper communication, and adjustments. - will not talk about good and bad, but cost/benefit ratio. You can request everything you want, the question is can I build it under your conditions. - will talk about his preferences and specializations and advocate them when relevant. But will understand if a different technology is needed for the job. I love Python, and will advise you to use it. I don't like JS. I will code in clean proper JS for a Web UI. - will be honest about their needs: schedules, payment, communication, ethics, channels or technology use. E.G: I don't do military/banking related contracts and refuse missions that use some languages such as Lisp, Haskell or PHP. You have the right to want them, there are other contractors that will do it for you just fine. - not be cheap. Well, just like with lottery, you may be incredibly lucky. But I would not base my life choices on such hopes. I'm often booked for months in advance and know the market prices I can expect. I won't bother negotiating. - will be interested in your project itself. Even when I don't work on something, I'm always happy to hear about what the project became 6 months later. I like my job. You are not committed to anything until you sign something. So go shopping. Change your mind. We are used to talk to many customers, and only land a few jobs. That's also why we are expensive: we include that in the price tag.