In-House vs Outsourcing: The Full Cost Math, the Control Tradeoffs and the Hybrid That Usually Wins

Nguyen Manh Thang Chief Executive Officer, AgileTech Vietnam

Published: August 21, 2026
Read time: 10 min

Two workshops joined by a central shared bench where a resident worker and a visiting worker assemble the same part together — The real answer is usually the bench in the middle, not either workshop alone.

In short

Neither model wins in general; each wins somewhere specific. In-house teams win where the work is the company's core differentiator, where product knowledge must compound for years, and where daily collaboration with the business drives the roadmap. Outsourcing wins where speed to start matters more than ramp time, where the skill needed is temporary or scarce locally, and where a fully loaded internal hire, salary plus taxes, benefits, equipment, management and hiring cost, roughly one and a half to two times base salary, exceeds what a strong external team charges for the same output. The failure modes are symmetrical: in-house fails through slow hiring, key-person risk and skill stagnation; outsourcing fails through knowledge leaving at contract end, communication overhead and misaligned incentives on time-and-materials work. Most companies past the first product converge on a hybrid: a small in-house core owning architecture, product direction and vendor management, with external teams adding capacity, specialty skills or whole workstreams under that core's technical control.

Every company that builds software eventually faces the same fork: grow an internal engineering team, or pay an external one. The argument is usually conducted with rigged numbers, a salary compared against an hourly rate, as if employees cost only their pay and vendors billed only for typing, and with rigged anecdotes, the outsourcing horror story against the eighteen-month internal hire who never shipped. Both models work; both fail; and the interesting question is not which is better but which fits the specific work, timeline and stage in front of you.

This guide runs the comparison honestly. The fully loaded cost of an internal engineer against what vendor rates actually contain. Time to capacity, the variable that decides more projects than price does. The knowledge and control tradeoffs that spreadsheets cannot capture. Where each model characteristically breaks. And the hybrid patterns, a small in-house core directing external capacity, that most companies past their first product converge on, because the pure models are mostly found at the extremes of scale.

The lens is a decision-maker's throughout, written for founders and CTOs sizing their first team and for leaders rethinking an existing one. For the geography dimension of the external option, onshore, nearshore and offshore covers where the work sits; for picking the vendor once you choose to use one, how to evaluate a software partner covers the diligence.

Key takeaways

Compare fully loaded costs, not salary against rate. An internal engineer costs roughly one and a half to two times base salary after taxes, benefits, equipment, tooling, management overhead and amortized hiring cost; a vendor rate has all of that inside it.
Time to capacity is the hidden variable: hiring an engineer takes months from opening to productive work, while a good external team starts in weeks. For deadline-driven work, the calendar often decides before the spreadsheet does.
Knowledge is the real currency: in-house knowledge compounds and stays; outsourced knowledge leaves at contract end unless you engineer retention through documentation, code ownership and overlap with internal staff.
The control tradeoff is about incentives, not geography: employees optimize for the company's long game, vendors optimize for the engagement. Contracts, embedded product owners and outcome-based scopes narrow the gap but never close it fully.
Core versus context is the cleanest dividing line: build in-house what differentiates you, outsource what is necessary but generic. Companies that outsource their differentiator rent their own moat.
The hybrid is the steady state, not a compromise: a small internal core owning architecture and product direction, with external teams adding capacity under its technical control, outperforms either pure model for most companies past their first product.

The question behind the question

A figure at a crossroads looking into a mirror that reflects scales, an hourglass and a key instead of the two roads — Build or buy is really three questions: cost, speed and what you must own.

In-house versus outsourcing looks like a procurement question and is actually a strategy question: which capabilities must this company own, and which can it rent? The classic dividing line is core versus context. Core work is what differentiates you, the algorithm, the product experience, the domain logic customers pay for, and it compounds: every month an internal team spends on it deepens an advantage competitors cannot buy. Context work is necessary but generic, the admin portal, the data pipeline plumbing, the app nobody chose you for, and it does not compound: done is its only virtue. The first-pass answer to the whole debate is one sentence: own the core, rent the context, and be brutally honest about which is which.

