Hiring for a Project Rather Than a Role
Decide whether the work has a definable end. If you can specify what done looks like and will not need continuous change afterwards, contract for it. If the work is ongoing, ambiguous or will evolve with what you learn, a contract arrangement will fight you and you need an employee.
The question that decides it
People frame this as contractor versus employee, and that is downstream of a more useful question: can you specify what finished looks like?
If you can describe the outcome precisely enough that someone could build it without asking you a question every day, and you will not need substantial change once it exists, then the work has a definable end and a contract arrangement fits it.
If you cannot, either because the requirements will emerge as people use it, or because you are still deciding what the product is, then no specification will hold and a contract will produce exactly what was written rather than what you needed. That is not a contractor failing. It is the arrangement working as designed.
The useful distinction: a contractor is accountable for delivering a specification. An employee is accountable for the outcome, which includes noticing the specification was wrong.
That difference explains most of the disappointment in this area. Companies contract for something they could not specify, receive what they asked for, and conclude the contractor was poor when the arrangement was the mismatch.
Duration is a weak proxy. Six months of well-specified work contracts fine. Two months of undefined exploratory work does not.
What to get right if you contract
Specify what done means, in testable terms. Not build an app. A list of things a user can do, with acceptance criteria someone else could check. Vagueness here becomes disputes later and both sides lose.
Decide who owns the result before you start. The most common failure is not code quality. It is that the app ships, the contractor leaves, and nobody internally can change it. Assign an owner in advance, ideally someone who reviews work as it is produced rather than receiving it at the end.
Treat handover as a deliverable. Documentation, a walkthrough, deployment access, and a period of availability for questions. Scope it and pay for it. Handover assumed and unpaid is handover that does not happen.
Get the intellectual property terms right at the start. Ownership of the code, of anything created along the way, and of any third-party components used. This is boilerplate to sort out beforehand and expensive to sort out afterwards, and this is general information rather than legal advice.
Buy in stages. A small first piece tells you far more about how someone works than any interview, and it limits the cost of being wrong.
Review as you go. Work you first see at delivery is work you cannot influence.
The maintenance question decides more than the build cost
An application that exists and cannot be changed is a liability rather than an asset. Before contracting, answer who will maintain this in a year. If the answer is nobody, you are buying something with an expiry date, and rebuilding later routinely costs more than the difference between contracting and hiring would have.
When to hire instead
When the requirements will emerge. If you expect to learn what the product should be from people using it, you need someone who can absorb that and change direction, which is an employment relationship rather than a change request.
When it is core to the business. Work that defines your product is worth having inside, because the understanding accumulated while building it is most of the value and it leaves with a contractor.
When it never ends. Ongoing development, support and iteration are not a project. Structuring them as one produces a rolling series of contracts with worse continuity and usually higher total cost.
When you need judgement rather than execution. If the hard part is deciding what to build, you are buying a decision maker, and decision makers work poorly under a specification.
A reasonable middle path exists and is underused: contract someone to build the first version while you hire, with handover to the permanent person written in from the start. That gets you moving without buying an asset nobody can maintain, provided the handover is scoped rather than hoped for.
The underlying principle is the same either way. Whoever builds it, someone in your company has to end up understanding it, and arranging that is your job rather than theirs.
Frequently asked questions
- Should I hire a contractor or an employee to build my app?
- Decide whether you can specify what finished looks like. If the outcome is describable and will not need substantial change afterwards, contract for it. If requirements will emerge from use or you are still deciding what the product is, no specification will hold and you need an employee.
- What is the difference in what you actually get?
- A contractor is accountable for delivering a specification. An employee is accountable for the outcome, which includes noticing the specification was wrong. Companies that contract work they could not specify receive exactly what they asked for and conclude the contractor was poor.
- What is the most common mistake when contracting development work?
- Not deciding who owns the result. The app ships, the contractor leaves, and nobody internally can change it. Assign an owner before starting, ideally someone reviewing work as it is produced rather than receiving it at the end.
- How should handover be handled?
- As a paid, scoped deliverable: documentation, a walkthrough, deployment access and a period of availability for questions. Handover that is assumed and unpaid is handover that does not happen, and an application nobody can change is a liability rather than an asset.