Most hiring mistakes are not about the developer. They are about picking a model that does not match the shape of the work. A fixed scope billed hourly drifts. Open-ended product work squeezed into a fixed quote gets fought over. Here is how to tell them apart before you commit.
Project based: when the outcome is known
Use this when you can describe the finished thing. A five-page website, a checkout flow, a specific integration. The scope is agreed up front, one developer owns the outcome, and the price does not move unless the scope does.
- You can write down what done looks like
- The requirements are unlikely to change mid-build
- You want one number before you start
The failure mode is scope you thought was obvious but never wrote down. Spend the extra hour on the brief.
Hourly: when the work arrives in bursts
Bug fixes, small features, support on a product you already run. Nobody can scope a month of unknown issues, so you pay for the hours used and stop when you want.
- The work is reactive or irregular
- You need someone available, not booked solid
- You want to start small and see how it goes
Rates start around ten dollars an hour and rise with seniority. A senior developer at a higher rate is often cheaper per outcome than a junior at half the price.
Monthly: when the product keeps moving
A developer working with your business month to month, in your tools, on your roadmap. This is the right model once there is always a next thing to build.
- The backlog never empties
- You want continuity and context, not a fresh briefing each time
- You are growing and not ready to hire in-house
The question that usually decides it
Can you write the acceptance criteria today? If yes, go project based. If no, and the work is occasional, go hourly. If no, and the work is constant, go monthly. Most teams start with one defined project and move to monthly once they trust the developer.
Tell us what you are building. We reply by email, usually the same working day.
