What a product actually needs
A software product is not one skill. Between the first sketch and a stable release it needs someone to decide what to build and in what order, someone to design the flows, engineers for the web and the mobile app, often an AI or data specialist, and someone who keeps the cloud, releases and monitoring healthy. That is six roles. Few early products need six full-time people, but all of them need the six skills, and usually in the first month.
This is why the "hire a developer" plan stalls. One engineer, however good, is one skill and one opinion. Two freelancers add a coordination problem and lose context every time one leaves. The real comparison is not agency versus developer; it is how you assemble six skills, with shared context, by the date you need them.
- Six roles, rarely six full-time people
- Shared context is the expensive part, not the code
When to hire in-house
Hire when you have a stable core you must own for years, enough roadmap for each role to stay busy, and the time to recruit. A senior engineering hire in Canada typically takes a quarter from posting to first commit, and the first month is onboarding. If the product is your company, a core in-house team is the right end state.
Hire for the roles that carry your edge: the product owner who knows the customer, and the domain logic nobody else should hold. Everything else can be bought as capacity without losing control, as long as the code and accounts are yours.
- A clear long-term core you must own
- Enough roadmap for every role to stay busy
- Time to recruit, onboard and retain
When a team partner makes sense
A product team partner makes sense when you need to start on Monday, when you need breadth now and depth later, and when the roadmap will change shape before a hire would finish onboarding. The good version gives you a CTO who sits in on the business decisions, product, design, engineering and cloud from week one, scoped as a first project so you can judge the work before committing further.
The test of a partner is what you own. Code, cloud accounts, documentation and the model agreements should be in your name from day one, with the partner working inside them. If leaving would mean losing the system, it is not your product.
- You need six skills on Monday
- Breadth now, depth later
- Everything stays in your name either way
The hybrid most companies land on
In practice most growing companies run a hybrid: a product owner in-house, the build team outside, and one person accountable for the technical decisions. As the product proves itself, they hire the roles that have the most work and keep the partner for the ones that spike, which tends to be design, mobile and AI.
Plan the hand-over from the start. Documentation as a deliverable, a repository the new hire can read on day one, and a partner who treats the hire as a success rather than a threat. The question to ask any partner before signing is simple: how do you hand over when we hire?
- Product owner inside, build team outside, a CTO accountable
- Hire the roles with steady work; keep the partner for the spikes
- Agree the hand-over before you start
In short
Hire in-house when you have a stable core you must own and enough work for each role. Use a team partner when you need six skills on Monday. Most growing companies run a hybrid and keep ownership of code and accounts in both cases.