Most founders and business owners I speak to are trying to figure out what kind of technical resource they actually need. It's a more consequential question than it looks - not just commercially, but in terms of how the engagement works, who makes decisions, and what happens when something goes wrong.
What a Contractor Provides
A contractor provides time and skill. They sit within your team or alongside it, take direction from you or your technical lead, and deliver work to a specification that you define. The relationship is transactional: hours worked in exchange for a day rate. The contractor's responsibility ends at the code they write.
This is a legitimate and valuable model. A skilled, experienced contractor who's a good fit for your team can extend capacity quickly, bring in a specific technical skill you don't have internally, or accelerate delivery on a defined workload. The key word is "defined". Contractors work best when you know what you need and can direct the work clearly.
What a Consultancy Provides
A consultancy takes ownership of outcomes, not just outputs. The scope typically includes understanding your problem, designing the solution, building it, and ensuring it works - not just writing code to a specification you hand over. A consultancy is accountable for the quality of what they deliver and, in a good engagement, takes an active interest in whether it actually solves the problem it was designed to solve.
This comes with higher cost and higher expectations on both sides. A consultancy will push back on requirements that don't make sense. They'll flag risks you haven't considered. They'll make architectural decisions and stand behind them. That's not overreach - it's the job.
A contractor asks "what do you want me to build?" A consultancy asks "what are you trying to achieve?" The difference in those questions determines everything that follows.
When to Use a Contractor
Use a contractor when you have strong technical leadership in place and a well-defined workload. If you have a CTO or senior technical lead who can direct work, review output, and make architectural decisions, a skilled contractor can add capacity without the overhead of a consultancy engagement. This is particularly true for technology teams that are well-established and have clear delivery processes.
Contractors are also the right choice for clearly bounded, short-term engagements - covering parental leave, delivering a specific feature within a defined timeline, bringing in expertise for a migration your existing team doesn't have.
When to Use a Consultancy
Use a consultancy when you don't have the technical leadership to direct and review the work independently. If you're a non-technical founder, or a technical leader who's already stretched, handing work to a contractor without the ability to oversee it properly is a risk. You're relying on their judgment by default, without the accountability structure of a consultancy engagement.
A consultancy is also the right choice for high-stakes work where outcomes matter more than outputs - a system redesign, a production performance crisis, an architecture that will determine your platform's scalability for the next five years. These decisions are too consequential to delegate to someone who is only accountable for the code they write, not the decisions they make.
The Hybrid Reality
In practice, the distinction gets blurred - good contractors behave like consultants, and good consultancies place people who work like contractors. What you're really evaluating is: does this person or team take ownership of outcomes, or do they deliver what they're told and leave the judgment to you? The commercial structure matters less than the answer to that question.
When evaluating any external technical resource, ask directly: what happens if what I've asked for turns out to be the wrong thing? A contractor's answer is usually some version of "I built what you specified". A consultancy's answer should be "that's why we'd push back before building it".