The honesty is the hard part, because everything feels core from inside. The test is competitive: if a rival shipped the same component tomorrow, would customers move? The checkout flow of a commerce startup is core; its invoice PDF generator is context. The matching engine of a marketplace is core; its CMS integration is context. Companies routinely get this backwards in both directions, outsourcing the differentiator to save money, which rents out the moat, and staffing internal teams on commodity work, which spends the scarcest resource, hiring capacity, on problems the market already solved.

Stage matters as much as strategy. A pre-revenue startup with a twelve-month runway cannot spend five months of it hiring; an external team that starts in three weeks may be the only path to a product before the money ends, with the explicit plan to hire around the core once it exists. A scaled company with a hundred engineers faces the opposite math: it has the hiring machine, the brand and the management depth to grow internally, and uses external teams surgically, for spikes, specialties and legacy work its own engineers would quit over. The models are not rivals so much as tools for different moments, which is why the rest of this guide compares them dimension by dimension instead of declaring a winner in the first paragraph.

Core work: own it. The differentiator customers pay for. Internal knowledge of it compounds into a moat; outsourcing it rents the moat out.
Context work: rent it. Necessary but generic. Done is its only virtue, and external teams reach done without spending your hiring capacity.
Stage bends the rule. Short runways favor speed to start; scaled companies favor internal compounding. The same work can deserve different models at different moments.

The cost math both sides get wrong

An accountant in a rowboat measuring the submerged mass of an iceberg whose tip is a small coin block above the waterline — Salary is the tip; recruiting, ramp, benefits, tooling and vacancies sit below the line.

The naive comparison, local salary versus vendor hourly rate, is wrong in both columns. An employee's true cost starts at base salary and climbs: employer taxes and social contributions, health and retirement benefits, equipment and software licenses, office or remote stipends, training, and the amortized cost of recruiting, agency fees or internal recruiter time plus the engineering hours burned on interviews. Add the management layer that ten engineers require and the payroll cost of vacation, sick leave and holidays, and the fully loaded figure lands, in most Western markets, at roughly one and a half to two times base salary. An engineer at a one hundred thousand dollar base is a one hundred fifty to two hundred thousand dollar line item, illustrative but directionally reliable, before a single feature ships.

The vendor rate, meanwhile, contains things the salary comparison forgets it needs: the vendor's recruiting and retention machine, its management and delivery infrastructure, replacement of underperformers without a severance process, and elasticity, the ability to add two engineers next month and release them after launch without a layoff. Against that, the rate also contains the vendor's margin and sales cost, and time-and-materials engagements bill for coordination hours an internal team would absorb invisibly. Geography moves the number enormously: strong teams in Vietnam, Eastern Europe or Latin America bill a fraction of Western onshore rates for comparable senior talent, the arbitrage that the onshore, nearshore and offshore comparison maps in detail.

Two costs escape both columns and decide many projects anyway. Time to capacity: a requisition-to-productive-engineer cycle commonly runs a quarter or more, opening approval, sourcing, interviews, notice period, onboarding, while an established vendor fields a team in weeks; for revenue-critical deadlines, the value of those months dwarfs the rate difference. And exit cost: an internal team wound down is severance, morale damage and knowledge diaspora; an external engagement ended is a notice period. Flexibility has a price when you do not use it and a large negative price when you do. The honest spreadsheet has all four numbers: loaded cost, true rate, calendar value and exit cost, and the model that wins changes with the weights.

What each column actually contains

Cost component	In-house engineer	External team rate
Base compensation	Salary	Inside the rate
Taxes and benefits	Add a quarter to a half of base	Inside the rate
Recruiting cost	Agency fees or recruiter time, amortized	Vendor's problem, inside the rate
Equipment and tooling	Laptops, licenses, stipends	Mostly inside the rate
Management overhead	A lead per handful of engineers	Vendor delivery management, inside the rate
Vendor margin and sales	None	Inside the rate
Coordination hours	Absorbed invisibly	Often billed, visible
Exit cost	Severance and knowledge loss	Notice period

The naive comparison strips the left column and pads the right. Illustrative composition of fully loaded costs.

The naive comparison stops at the first bar. The honest one stacks taxes, benefits, equipment, management and amortized hiring on top, which is the figure a vendor rate should be compared against. Illustrative composition.

Time to capacity: the variable that decides deadlines

Two garden beds, one with seeds barely sprouting in a long row, the other receiving fully grown potted plants slotted into place — Hiring grows a team from seed; a partner transplants one already grown.

