Do You Need a Full Stack Developer or a Specialist Team for Your Web App?

“Full-stack developer” is the most common job title in software; roughly one in three professional developers claims it, per the Stack Overflow Developer Survey. It is also the most misread line item in a web app budget. Founders read “full stack” as “full team,” and that single misreading is behind a large share of the stalled MVPs, rewritten codebases, and blown runway timelines we see when projects arrive for rescue. So before you hire full stack developers for web app build  or sign a five-role team instead, the budget line behind that title is the first thing to get right.

Here is the uncomfortable symmetry: hiring a specialist team too early is just as expensive as hiring a solo generalist too late. A five-person pod burning $20,000+ a month on a product that hasn’t found its first 100 users is the same category of mistake as one overloaded engineer carrying frontend, backend, infrastructure, and QA for a product that just crossed 50,000 users. The question that decides between the generalist and the team is not “which model is better.” It’s “which failure mode is your product closest to right now.”

Demand isn’t cooling on either side of this decision. The U.S. The Bureau of Labor Statistics projects web developer employment to grow about 8% from 2023 to 2033  faster than the average across all occupations  which means both generalists and specialists will keep getting more expensive to hire, not less.

This guide is the full decision, end to end: the exact product signals that favor each model, real monthly cost bands in ₹ and $, a vetting process that actually filters, contract terms that protect your IP, and  the part almost nobody writes about  how to switch models when you outgrow your first choice. Read it once and you can run this entire hiring cycle yourself.

What Is a Full Stack Developer (and What Is a Specialist Team)?

A full stack developer is a single engineer who builds both the client-side interface (frontend) and the server-side logic, APIs, and database (backend) of a web application, and can deploy the result to production with one hire covering the entire application stack end to end. A specialist team splits those same responsibilities across dedicated roles  typically frontend, backend, DevOps, QA, and UI/UX design, each hired for depth in one layer.

What a full stack developer is not:

• Not a full team in one salary. “Can touch every layer” is not “delivers every layer at specialist depth and specialist speed simultaneously.” The role trades depth for breadth by design.
• Not automatically a DevOps engineer, QA engineer, or designer. Most full stack profiles are strongest in one stack pairing (e.g., React + Node.js in a MERN stack) and functional-but-basic in infrastructure, test automation, and design.
• Not the same as a “dedicated developer.” “Dedicated” describes the engagement model (100% allocated to you, no shared bandwidth); “full stack” describes the skill shape. You can hire a dedicated specialist or a fractional generalist.

Why This Decision Matters More Than Your Tech Stack

Teams agonize over React vs. Angular and then pick their team model by default. That’s backwards  the model decision moves bigger numbers than the framework decision ever will:

• Monthly burn moves 3–6x. A solo senior generalist typically runs $4,000–$8,000/month offshore (₹25–45 LPA equivalent on payroll in India) versus $15,000–$35,000/month for a 4–6 person specialist pod at offshore blended rates. Choosing wrong in either direction misallocates the single largest line in most early product budgets.
• Time-to-first-release moves 30–50%. For a small, well-scoped MVP, one generalist with no coordination overhead usually ships faster than a team. Past MVP scope, the relationship flips: parallel workstreams beat sequential ones, and the solo model becomes the bottleneck.
• Engineering speed is a revenue variable, not a cost variable. McKinsey’s Developer Velocity research found top-quartile companies grow revenue 4–5x faster than bottom-quartile peers. Your team model is the ceiling on that velocity.
• Risk concentration changes shape. One generalist is a bus factor of exactly 1; a resignation is a full project stop. A team diversifies continuity risk but concentrates coordination risk: unclear ownership, integration bugs, and meeting overhead.
• Rework is the hidden cost. In engagements we’ve rescued, the most common pattern is a solo-built codebase that needs 20–40% of its surface rewritten (test coverage, infrastructure-as-code, access control) before a scaling team can safely work in it. That rework is the deferred price of the cheaper first hire.

The Core Problem: Why Smart Teams Pick the Wrong Model

The failure isn’t ignorance, it’s that both wrong choices look correct at signing time.

The underestimation pattern. Most first-time buyers scope the visible product: screens, forms, dashboards. They don’t scope the invisible 60–70%: authentication and role management, payment edge cases, admin tooling, monitoring, backups, staging environments, test coverage. 

