Contents
01Compare the right numbers
The salary is not the cost. Add employer payroll taxes, health benefits, paid time off, a laptop, software licenses, and whatever recruiting cost to find the person. Add the management time, which is real even when it is unbudgeted. Then divide by the hours of useful output you can actually supply them with in a month.
Against that, a contract has a rate and an end date. Higher per hour, lower per month of commitment, and no cost at all in the months you do not need it. Neither is cheaper in general; they are cheaper in different situations.
02One person is one set of skills
A working product usually needs backend, frontend, some design, some infrastructure, and someone who notices the security and accessibility problems. Very few individuals cover all of that well, and the ones who do are expensive and hard to retain at a company where software is not the product.
This is the failure we are called in to repair most often. The hire went well, the first version shipped, and then the gaps arrived at once: the deploy nobody can reproduce, the database with no backup tested, the dependency three years out of date, the accessibility issue in a form a customer complained about.
Ask what happens the week your developer is on holiday and something breaks. If the honest answer is nothing happens, one person is a single point of failure, not a team.
03When hiring is the right answer
Three conditions, and you want all three rather than two.
- The work is continuous: a product that changes weekly, not a project that finishes.
- Someone can judge the output, either internally or through an arrangement where an outside engineer reviews the code.
- Domain knowledge compounds: the hard part is understanding your business, and that knowledge is worth keeping in the building.
04When a contractor is the right answer
When the work has a beginning and an end, when the stack changes between projects, when you need several skills for a few weeks each, or when nobody internally can tell good code from code that merely runs. The last case is the one people underweight: hiring someone you cannot evaluate is a gamble, and a bad first technical hire is slow and expensive to undo.
The honest middle path is common and works well. Have a contractor build and document the first version, then hire to maintain and extend it once the shape of the ongoing work is visible. That sequence costs less than hiring first and discovering the scope afterwards.
05What to insist on either way
The repository sits on your account from the first commit, not on the contractor's and not on the employee's personal one. Every service is registered in the company name with billing on a company card. The deploy process is written down and has been run by a second person at least once. And something restores from a backup on a schedule, because an untested backup is a belief rather than a backup.
These sound obvious and are the four things most often missing when a client moves between contractors, or when a developer leaves on short notice.
06How we work with this
Our software work starts at $18,000 and discovery is fixed price at $2,400 over three working days, producing the scope, the integrations and a price band with the factors that move it. You own the repository and the accounts from day one, which is what makes leaving us straightforward.
We also do the review arrangement for companies that have hired and want an outside engineer looking at the work: a regular read of the code, the deploys and the dependencies, with a written list of what to fix. We would rather set that up than argue that your hire was a mistake.
Questions
Is offshore hiring a cheaper version of this?
It changes the rate, not the structure of the decision. The same questions apply: is the work continuous, and can anyone on your side judge the output. Time zones mainly affect how quickly a question gets answered, which matters more than most people expect during a launch.
What if we hired already and it is not working?
Start with a read of the code and the infrastructure by someone outside, before any personnel decision. We have seen both outcomes: a capable developer with no review and no priorities, and a codebase that genuinely needs replacing. Those look identical from the outside and are handled very differently.
Will you hand over to our own developer later?
Yes, and it is designed for from the start: your repository, your accounts, a written deploy process and documentation that assumes the reader is not us. A contractor who makes leaving difficult is telling you something about the next two years.
Where we can help