Money is negotiable; the calendar is not. The in-house path to new capacity runs through a pipeline with well-known stage lengths: getting a requisition approved, sourcing candidates in a market where senior engineers are permanently scarce, interview loops that consume the existing team's weeks, offer negotiation against competing bids, a notice period at the candidate's current employer, and an onboarding ramp before real productivity. Quarter-long end-to-end times are normal; half a year is not rare for senior and specialized roles. The pipeline also fails silently: offers get declined, new hires wash out, and the requisition restarts.

The external path compresses most of that. An established vendor holds a bench and a hiring machine; a dedicated team can be interviewing within days and productive within weeks, and scaling it up or down later is a staffing conversation rather than a hiring or layoff cycle. This elasticity is the model's most underrated property: product development is lumpy, a platform rewrite here, a compliance deadline there, a quiet quarter after launch, and matching a fixed internal headcount to lumpy demand means either overstaffing the valleys or understaffing the peaks. External capacity absorbs the lumps.

The compression has limits worth naming. A new external team still climbs a context ramp, your domain, your codebase, your standards, and the ramp is paid at full rate; vendors that promise productive output in the first week are describing typing, not contribution. Specialized skills are the second honest advantage: needing two months of a machine learning engineer, a security auditor or an ERP integration specialist is a terrible hiring problem and a routine contracting one, which is why even determinedly in-house companies rent specialties. The steady-state comparison is therefore not weeks versus months once, but how each model handles the next ten capacity changes, and there the elasticity argument compounds.

A quarter Typical requisition-to-productive time, in-house Approval, sourcing, interviews, notice period, onboarding. Longer for senior and specialized roles. Illustrative.

Weeks Typical start time, established vendor team Bench and hiring machine already running; context ramp still applies.

Elastic The underrated property Scaling down is a staffing conversation, not a layoff. Lumpy demand meets adjustable supply.

The rate difference decides budgets; the start difference decides deadlines. An established external team compresses the front of the timeline, and the context ramp is the honest cost both paths still pay.

Knowledge and control: what the spreadsheet cannot see

A rooted bookshelf built into a wall beside an equally full wheeled bookcart pointed toward the door, a librarian between them — Knowledge kept in the walls compounds; knowledge on wheels must be deliberately anchored.

The deepest argument for in-house is not cost; it is compounding. An internal engineer's second year is worth more than the first: they know why the architecture bends where it does, which customer drove which constraint, where the bodies are buried in the billing code. That knowledge shortens every future project, and it stays, feeding the next hire's ramp, until the person leaves, which is the model's mirror risk: key-person concentration, where one departure takes a subsystem's living memory with it. Outsourced knowledge has the opposite default: it accumulates in people whose contract ends, and at handover it evaporates unless retention was engineered from the start, documentation as a deliverable, internal engineers embedded in the external team, code review by staff who will own the system, and overlap periods written into the contract rather than improvised at the end.

Control is the second invisible column, and it is about incentives more than oversight. An employee's career is entangled with the company's long game; refactoring that pays off next year is rational work. A vendor on time-and-materials has no structural reason to reduce billable hours, and a vendor on fixed price has every reason to interpret scope narrowly; neither is dishonesty, both are incentive gradients that contracts can flatten but not erase. The practical mitigations are ownership design: product direction and architectural authority stay internal, external work lands in your repositories under your review from day one, and scopes are outcome-shaped where possible. A vendor working in your codebase, your CI and your standards is auditable continuously; a vendor delivering a zip file at the end is auditable once, too late.

Quality risk deserves symmetry too, because the folklore assigns it entirely to outsourcing. Internal teams stagnate: without fresh input they entrench their habits, and a mediocre internal hire is far harder to remove than a mediocre vendor engineer, who can be swapped in a week. External teams that specialize, a firm that has built twenty logistics platforms, arrive with pattern knowledge no first-time internal team has. The realistic quality statement is that variance is higher outside, the best vendors rival anyone and the worst are catastrophic, which is why vendor selection diligence, reference calls, trial projects, code audits of past work, carries the weight that hiring interviews carry internally. The partner evaluation guide treats that diligence as the project it is.

Mixing internal and external teams well

Do this