In practice, founders routinely underestimate post-MVP engineering surface by 3–4x, which means the “one developer can handle this” assessment was made against one-third of the real workload.

The premature-team pattern. The inverse mistake: raising a round and immediately standing up a 5-role web app development team structure for a product still hunting product-market fit. Now every pivot requires re-aligning five people, sprint ceremonies consume 15–20% of capacity, and the burn multiple makes the runway math brutal.

Red flag: if you cannot state which of these two failure modes you’re closer to, you are not ready to sign either contract. The 30-minute framework later in this guide exists for exactly this.

What the wrong pick actually costs (typical patterns from real engagements):

1. 2–3 months of calendar time lost to a mid-project model switch (re-hiring, knowledge transfer, partial rewrite).
2. 20–40% code rework when a scaling team inherits an untested solo codebase.
3. 15–25% capacity tax when a full team runs ceremonies for a product that needs one decisive builder.
4. A full project stop is measured in weeks, not days, when a bus-factor-1 engineer exits without documentation obligations in the contract.

The Complete Walkthrough: From First Requirement to Shipped Product

This is the entire lifecycle. If you’ve never run a technical hire before, execute these six phases in order and skip nothing. Every phase below exists because we’ve watched someone skip it and pay for it.

Phase 1  Defining Requirements (Scope, Skills, Timeline, Budget)

Your web app team structure falls directly out of your scope document, not the other way around  so scope comes first, in writing, before you talk to a single candidate or vendor. A one-page brief beats a 40-page PRD at this stage; what matters is that the invisible work is on the page.

The scope one-pager (write all seven):

1. Core user workflow is the one journey that must work end to end (e.g., “vendor lists product → buyer pays → vendor gets payout”).
2. Screen count  counts every screen including admin, settings, and empty states. Under ~12 screens is solo territory; 20+ rarely is.
3. Integrations  payments, KYC, messaging, analytics, third-party APIs. Each nontrivial integration adds 1–3 weeks.
4. Data sensitivity  health, financial, or minors’ data pulls in compliance work (audit logs, encryption at rest, access reviews) that generalists rarely carry alone.
5. Concurrent-user expectation at 12 months  hundreds, thousands, or hundreds of thousands. Be honest; this single number drives the infrastructure skill requirement.
6. Hard deadlines and what happens if you miss a demo day is different from a contractual go-live with penalties.
7. Monthly budget band  commit to a range before vendors anchor you.

Budget bands to plan against (typical market ranges, not quotes):

• Solo full stack, India payroll: ₹12–25 LPA mid-level, ₹25–45 LPA senior
• Solo full stack, contract/offshore: $25–50/hour ($4,000–$8,000/month full-time)
• Solo full stack, US payroll: $110,000–$160,000/year base
• Specialist pod (4–6 roles), offshore blended: $15,000–$35,000/month
• Specialist pod, US onshore: $60,000–$120,000+/month

If the one-pager says ≤12 screens, one core workflow, ≤2 integrations, and a 12-month audience in the low thousands, plan to hire a full stack developer and revisit the scaling triggers in Phase 6. If it says otherwise, price the pod.

Phase 2  Sourcing & Vetting (What Good Screening Actually Looks Like)

Vetting a generalist and vetting specialists are different tests, and using the same interview loop for both is the most common screening error we see. A generalist is vetted for judgment across layers; a specialist is vetted for depth in one.

Vetting a solo full stack developer  the 4-stage filter:

1. Portfolio forensics (30 min). Ask for two shipped products they built alone. Then ask who did the deployment, the database schema, and the UI. “I did all of it” should come with specifics (which cloud, which CI/CD setup, which design process). Vague answers here predict vague ownership later.
2. System-design conversation (60 min). Hand them your actual one-pager from Phase 1 and ask for architecture, a monolith-vs-microservices call (the right early answer is almost always a well-structured monolith), and a build sequence. You’re scoring trade-off reasoning, not vocabulary.
3. Paid trial task (3–5 days). A thin vertical slice of your real product: one screen, one API, one table, deployed to a live URL. Pay for it. Unpaid take-home assignments are selected for candidates with the least demand.
4. The weakness question. Every genuine full stack engineer has a weak layer and knows it. “Which layer would you hire to help first?”  a candidate with no answer hasn’t shipped enough alone.

