When to Hire an Agency vs Build an In-House Team for Enterprise Web Apps

The first number that gets quoted in any "build vs. buy" conversation is the salary line. A senior full-stack engineer in a major US market is around $180,000 to $220,000 base. A team lead or staff engineer is higher. That number alone is not the cost of the team, and treating it as the cost is the most common mistake we see when companies estimate the in-house path.

A realistic enterprise web platform needs five to seven people to ship and operate: a tech lead, two to three senior engineers, a designer or UX lead, a QA engineer, and at least part-time DevOps or platform support. The fully loaded cost per head, once you include benefits, payroll taxes, equity, tooling, hardware, software licenses, and the overhead of HR, recruiting, and management time, runs roughly 1.3 to 1.4x base salary.

A representative annual cost looks like this:

• Tech lead at $230,000 base, fully loaded around $320,000
• Three senior engineers at $200,000 base, fully loaded around $280,000 each
• Design and UX lead at $170,000 base, fully loaded around $235,000
• QA engineer at $140,000 base, fully loaded around $195,000
• Part-time DevOps support, fully loaded around $120,000
• Recruiting cost: 20 to 25% of first-year salary per hire, often paid to an external recruiter

That puts the all-in run rate north of $1.7 million per year before the team has shipped a single feature, and it assumes you can actually hire those people in a reasonable window. It also assumes zero attrition, which is not how engineering teams behave. Replacing a senior engineer who leaves at month nine effectively resets a meaningful slice of that investment.

“The salary line is roughly half the actual cost of an in-house team. Recruiting, benefits, attrition, and management overhead make up the rest, and they show up whether the team ships or not.”

Even when the budget exists, the time it takes to assemble an in-house team from scratch is the variable most companies underestimate. A realistic timeline to hire a tech lead, two seniors, and supporting roles for an enterprise web platform is four to six months of active recruiting in a healthy market, and longer in competitive ones. That is before anyone writes code. Once hired, a senior engineer joining a greenfield project still needs roughly four to eight weeks to be productive on architecture decisions, conventions, and the specific business domain.

An agency engagement starts in week one. The team is already assembled, already shipped projects together, already has working conventions for code review, deployment, testing, design handoff, and stakeholder communication. The first sprint produces deployed code, not org-chart conversations and laptop orders. For a platform with a real business deadline, that gap is often the deciding factor by itself.

A typical first-six-months comparison

• In-house path. Months 1 to 4: hiring. Month 5: onboarding, environment setup, architecture spikes. Month 6: first meaningful feature in staging.
• Agency path. Week 1: discovery and architecture. Week 3: first feature in staging behind a flag. Month 3: a working beta with real users. Month 6: production launch with a defined handoff plan.

If the platform exists to enable a revenue line, support a launch, or replace a system that is already under load, the cost of those four months is rarely the salary line. It is the opportunity cost of the platform not existing yet.

A five-person in-house team is, by necessity, deep in a small number of technologies. Whatever the tech lead chose, whatever the existing seniors know best, that is the stack the team is excellent at. Anything outside that surface area, whether it is a payment integration, a complex data migration, an accessibility audit, performance work on Core Web Vitals, a niche third-party API, or a security review, becomes a contract engagement or a learning curve that delays the roadmap.

An agency that builds enterprise web platforms across multiple clients carries the full stack of capabilities continuously. The frontend specialists, the backend and integration engineers, the designers, the SEO and performance practitioners, the security reviewers, the DevOps engineers, and the AI tooling people are all on staff because the next project will need them. Any individual engagement draws on whichever slice of that bench it needs, when it needs it, without hiring anyone.

For an enterprise platform that touches authentication, data, integrations, content management, design systems, and compliance all at once, that breadth is hard to replicate with a small in-house team in the first year. It is also hard to justify hiring permanently for capabilities the platform only needs intermittently.

“A small in-house team is excellent at the specific things its members already know. An agency carries the full stack because the next project always needs a different slice of it.”