Keep architecture and product direction internalThe decisions that compound stay with people whose incentives compound too. External teams execute under that authority.
Engineer knowledge retention into the contractDocumentation as a deliverable, embedded internal reviewers, handover overlap. Retention improvised at contract end is retention lost.
Work in your repositories from day oneYour git, your CI, your review standards. Continuous auditability beats end-of-project discovery.

Not this

Outsource the differentiator to save moneyRenting the moat out is the most expensive saving available. Core work belongs to people who stay.
Judge vendors by rate card aloneVariance outside is huge; the cheap catastrophic vendor costs more than the expensive good one. Diligence is the price of the model.
Let time-and-materials run without outcome anchorsBillable-hour incentives need milestones, demos and scope discipline pulling the other way.

The default and the engineered outcome, illustrative: without retention work, most system knowledge walks out with the external team; with documentation deliverables, embedded reviewers and overlap, the balance flips.

Where each model characteristically breaks

Two bridges over one river, a stone bridge missing its first arch and a rope bridge sagging under unattended crates, both flagged — In-house breaks at the start, in hiring; outsourcing breaks in the middle, in unmanaged handoffs.

In-house failures follow a pattern. The hiring stall: the roadmap assumes five engineers, the market delivers two, and the plan quietly becomes fiction while the requisitions age. The key-person trap: the payments system lives in one head, salary negotiations become hostage negotiations, and a resignation letter is an outage. The skill freeze: the team that built the monolith defends the monolith, and the company's technical ceiling becomes the comfort zone of its longest-tenured engineers. And the fixed-cost squeeze: headcount hired for the peak becomes payroll in the trough, and the layoff that follows burns morale and employer brand for years. None of these are exotic; every scaled engineering organization has survived most of them.

Outsourcing failures follow their own pattern. The knowledge cliff: the contract ends, the team disperses, and six months later nobody can explain the deployment scripts. The communication tax: requirements filtered through time zones and account managers arrive distorted, and a misunderstanding that a hallway conversation would have caught costs a sprint. The incentive drift: hours grow to fill the budget, or fixed-price scope shrinks to fit the margin. The dependency lock: the vendor becomes the only entity that understands the system, and rate negotiations invert, the customer negotiating with its own memory. And the quality lottery: the sales team's seniors demo, the delivery team's juniors build, a bait-and-switch that reference checks and named-engineer contracts exist to prevent.

The instructive point is that the mitigations for both lists are managerial rather than model-inherent. Hiring stalls yield to pipeline discipline and external bridging; key-person risk yields to documentation and rotation; knowledge cliffs yield to retention engineering; incentive drift yields to outcome-shaped contracts and continuous review. Companies that run either model well look similar in one respect: they treat the model's known failure modes as operational risks to be managed, not as surprises. Companies that fail at either usually skipped that step, chose the model for its brochure and inherited its pathology.

The knowledge retention checklist

Document the systems only one person understandsKey-person risk is an in-house certainty, not a possibility. Rotation and writing are the insurance.
Write knowledge retention into every external contractDocumentation deliverables, internal reviewer embedding, handover overlap with acceptance criteria.
Anchor time-and-materials work to outcomesSprint demos, milestone reviews and scope discipline flatten the billable-hour gradient.
Name the engineers in the contractThe team that demos is the team that delivers, with replacement approval rights on your side.
Keep a second source of understandingInternal engineers reviewing external code, or a second vendor on an adjacent workstream. Dependency lock is negotiating with your own memory.
Match headcount shape to demand shapeFixed internal core for permanent load, elastic external capacity for the lumps. The squeeze and the stall are both shape mismatches.

The hybrid patterns that usually win

A rowing shell crewed by figures in two shades rowing in perfect sync, steered by a cox holding the rudder — Core ownership steers; blended capacity rows; the wake is one product.

Pure models live at the extremes: the three-founder startup with no budget for vendors, the enterprise with a thousand engineers and a hiring brand. Between them, most companies that build software steadily converge on hybrids, and the convergent designs are worth naming. The core-and-capacity pattern: a small internal team, often just a handful of senior engineers, owns architecture, product direction, code review and vendor management, while external teams supply build capacity under that core's technical authority. The internal core is the keel: it keeps knowledge aboard, holds the quality bar and makes the external capacity swappable rather than load-bearing. This is the single most common successful shape, and it scales from a startup with one staff engineer directing a vendor squad to an enterprise running dozens of blended teams.