Vetting specialists: run depth interviews per role instead  e.g., rendering performance and state management when you hire ReactJS developers, or API design, queueing, and database indexing when you hire Node.js developers  plus one joint session with two roles together to test how they split an ambiguous feature. Teams fail at the seams, so test the seams.

Cultural evaluation  the part both models skip: technical filters answer “can they build it”; cultural filters answer “will this survive six months of real collaboration,” and for a remote engagement the second question fails more hires than the first. Test three things directly rather than by vibe:

• Written communication under ambiguity. Give a deliberately underspecified requirement in writing and score the response: a strong hire asks 2–3 sharp clarifying questions; a weak one either builds the wrong thing confidently or stalls waiting for perfect specs.
• Disagreement behavior. In the system-design session, push back on one of their correct choices. You want a candidate who defends the decision with reasoning and concedes gracefully where you’re right, not one who folds instantly (they’ll build whatever the loudest voice says) or digs in on ego.
• Timezone-overlap honesty. Agree on 3–4 hours of guaranteed overlap in writing before the offer, not after. “Flexibility” without a number is the root cause of most async-collaboration failures we see.

Red flags in either model:

• No questions back about users or business goals during the technical interview
• “We can start tomorrow” from an agency  strong vendors have a bench pipeline, not idle staff
• Refusal to put a named engineer (not “our team”) in the contract
• Portfolio full of demos and templates, nothing with real production users

A structured pipeline compresses this dramatically: with pre-vetted talent pools, a 7–10 working day cycle from job description to interview-ready shortlist is a realistic benchmark  if a vendor quotes 4–6 weeks just to show you CVs, that’s a process smell.

Phase 3  Engagement Models & Contracts

Skill shape (generalist vs. specialists) and engagement model (how you contract them) are separate decisions. Most buyers conflate them.

The three engagement models:

1. Dedicated hire / dedicated development team  engineer(s) work only on your product, you direct the work day to day. Best when requirements will evolve. Watch for: “dedicated” in name only  no shared bandwidth should be an explicit contract term.
2. Staff augmentation  talent slots into your existing processes and management. Best when you already have engineering leadership. Watch for: augmenting a team you don’t actually have the management capacity to run.
3. Fixed-scope project  vendor owns delivery of a defined spec for a fixed price. Best for genuinely frozen scope (rare in new products). Watch for: change-request pricing, which is where fixed-price margins are recovered.

Contract terms that are non-negotiable regardless of model:

• IP assignment on creation, not on final payment  you own every commit from day one
• NDA covering the product and the data, signed before code access
• Named individuals in the contract, with a replacement clause and timeline (7–10 working days is the standard worth demanding  it’s a guarantee credible vendors, Supersourcing included, put in writing)
• Documentation and handover obligations  repo access, environment credentials, architecture notes  owed continuously, not at exit
• Notice period and code-escrow-style access so a resignation is a disruption, not a hostage situation
• Payment tied to time or milestones, never to “completion” of ambiguously worded scope

Phase 4  Onboarding & Ramp-Up (The First Two Weeks)

Ramp-up time is where paper savings evaporate. A hire who spends three weeks waiting for access and context costs you the same as one who ships in week one  and plans the first 10 working days like a project.

Day 1–2: Access. Repo, cloud console (least-privilege roles, not owner access), project tracker, staging environment, domain/API keys in a secrets manager  never in chat messages.

Day 3–5: Context. A 60-minute product walkthrough recorded for reuse; the Phase 1 one-pager; a written “definition of done” (code review passed, tests written, deployed to staging, product owner accepted).

Day 5–10: First deployment. The single best ramp-up KPI is a small real feature deployed to production by day 10. It forces every access, process, and communication path to actually work.

Communication cadence to set on day 1:

• Solo generalist: 15-minute daily written check-in (yesterday/today/blockers) + one 45-minute weekly demo. Resist daily meetings  you hired for autonomy.
• Specialist team: daily standup inside the team, but you attend only the weekly demo and a fortnightly planning session. A dedicated account manager or delivery lead should be your single throat to choke; if you’re personally chasing five people, the vendor’s management layer isn’t doing its job.

The 3-day rule: any blocker that survives three daily check-ins unresolved gets escalated to a call with the vendor’s delivery manager. Blockers that age silently are the leading indicator of a failing engagement.