Every in-house engineering team has a bus factor, the number of people who could leave before institutional knowledge of the platform is meaningfully lost. On a team of five, the bus factor is often one or two. When the tech lead resigns, or the senior engineer who built the auth flow takes another offer, the team absorbs a real shock: months of context, undocumented decisions, and tacit understanding of how things fit together walk out the door.

A well-run agency engagement is structured around continuity. Multiple engineers know the codebase. Documentation, code review standards, and architecture decisions are recorded as a matter of habit because the agency knows the project will be handed off, audited, or revisited. When a single person rolls off a project, another team member picks up the same context the next morning. The platform does not depend on any one person remembering how something works.

This matters most six to eighteen months after launch, when the platform is in production and the team that built it is being asked to extend it. In-house teams at that stage are also when attrition risk is highest: the original engineers have shipped the big interesting thing, the work has settled into incremental feature delivery, and the strongest hires are getting recruited elsewhere.

For most enterprise web platforms, the right model is not strictly one or the other. It is a hybrid: the agency designs and builds the platform to production, then trains and hands off to an in-house team that owns long-term operations and product velocity. This is the model we run most often for clients who do not have an existing engineering org but expect to grow one.

How a hybrid engagement is typically structured

1. The agency leads discovery, architecture, design, and the initial build, shipping to production on a defined timeline.
2. The client hires a tech lead and one or two senior engineers during the build, typically starting around month three or four.
3. Those in-house engineers are embedded in the agency team for the final stretch, pairing on the codebase they will inherit.
4. A structured handoff covers architecture, deployment, monitoring, runbooks, and the testing and design conventions the agency uses.
5. After handoff, the agency continues on a smaller retainer for advisory, complex feature work, and capability gaps the in-house team is still hiring for.

The result is a platform that exists, a team that owns it, and a relationship that can be drawn on when the in-house team needs help. The handoff is the part that distinguishes a serious agency from a vendor; if you are evaluating partners, asking about their handoff playbook is one of the fastest ways to tell them apart.

“The agency builds the platform while the client builds the team. By launch, both exist, and the handoff is a structured event rather than a panic.”

After enough of these conversations, the signals that point to each model are reasonably consistent. The decision rarely depends on budget alone. It depends on what the platform is for, how often it will change, and whether engineering is a core competency the business needs in-house to compete.

Signals you should build in-house

• The platform is your core product, the thing customers pay you for, and product velocity is a competitive advantage.
• You expect daily or near-daily changes driven by product, growth, or experimentation.
• You already have a CTO and at least two senior engineers, and the next hires extend an existing team rather than starting one.
• The roadmap is open-ended and will keep producing new work for years, not a defined platform with a maintenance phase.

Signals you should engage an agency

• The platform is a one-time build or a major rebuild with a defined scope and a real launch deadline.
• The work is integration-heavy, compliance-heavy, or design-heavy, pulling in capabilities you would not hire for permanently.
• You do not have an existing engineering org and do not want hiring to become the critical path.
• You want a vendor with a track record of shipping similar systems, accountable to a fixed-bid or capped-scope engagement.
• You expect the platform to settle into maintenance and incremental change after launch, not daily product iteration.

How to evaluate an agency objectively

The most reliable signals about an agency come from its own work product, not its sales pitch. Look at the agency website: does it load fast on a real connection? Is the markup clean? Does it score well on Core Web Vitals? Look at the live sites in the case studies, not the screenshots: are they fast, accessible, and well-structured? Ask to see code, runbooks, or a sample handoff document. Ask which engineers will actually be on your project and how long they have been at the agency. Read the agency-authored engineering writing and decide whether it reflects how the team thinks, or whether it is generic marketing copy. Good agencies are happy to be evaluated this way; the ones that aren't are telling you something.

“You cannot evaluate an agency by what it says about itself. You evaluate it by what it ships, what it writes, and who shows up on the call.”