Three variants cover most of the rest. The specialty-rental pattern: a fundamentally in-house organization that contracts narrow expertise, security audits, data engineering spikes, a payments integration, for weeks or months, buying skills it would be irrational to employ permanently. The workstream-split pattern: core product in-house, entire context workstreams, the admin portal, the data pipeline, the legacy maintenance, delegated to an external team end to end, with interfaces and acceptance criteria as the contract surface. And the build-operate-transfer pattern for companies converging on in-house at scale: an external partner builds and runs a team in a lower-cost location, then transfers it into the company as a captive center once it is proven, the path the offshore development center guide walks in detail.

What makes hybrids work is the same discipline that makes either pure model work, applied at the seam: unambiguous ownership of every system, one definition of done enforced by one review standard across internal and external contributors, and knowledge flowing to people who stay. What makes hybrids fail is seam neglect: two teams, two standards, an integration nobody owns, and accountability that evaporates exactly at the boundary where the models meet. The seam is a managed artifact; staffing it, a technical lead whose explicit job is the boundary, is the cheapest insurance the model offers.

Deciding the sourcing mix in a month

Split the portfolio: core versus contextWeek one

One honest pass over the roadmap. The competitive test: would customers move if a rival shipped it? Core stays in, context can go out.
Size the internal coreWeek two

Enough senior engineers to own architecture, review every external line and hold product direction. The keel, not the crew.
Choose the external shapeWeeks two and three

Capacity under your direction, a specialty rental or a whole workstream. Different contracts, different management load.
Run selection as diligence, not procurementWeeks three to six

References, trial project, code audit, named engineers. The variance outside is the risk; selection is the control.
Staff the seamFrom day one

One technical lead explicitly owning the boundary: standards, review, knowledge flow, integration. Seam neglect is how hybrids die.

The convergent shape, illustrative: a small internal core holding architecture, direction and review, with external capacity absorbing the lumpy build load that pure in-house overstaffs for and pure outsourcing cannot be trusted with.

Making the call for your situation

Compressed to a decision, the question resolves through four filters. First, the work: is it core or context? Core work defaults in-house, or to the core-and-capacity hybrid if hiring cannot keep pace; context work defaults external, because spending hiring capacity on commodity problems is the quiet strategic error. Second, the clock: is there a deadline that hiring cannot meet? A funded startup racing a market window or a company facing a regulatory date often has no real in-house option for the work in front of it, whatever the long-term plan says. Third, the duration: is the need permanent or temporary? Permanent load justifies permanent staff; spikes, specialties and one-off builds fit contracts. Fourth, the management capacity: directing an external team well takes real internal bandwidth, a product owner and a technical reviewer at minimum, and a company that cannot staff that seam will fail with any vendor, however good.

The stage-typical answers fall out of the filters. Pre-product startups split by founder composition: technical founders build in-house by default; non-technical founders choosing between a slow first hire and a fast external build usually ship sooner with the external team plus a plan to hire around the core after validation. Growth-stage companies live in the hybrid: internal core, external capacity, specialties rented. Enterprises optimize portfolio by portfolio, in-house for differentiators, external for context, captive centers where scale justifies them. The pattern across stages is consistent: the in-house share of core work rises as the company's hiring machine matures, and the external share concentrates into capacity and context.

Two closing honesty checks, one per direction. If you are choosing in-house, verify the hiring math with your own recent data, time-to-fill, offer acceptance, attrition, not with the plan's optimism; a roadmap built on hires that do not arrive is the most common in-house failure and it is self-inflicted. If you are choosing external, verify you are buying a team, not a rate card: the diligence in the software partner evaluation guide is the difference between the model's good outcomes and its folklore. Both models reward the same underlying competence, clear ownership, honest scoping and managed knowledge, and punish its absence. The model is the smaller choice; running it well is the larger one.

Sourcing terms worth knowing

Fully loaded cost: An employee's true cost: salary plus taxes, benefits, equipment, management overhead and amortized hiring cost, commonly one and a half to two times base.
Core versus context: The dividing line between differentiating work, which compounds and belongs in-house, and necessary generic work, which can be rented.
Dedicated team: External engineers working as a standing unit under the client's direction, blending vendor elasticity with in-house-style integration.
Build-operate-transfer: A partner builds and runs a team in a lower-cost location, then transfers it to the client as a captive center once proven.
Key-person risk: Concentration of a system's living knowledge in one head, making a resignation an outage. An in-house default unless managed.
The seam: The boundary between internal and external teams in a hybrid: standards, review, integration and knowledge flow. Unowned seams are how hybrids fail.