Phase 5  Managing Delivery (Cadence, KPIs, and Who Watches What)

You cannot manage a build with “how’s it going?” Pick 4–5 measurable signals and review them on a fixed weekly rhythm.

KPIs that work for both models:

1. Deployment frequency  production or staging deploys per week. Weekly or better is healthy; a two-week gap is a conversation.
2. Sprint predictability  planned vs. delivered scope. Consistently below ~70% means estimation or scoping is broken, not effort.
3. Escaped defects  bugs found after a feature was called done. Rising trend = QA gap, the most common one in solo engagements.
4. Cycle time  days from “started” to “in production” per feature. Watch the trend, not the absolute number.
5. Blocker age  per the 3-day rule above.

Model-specific watch items:

• Solo generalist: watch for silent scope-cutting on tests and infrastructure. It’s how one person keeps pace, and it’s invisible until you scale. A monthly CI/CD and test-coverage review catches it; if infra debt is compounding, a fractional engagement to hire DevOps engineers for 20–40 hours/month is dramatically cheaper than the outage that otherwise announces the problem.
• Specialist team: watch the seams  features that are “done” in three roles’ trackers but not integrated. The weekly demo shows the integrated product on staging, never per-role slides.

Phase 6  Scaling or Exiting (When to Switch, Add, or Wind Down)

Whichever model you chose, plan the transition on day one, because the switching point is predictable.

When to switch from a full stack developer to a specialist team  the four triggers:

1. Backlog inversion: the prioritized backlog grows for 6+ consecutive weeks despite full-time effort.
2. Layer failure: one layer (usually infra or QA) starts producing repeated production incidents; the generalist’s weak layer has become load-bearing.
3. Traction step-change: users or data volume grow 5–10x and performance work starts crowding out feature work every sprint.
4. Key-person anxiety: you find yourself afraid of your own engineer’s vacation. That’s bus factor 1 telling you its price.

How to switch without a stall (in order):

1. Add, don’t replace  bringing specialists in around the generalist, who becomes the context anchor and often the tech lead.
2. Sequence the first two hires by weakest layer  most commonly QA first, DevOps second.
3. Buy 2–4 weeks of overlap in the contract for handover; it’s the cheapest insurance in this entire guide.
4. Only consider a rewrite if rework estimates exceed ~40% of the codebase  below that, refactor in place while shipping.

Exiting a team: replacement clauses (swap an underperforming individual in 7–10 days) should be exercised early, not endured; offboarding checklist = access revocation, credential rotation, final IP assignment confirmation, and a recorded architecture handover.

Case Studies: What the Two Models Look Like at Real Scale

Paytm  specialist hiring at volume. 100+ engineers hired across specialized roles for one of India’s largest fintech platforms is the clearest illustration of the specialist model’s ceiling advantage: at that product surface (payments, lending, compliance), no generalist model exists that can carry the load, and hiring velocity itself becomes the constraint. Supersourcing’s vetted-pipeline approach kept shortlist-to-interview cycles inside the 7–10 working day band even at that volume.

OkCredit  generalist-weighted early engineering. An early-stage bookkeeping product hiring for speed and iteration: engineering hires weighted toward versatile, product-minded developers who could own features end to end while the product hunted for its shape. The takeaway founders should steal  the early team that was built for cheap pivots, and specialists were layered in as workflows stabilized, in exactly the Phase 6 sequence above.

Somnoware  niche specialists where depth is non-negotiable. A healthtech (sleep-diagnostics) platform where domain constraints, clinical data handling, integrations with diagnostic hardware  made generalist hiring a false economy. Recruitment automation plus targeted specialist sourcing filled roles a generic pipeline had struggled with; the pattern: the rarer the intersection of skills, the more the process (not the job ad) determines whether the role fills at all.

Full Stack vs Specialist Team: A Decision Framework You Can Run in 30 Minutes

The full stack vs specialist team call reduces to seven questions. Score each 0 (left answer) or 1 (right answer), then total.

Scoring:

• 0–2 → Solo full stack developer. Coordination overhead would cost you more than depth buys you. Hire one strong generalist, dedicated, with the Phase 3 contract terms.
• 3–4 → Hybrid. One full stack anchor plus 1–2 targeted specialists (most often QA and DevOps, fractional). This is the most under-used answer and, in our experience, the right one for the largest share of funded pre-Series-A products.
• 5–7 → Specialist team. A generalist here isn’t a savings; it’s a queue. Budget the pod from day one and spend your negotiation effort on the delivery-management structure, not the headcount price.

