When to bring your website in-house
When a business should run its own website and software rather than use a partner, and the hybrid most end up with.
The short answer
A business should bring its website and software in-house when three things are true: the digital side is the product or close to it, the volume of change keeps several people busy all year, and the business can hire, retain and manage them. In-house means more than a developer. It means design, operations, monitoring, security, testing, on-call and the disciplines a partner supplies as a package, and it means more than one person or the single point of failure returns. Hybrid is the arrangement worth aiming for: an internal owner or a small team for priorities, content and product decisions, and a partner for building and operations, working in the same repository and accounts. Whatever the arrangement, ownership and documentation stay the same; an in-house team inherits them rather than replacing them.
Partner, hybrid or in-house
| Partner | Hybrid | In-house | |
|---|---|---|---|
| Fits when | Digital is a means; change is steady but not constant | Digital matters; the business wants internal ownership of priorities | Digital is the product; constant change; the business can hire and retain |
| Who owns priorities | The business, with the partner advising | An internal owner | An internal product lead |
| Who builds and operates | The partner | The partner, with internal developers alongside | The team, with contractors for peaks |
| Breadth | Many projects’ experience | Both | Deep on your product; narrower otherwise |
| Continuity risk | On the partner, mitigated by ownership | Low: knowledge on both sides | On the team; hiring and retention |
| Cost shape | Fixed monthly plus projects | Salary plus a smaller partner fee | Salaries, tooling, management |
What in-house actually requires
- A product or digital lead who owns priorities and numbers.
- Development capacity of more than one person, so holidays and departures do not stop work.
- Design for a coherent product, not screens improvised by developers.
- Operations: monitoring, pipelines, hosting, backups, on-call for critical issues.
- Security and testing as disciplines, not intentions.
- Management: hiring, retention, direction, which is a job in itself.
- Contractors or a partner for peaks and specialisms.
The gradual path
Hire the internal owner first. They run the partner, learn the estate, and start owning priorities. Add a developer who works in the same repository, pipeline and accounts as the partner, so knowledge transfers by working together. Grow the team as volume justifies, moving operations in-house last because it is the hardest to staff. Because ownership and documentation were always in the business’s name, each step is a change of collaborators on systems the business already holds, not a hand-over.
What this means for you
Bring digital in-house when it is the product, the change is constant and you can build and manage a real team. Otherwise, hire the internal owner and keep a partner for building and operations, working in your accounts and repository. Either way, ownership and documentation are already yours, so the arrangement can change as the business does, without a crisis.
Frequently asked questions
We are spending a lot with our partner. Would a developer be cheaper?
Compare like with like. A partner's fee covers design, development, operations, monitoring, security, testing, the escalation arrangement in the agreement and the breadth of many projects. One developer covers development, and the rest either goes undone or lands on them. For a business whose digital side is a means rather than the product, one salary rarely covers the full scope, so compare the fee with what covering it in-house would take; for one where it is the product, a team makes sense.
What is the minimum viable in-house team?
More than one person, or the single point of failure returns. Typically a product or digital lead who owns priorities, a developer or two, design capacity, and someone accountable for operations and security, plus a partner or contractors for peaks and specialisms. Below that, the honest arrangement is an internal owner plus a partner.
Can we move from partner to in-house gradually?
Yes, and that is the healthy path: hire the internal owner first, who runs the partner and learns the estate; then a developer who works alongside the partner in the same repository and pipeline; then more as volume justifies. Because everything was in your name and documented, the transfer is a change of collaborators, not a hand-over crisis.