The four filters compressed to one tree: what the work is, what the clock says, how long the need lasts, and whether you can staff the seam. Different workstreams legitimately take different branches inside one company.

Frequently asked questions

Is it cheaper to outsource development or hire in-house?

It depends on what you count and where you compare. An internal engineer's fully loaded cost, salary plus taxes, benefits, equipment, management overhead and amortized hiring, runs roughly one and a half to two times base salary in most Western markets, and against that figure, strong external teams in lower-cost regions are usually cheaper for equivalent output. Against local contractors or onshore agencies, in-house often wins on steady long-term load. The comparison also has non-price columns: external teams start in weeks rather than a quarter and scale down without layoffs, while internal knowledge compounds instead of leaving at contract end. Run the loaded numbers for your actual roles and durations rather than comparing a salary to a rate card.

What should never be outsourced?

Your differentiator, the core work customers actually pay you for, and the authority over it. That means product direction, architectural decisions and the code that embodies your competitive advantage should stay with people whose incentives run on your company's timeline. Everything around the core is negotiable: build capacity executing under internal architectural control, whole context workstreams like admin tooling and pipelines, and temporary specialties like security audits or a payments integration. The test for core is competitive: if a rival shipped the same component tomorrow, would customers move? If yes, own it; if no, it is context and renting it is usually the better use of your hiring capacity.

What are the biggest risks of outsourcing?

Five recur. Knowledge loss: the system's understanding leaves when the contract ends, unless retention, documentation deliverables, embedded internal reviewers, handover overlap, is engineered from the start. Communication overhead: requirements filtered through distance and account layers arrive distorted. Incentive drift: time-and-materials work has no structural reason to minimize hours, and fixed-price work has reasons to minimize scope. Vendor dependency: when only the vendor understands the system, negotiations invert. And quality variance: the spread between the best and worst external teams is far wider than between internal hires, which is why reference checks, trial projects and named-engineer contracts carry the weight interviews carry internally. All five have known mitigations; all five punish skipping them.

What is a hybrid model in software staffing?

A structure where a small internal core, senior engineers owning architecture, product direction and code review, directs external capacity that does much of the building. The core keeps knowledge aboard and holds the quality bar; the external teams provide elasticity for lumpy demand, specialties for temporary needs, or whole context workstreams behind defined interfaces. Variants include specialty rentals inside an otherwise in-house team, workstream splits where a vendor owns non-core systems end to end, and build-operate-transfer, where a partner builds a team offshore and later transfers it in as a captive center. Most companies past their first product converge on some version of it, because the hybrid captures each pure model's strength while managing its known failure mode.

When does in-house make more sense than outsourcing?

Four conditions favor it strongly: the work is your core differentiator, so its knowledge should compound in people who stay; the load is permanent rather than spiky, so fixed staff match fixed demand; your hiring pipeline demonstrably delivers, measured by your own recent time-to-fill and acceptance rates rather than the plan's optimism; and the work needs daily entanglement with the business, product discovery, rapid iteration with sales and support, where collocation or at least employment-grade commitment beats any contract. Companies meeting all four should default in-house for that work and still rent specialties and absorb spikes externally, which is how the standard hybrid forms.

How do I keep control over an outsourced project?

Design ownership before signing. Keep product direction and architectural authority internal, with a named technical lead whose explicit job is the boundary. Have the external team work in your repositories, your CI and your review standards from day one, so auditability is continuous rather than a discovery at delivery. Shape the contract around outcomes: milestones, sprint demos and acceptance criteria pulling against the billable-hour gradient. Name the engineers in the agreement with replacement approval on your side, so the team that demos is the team that delivers. And write knowledge retention in as deliverables, documentation, internal reviewer embedding, handover overlap, because control after the contract ends depends entirely on what you retained during it.

In-house versus outsourcing is a strategy question wearing a procurement costume: own the core, rent the context, and run whichever model you pick with its failure modes managed. For the loaded cost math, the control tradeoffs and the hybrid that usually wins, read the in-house versus outsourcing guide.