The model trade-off at a glance:

When to Hire Full Stack Developers for a Web App (and When Not To)

The scorecard gives you a number; this section gives you the pattern-matching. These are the scenarios where each answer wins in practice. The fastest sanity check on your scorecard results in finding your product in one of these lists.

Hire the generalist when:

• You’re validating, not scaling. The product’s job for the next 6 months is to prove someone will pay. Iteration speed and cheap pivots outrank architecture, and one decisive builder pivots in a conversation, not a re-planning cycle.
• The product is an internal tool or a workflow app. Predictable load, forgiving users, one workflow  the exact shape a strong generalist ships in 8–12 weeks.
• You are the product manager and the QA. With a founder deeply in the loop daily, the missing specialist layers are partially covered by your own attention. This stops being true the day you can’t personally test every release.
• The budget is genuinely capped below ~$8k/month. A great generalist beats a mediocre pod at the same total price every time; never split a small budget across weak specialists.

Go straight to specialists when:

• The domain punishes shallow depth. Payments at scale, healthcare data, marketplaces with money movement, real-time systems  the cost of a security or compliance mistake exceeds the entire salary delta.
• Two or more workflows must launch together. Parallel workstreams are the whole point of a team; forcing them through one person just serializes your launch.
• You’ve already found traction. Post-product-market-fit, every week of delivery delay has a measurable revenue cost, and the coordination tax becomes cheap by comparison.
• A committed date has penalties attached. One person has zero schedule redundancy and no reputable advisor signs off on bus factor 1 against a contractual deadline.

The exception that trips people: technical founders who can code often hire a generalist to pair with themselves and believe that equals a team. It equals a bus factor of 1.5  better, but the QA and infrastructure gaps in this guide still apply, because two people who both prefer building features will both silently deprioritize testing.

What Most Teams Get Wrong

This is the section to screenshot. Five patterns, all from real engagement post-mortems, all contrarian to the standard blog advice.

1. They compare day-one price instead of month-nine price. The generalist looks 4x cheaper at signing. But if the product succeeds, most solo-built codebases need 20–40% rework before a team can scale them  so the real comparison is “generalist + later rework + later team” vs. “smaller team now.” For products that clear the 3+ score on the framework above, the total 12-month spend of the two paths converges far more than the monthly rates suggest; you’re mostly choosing when to pay, and how much risk to carry in between.
2. They treat “full stack” as a certification instead of a spectrum. The title is self-declared. Roughly a third of professional developers claim it, which mathematically guarantees most are frontend- or backend-leaning developers with working knowledge of the other side. The vetting stages in Phase 2 exist because the title filters nothing.
3. Full stack developer limitations are structural, not personal. The limitations that matter: basic test automation, shallow infrastructure depth, no design system discipline, single-threaded delivery  aren’t fixed by hiring a better generalist, because they come from the shape of the role, not the talent of the person. Budget for the gaps (fractional QA/DevOps) instead of interviewing harder for a unicorn who doesn’t exist at market rates.
4. They scale by replacing instead of surrounding. The most expensive sentence in this niche is “we’ve outgrown our developer, let’s hire a team and start fresh.” Firing the context-holder and rewriting simultaneously is how 3-month transitions become 9-month ones. Surround the generalist (Phase 6); the rewrite decision should be made by the incoming tech lead after reading the code, never before.
5. They negotiate rates and ignore structure. Buyers grind $3/hour off the rate and accept shared bandwidth, no named engineers, no replacement clause, and IP-on-final-payment. Every catastrophic engagement we’ve audited had a structural contract gap; almost none were caused by paying 10% too much.

Cost & Timeline Reality Check

The section competing articles skip. All figures are typical market bands for 2025–26 (ranges, not quotes, your stack, seniority bar, and location tilt these 15–25% either way).

Full stack developer vs dedicated team cost, by scenario:

What moves cost up:

• Regulated data (adds compliance engineering: typically +15–30% effort)
• Real-time features (chat, live tracking, collaborative editing)
• Each integration past the second (+1–3 weeks each)
• US/EU onshore requirement (3–5x offshore rates)
• Rescuing an existing codebase (audit before you commit to a number  anyone quoting without reading the code is guessing)

What moves cost down:

• A written Phase 1 one-pager (vendors price uncertainty; remove it)
• A well-structured monolith over premature microservices
• Offshore or nearshore sourcing through IT staffing services with pre-vetted benches rather than open-market recruiting  the cost arbitrage on Indian engineering talent is typically 50–70% against US rates at equivalent seniority
• Fractional specialists instead of full-time ones for QA/DevOps in the first year

Hiring timeline, both models:

1. Scope one-pager: 2–3 days (you)
2. Shortlist of vetted candidates: 7–10 working days through a structured pipeline; 4–8 weeks via open-market job posts
3. Interviews + paid trial: 1–2 weeks
4. Contracting + onboarding to first deploy: ~2 weeks

Call it 4–6 weeks from decision to a productive engineer or team when the process is run well  and 3–4 months when it isn’t, which is itself a number worth budgeting against.

Where to Go From Here

If you’ve read this far, you’re probably mid-decision  so make the next step small and concrete. Fill in the Phase 1 one-pager (30 minutes), run the 7-question scorecard (another 10), and you’ll know which of the three bands you’re in.

If you land in the hybrid band, inherit someone else’s code, or simply want your scorecard pressure-tested by people who’ve staffed 527+ IT projects across both models, bring the one-pager to a consultation  Supersourcing runs both engagement types, so the recommendation isn’t pre-loaded toward either answer. Start here: supersourcing.com/contact-us.

FAQ

Is it better to hire a full stack developer or a team of specialists? 

Neither is better in general; they win at different product complexity levels. Under roughly 12 screens, one core workflow, and low-thousands of users, a solo generalist ships faster and 3–6x cheaper. Above that  multiple workflows, regulated data, 5,000+ users, a specialist team’s parallel delivery and per-layer depth overtake the solo model on both speed and total cost of ownership.

Can one full stack developer build a web app alone? 

Yes  genuinely, and it happens every day for MVPs, internal tools, and single-workflow SaaS products. What one developer cannot do is build it at specialist depth in every layer simultaneously: expect trade-offs in test coverage, infrastructure, and design polish. Those trade-offs are acceptable for validation-stage products and expensive for scaling ones.

How many developers do I need to build a web app? 

Score your project on the 7-question framework above. As a rule of thumb: one senior generalist for a simple validated scope; three (full stack anchor + QA + DevOps, some fractional) for a funded pre-Series-A product; four to six specialists for multi-workflow, regulated, or high-traffic builds. Headcount beyond six on a single web app usually signals scoping problems, not ambition.

How much does it cost to hire a full stack developer in India? 

On payroll, typically ₹12–25 LPA for mid-level and ₹25–45 LPA for senior engineers in 2025–26 market conditions. On contract through a staffing partner, $25–50/hour, or roughly $4,000–$8,000/month full-time equivalent. US-based equivalents run $110,000–$160,000/year base  the arbitrage is why offshore-first is the default for early builds.

Do full stack developers handle DevOps and QA? 

Functionally yes, at a basic level: most can containerize an app, set up simple CI/CD, and write some tests. Structurally no: under deadline pressure, testing and infrastructure are precisely what a single-threaded engineer cuts first. Assume working-but-thin coverage of both, and budget fractional specialist hours once real users arrive.

What happens if my full stack developer quits mid-project? 

With a well-structured contract, continuous documentation obligations, your ownership of repos and environments, a named-replacement clause, it’s a 2–4 week disruption. Without those terms, it’s a project stop and sometimes a partial rewrite. This is why Phase 3 of this guide treats contract structure, not rate, as the negotiation that matters.

How long does it take to hire a full stack developer? 

Through open job boards, 4–8 weeks to a signed offer is typical once screening noise is accounted for. Through a pre-vetted talent pipeline, a shortlist in 7–10 working days and a productive, onboarded engineer inside 4–6 weeks total is a realistic standard to hold a vendor to.

When should I get outside help with this decision instead of running it alone?

When your scorecard lands in the 3–4 hybrid band, when you’re inheriting an existing codebase, or when a hard deadline removes your margin for a mis-hire. Those three situations have the widest gap between a good and bad outcome, and a 30-minute scoping conversation with a team that has run hundreds of these engagements costs nothing against a 2–3 month mis-hire.