Vend of the line: how productized service studios plan and ship end-to-end game production

Vend of the line

The phrase “vend of the line” reads like a mishearing of the more common “end of the line,” and inside game production that ambiguity is useful. A studio that “vends” a complete game is one that takes a brief and returns a shipped, supported title without handing the work off midstream. The line is the production line, the sequence of disciplines that turns a concept document into a running build, and the question of who owns each station along that line is the practical question most teams answer badly. A productized service studio is one that has standardized those stations: a fixed menu of capabilities, predictable inputs and outputs, and a contract that names who carries the risk at each gate.

This article looks at how full-service game studios actually plan, staff, and run that line. It focuses on the production choices that determine whether a project survives a vertical slice, passes certification, and reaches live operations on a budget a publisher will accept. The relevant reference for the vending model as a service category is the Full-line vending overview of how single-vendor service contracts are structured and priced; the same structural logic, applied to creative and engineering work, is what makes a game studio “full-line” rather than a collection of freelancers.

What a productized full-line game studio actually sells

A productized game studio does not sell hours. It sells a defined output: a vertical slice, a soft-launch build, a port to a new platform, or a complete title with twelve months of live operations. The product frame is what separates this model from a traditional work-for-hire shop, which is paid for bodies and tools, and from a co-development shop, which is paid for a defined feature set inside someone else’s project. Each of these has a place, but the full-line vendor absorbs the integration cost that the others leave with the client.

Three contracts describe most of the market:

• Fixed-price product contract. A publisher or brand owner pays a defined amount for a defined deliverable. The vendor carries the cost of overruns, which makes scope control the central production discipline.
• Time-and-materials co-development contract. The client pays for a defined team over a defined period, and the vendor bills monthly against a staffing plan. Risk sits with the client, but the vendor still has to manage velocity.
• Risk-share or revenue-share contract. The studio funds part of development in exchange for a share of revenue, IP rights, or both. This is the model most likely to behave like a real publisher and the one that punishes weak pre-production the hardest.

The line itself, in any of these, has the same shape: a concept stage, a pre-production stage that resolves risk, a production stage that builds content, a release stage that certifies and launches, and an operations stage that keeps the build healthy. A studio that vendors the full line is one that signs up for all five under a single contract and a single production owner.

Why the term keeps surfacing in game production conversations

Search interest in “vend of the line” is small, but the related concepts are loud. Publishers have spent a decade consolidating their vendor lists because integrating ten specialists costs more than hiring one full-line studio. Platform holders now treat certification as a vendor capability, not a publisher task, because the studios that ship reliably have already absorbed certification into their own pre-submission process. Live-service publishers want a single accountable partner for content drops, balance patches, and platform updates, because every handoff is a place where context leaks.

The pressure flows in the other direction too. Independent developers who used to assemble a team of freelancers for each project now prefer to hire a studio that can take a vertical slice and carry it to release, because the alternative is a six-month search for a different technical artist, a different engine programmer, and a different QA lead every time the project moves into a new phase. The line that used to run inside a single building now runs across a contract, and a vendor of the line is the company that has standardized the contract so the line can cross without breaking.

Reading the brief: what an end-to-end studio asks for

A full-line brief is denser than a co-development brief because the client is handing over decisions as well as work. A serious intake covers the following areas before any estimate is written:

• Audience and platform scope. Target hardware, target storefronts, and the realistic frame-rate and memory budget for each. A console that is no longer in active production is rarely a viable primary target because the certification cost is amortized over a smaller installed base.
• Reference and IP constraints. What the client owns, what the studio owns from previous projects, what third-party middleware must be licensed, and what music, voice, or likeness rights have to be cleared.
• Milestones and acceptance criteria. The dates and artifacts that define done for the concept, vertical slice, alpha, beta, and release candidates. A vague milestone is a contract dispute waiting to happen.
• Live operations and sunset terms. Whether the studio runs the title for one quarter or five years, who owns player data, and how a sunset or handover is staged.

A studio that cannot describe how each of these turns into a line item in the production plan is not really vending the line; it is selling capacity and hoping the client defines the product. The first gate of a full-line engagement is the brief itself, and studios that ask the wrong questions here spend the rest of the project reworking decisions that should have been locked at intake.

Designing the production line before designing the game

Pre-production is the stage where the line gets drawn. A useful pre-production plan names the disciplines, the artifacts, and the review gates that move the project from one station to the next. The shape is similar across engines and genres, but the load on each station changes with the type of game.

A practical pre-production map looks like this:

Stage	Primary outputs	Owning role	Exit gate
Concept	Pitch deck, audience model, reference analysis, technical risk register	Producer and design lead	Signed creative brief and risk register
Vertical slice	One playable level, target performance, art style guide, audio direction, validated pipeline	Multi-discipline leads	Approved slice, locked feature list, dated production schedule
Production	Full content set, feature-complete build, localized assets, certification-ready submission	Discipline leads under a production owner	Code-complete, content-complete, localization-complete sign-off
Release	Day-one build, store assets, marketing integration, post-launch monitoring	Release manager and operations lead	First live day with no P0 defects
Operations	Live patches, content drops, balance work, player support tooling	Operations lead and community manager	Quarterly operating reviews and a defined sunset plan

The exit gates are the contract. A line that can be moved sideways is a line that can be cut, and a full-line studio is one that has decided which gates are firm, which are negotiable, and what evidence is required to walk through each one.

Capability staffing along the line

Full-line does not mean the studio employs every specialist in-house. It means the studio owns the integration of those specialists, whether they sit on payroll, on long-term contract, or inside a partner network that the studio can reach inside the schedule. The honest answer to a client about who is doing the work is part of the product.

Disciplines that almost always sit in-house for a vendor of the line:

• Production and project management, because the line needs a single owner who is paid to say no.
• Engineering leadership, because the engine, tools, and pipeline decisions bind every other discipline.
• Art direction, because the visual identity of the title has to survive dozens of contributors without drifting.
• QA strategy, because the test plan is built into the schedule, not added at the end.
• Release management, because the certification, store submission, and day-one operations are the stage where most full-line projects fail.

Disciplines that are often hired per project without weakening the full-line pitch:

• Niche specialists: shader programmers for a specific lighting effect, vehicle physics engineers for a racing title, animation retargeting specialists for a port.
• Localization production, because the volume is bursty and the vendor relationship benefits from a partner with translation memory tools and a tested QA loop.
• Audio outsourcing for non-interactive music and licensed stems, provided the studio owns the integration and the mix.
• Platform-specific certification engineers for less common targets, where a temporary contractor is more cost-effective than a permanent hire.

The studio’s job is to keep the line running while these contributors come and go, which is why documentation, build automation, and onboarding are the most important investments a full-line studio makes in its own infrastructure. A studio that depends on tribal knowledge cannot onboard a specialist without slowing the project down.

Estimating a full-line engagement without lying

The hardest station on the line is the estimate. A studio that promises a number before the brief is locked is gambling with the client’s money, and a studio that hides the risk in a vague “to be determined” is gambling with its own margin. The honest middle path is a two-stage estimate.

1. Stage one, a range bound by the brief. Given the audience, platform, and milestone structure the client has actually defined, the studio produces a low and high range with the assumptions written next to it. The range is wide because the brief is incomplete; the assumptions are the contract the client has to break to move the number.
2. Stage two, a fixed price after the vertical slice. Once the slice has resolved the technical and artistic risks, the studio replaces the range with a fixed price for the remaining work. The vertical slice cost is treated as a sunk investment that the client has already agreed to fund.

This structure protects the studio from scope drift and protects the client from a price that reflects worst-case risk on day one. It also creates a natural review point: if the client refuses to fund the vertical slice, the studio has not yet committed to the project, and the client has not yet committed to the studio.

A useful range answers four questions explicitly:

• What content is included, and what is excluded as a change order?
• What platform work is included, and what is treated as a separate port?
• What live operations period is included, and how is work after that period priced?
• What happens if certification fails, and who owns the resubmission cost?

Studios that cannot answer those four questions in writing tend to discover the answers during a crisis, and crises on a full-line contract are expensive for both sides.

Risk registers that actually reduce risk

Risk registers in game production are often treated as paperwork. The full-line model makes them load-bearing because the studio is on the hook for the consequences. A useful register has three columns that survive contact with reality: the risk itself, the signal that the risk is becoming real, and the response the studio will run if the signal trips.

Risk	Early signal	Pre-planned response
Target frame rate not met on minimum-spec hardware	Profiler shows the slice misses the budget on a representative build	Reduce per-frame particle budget, cut shadow map cascades, defer post-process to half resolution
Content authoring slower than the schedule assumes	Two consecutive content weeks miss the planned count	Cut a non-critical content stream, shift the cut into the post-launch plan, notify the client before the next sprint review
Live operations volume exceeds the planned support load	Support backlog grows past one business day for two consecutive weeks	Hire temporary support, move low-priority work to a queue, communicate the queue length to the publisher
Platform certification rejection on a known rule	Pre-certification audit flags the rule on the candidate build	Run a focused fix sprint, add the rule to the pre-cert audit checklist, document the regression test

The response column is the part most teams skip, and skipping it is what turns a risk register into decoration. A response that has been written before the signal appears is cheap to run; a response that has to be invented during a crisis is always more expensive than the team expects.

Pipeline engineering as a product feature

A full-line studio’s pipeline is the assembly equipment the line runs on. The studio does not sell the pipeline to the client, but the client feels the pipeline in every weekly build. A pipeline that builds a representative target in under an hour, that catches asset regressions on check-in, and that produces a clean release candidate without manual steps is the difference between a project that ships on time and one that runs out of year.

The investments that pay off across projects:

• Continuous integration on representative hardware. A build server that runs the title on a target-spec PC or a devkit, not just on the developer’s workstation, catches memory and frame-time regressions the day they arrive.
• Asset validation on import. Mesh budgets, texture resolutions, and naming conventions checked at the moment the asset enters the project, with a fail state that blocks the bad asset from reaching the build.
• Automated localization hooks. String tables extracted and re-injected without a manual pass, so a localization vendor can deliver an updated language build without an engineer babysitting the process.
• Crash and telemetry dashboards. Live builds that report anonymized performance and stability data to a dashboard the producer can read, so live operations decisions are made on evidence rather than on the loudest player report.

These are not glamorous investments, which is why they are the ones that separate a vendor of the line from a co-development shop. A co-development shop inherits the pipeline from the project owner; a full-line studio has to build its own and keep it warm between projects.

Quality assurance as part of the line, not a tax on it

Full-line QA is not the test pass at the end of production. It is the discipline that runs in parallel with every other station, and it is the discipline that determines whether a release candidate survives certification on the first submission. A studio that treats QA as a separate cost center usually pays for that separation in certification rejections, in post-launch defects, and in the support tickets that follow.

Three QA practices that earn their keep on a full-line project:

• Test plans tied to features, not milestones. A feature has an acceptance test before the first vertical slice, and that test is the definition of done for the feature. Tests that are written at the end of production are tests that have to be re-run against a moving target.
• Compatibility and certification rehearsal on a candidate build. The submission build is treated as a release candidate, with a freeze period during which only blocker fixes are accepted. The freeze is announced in the schedule, not improvised when the submission date approaches.
• Player support and telemetry read on the live build. A live service title needs a documented feedback loop from the support inbox to the engineering backlog. Without that loop, the same defect is reported by a thousand players and never reaches a fix.

The studios that ship reliably are the ones that run these three practices on every project, not the ones that invented them for a particularly difficult certification cycle.

Live operations as a contracted line

Live operations is the station most often sold as an afterthought and then renegotiated when the title launches. A full-line studio is the studio that puts a defined live operations period in the contract, names the deliverables, and plans for the post-contract transition. The shape of a useful live operations contract is short enough to read in a single meeting:

• Content cadence. A defined schedule of content drops, with the size of each drop named in terms of playable units, not in vague terms like “minor update.”
• Balance and live tuning. A weekly or biweekly patch cadence with a documented test pass before each patch reaches the storefront.
• Platform compliance. Responsibility for staying current with platform rules, SDK updates, and storefront policy changes, including the cost of re-submission.
• Support scope. Defined channels, defined response times, and a clear escalation path for legal, safety, and accessibility issues.
• Sunset plan. The notice period, the data retention policy, and the artifacts the studio hands back to the publisher at the end of the engagement.

A live operations contract that is silent on any of these five is a contract that will be re-priced under pressure, and a full-line studio should be the one writing the clean version, not the one accepting the client’s first draft.

How a vendor of the line handles platform changes

Platforms are not static. Storefronts change their rules, console manufacturers refresh their certification requirements, and engine vendors ship breaking changes that affect the build pipeline. A full-line studio absorbs those changes into its own process, rather than billing them to the client as surprises. The practical list of things that should be inside the studio’s own cost base:

• Subscription and seat costs for engine, middleware, and SDK access, accounted for at the studio level rather than billed per project.
• Time spent keeping pre-certification audit scripts current, treated as overhead rather than as a change order.
• Maintenance of internal templates for store assets, age ratings, privacy disclosures, and other compliance paperwork that recurs across every project.
• Training time that keeps the team current on the latest LTS engine releases, which is the difference between a project that can upgrade safely and one that is frozen on a legacy version.

This is the hidden margin in a full-line contract. A studio that does this work between projects ships on schedule; a studio that does it on the client’s time is the studio that misses the certification window by a week and pays for it out of the next engagement.

Reading the contract for the traps that hurt full-line studios

Three contract shapes are common enough to be worth a specific warning.

Soft milestones with no acceptance criteria. A milestone that pays on a date rather than on a deliverable is a milestone that the client can extend by changing the deliverable. Studios that accept date-based milestones without an acceptance document are essentially lending the client the float in the schedule, and the float always gets spent.

Vague IP assignment language. A contract that says the studio assigns “all work product” without defining what counts as a pre-existing tool, a third-party middleware, or a shared engine component is a contract that ends in a dispute when the studio’s next project needs to reuse the same internal tool. Studios that license their tools and engine code to the client, rather than assigning them outright, protect their own pipeline and give the client a clearer picture of what they own.

Unlimited live operations scope. A live service contract that obliges the studio to “support the title” without a defined response time, a defined bug priority, or a defined change order is a contract that has handed the studio’s schedule to the support inbox. The fix is to price support on a tiered model with a base load and an overage, and to put the overage in writing.

When a full-line contract is the wrong answer

Full-line is a strong default for projects that need a single accountable owner across concept to live operations. It is the wrong answer when the project is small enough that the integration cost outweighs the benefit, when the client already has an internal team that needs a specific capability rather than a whole studio, or when the project is a prototype that will be killed regardless of outcome.

Three cases where a different contract serves the project better:

• Pure prototype work. A studio that vendors the full line is not the cheapest place to validate a mechanic. A short, time-boxed co-development engagement with a defined prototype artifact is faster and cheaper.
• Specialist augmentation. Adding a single technical artist or audio programmer to an existing internal team is rarely improved by wrapping the engagement in a full-line contract. The contract overhead is higher than the work.
• Platform port only. A port between two known platforms is a contained project that benefits from a fixed scope, not from a contract that assumes the studio is also running live operations.

A good studio will tell a client when the full-line model is the wrong fit, and a good client will listen, because the alternative is paying for integration work the project does not need.

Pricing models that hold up under audit

Full-line pricing is a long-running argument inside the industry, and the patterns that survive scrutiny are narrower than the marketing copy suggests.

Model	What it covers	Where it works	Where it strains
Fixed price by milestone	Defined deliverable at a defined date, with a change order process for scope additions	Predictable scopes such as ports, remastered editions, and templated content drops	Original IP titles where the scope changes as the design is tested
Cost-plus with cap	Studio costs plus a defined margin, with a cap that protects the client	Long-running live operations and titles that evolve significantly after launch	Short original-IP productions where the client wants a number to plan against
Risk-share revenue split	Studio funds part of development in exchange for a share of net revenue	Original IP where the studio and the publisher both expect a real upside	Titles with a soft revenue expectation or a publisher that needs predictable cash flow
Retainer plus usage	Defined monthly retainer for a live team, plus usage-based billing for content drops above the retainer	Mature live service titles with a steady content cadence	Early live operations where the volume is not yet predictable

Each model has a place, and a studio that offers only one of them is forcing its clients into a contract shape that may not match the project. The honest answer to “what does this cost” is “it depends on which model fits the engagement,” and a vendor of the line is one that can explain the trade-offs in writing.

Commercial leverage inside a full-line contract

Commercial leverage is the part of the contract that most studio principals think they understand and most studio finance leads can explain better. The five terms that change the actual outcome of an engagement:

• Payment terms. Net thirty from invoice acceptance is the standard. Net sixty is a loan from the studio to the client, and the studio’s pricing has to reflect that.
• Milestone acceptance window. A defined period, usually five to ten business days, during which the client must accept the milestone or raise specific written objections. A milestone that can be held open indefinitely is a milestone that never gets accepted.
• Change order threshold. A written change order is required once a defined percentage of the remaining budget is consumed by additional requests. Without the threshold, scope creep is invisible until the project is in the red.
• Kill fee. A defined payment to the studio if the client cancels the project, sized to cover the studio’s committed costs and a defined margin on the lost pipeline.
• Warranty period. A defined window, usually ninety days, during which the studio fixes defects in the delivered build at no additional cost. After the window, defects are priced as live operations work.

A contract that does not address all five is a contract that has left the financial outcome to be decided by the team under pressure, which is rarely the team that wrote the proposal.

Briefing the client on what a full-line studio needs from them

A surprising amount of full-line production risk lives on the client side, and a vendor of the line has to say so out loud. The studio can staff, schedule, and execute, but there are decisions only the client can make, and a project that runs out of runway is often a project where those decisions arrived late.

Decisions a full-line studio should pin to a date in the schedule:

• Final creative sign-off on the vertical slice, with a calendar date and a documented approval process.
• Final feature lock, with a list of features that are explicitly out of scope for the initial release.
• Marketing and store asset timing, including trailer drops, screenshots, age rating submissions, and store page updates.
• Live operations content themes and licensed asset pipeline, so the studio can start production before the post-launch window opens.
• Player data ownership, privacy policy, and any required regional compliance, because these decisions affect the engineering backlog.

The studio that raises these dates before signing the contract is the studio that does not have to renegotiate the project at month four. The studio that does not raise them is the studio that absorbs the cost of late decisions in its own margin.

How Veldrake Studios structures a full-line engagement

Veldrake Studios works as a productized full-line game studio, and the production choices described above are not theoretical inside the team. The studio is built around a concept-to-live pipeline, with a defined intake, a two-stage estimate, and a live operations contract that includes a sunset plan. The team is structured to keep the line running when a contributor joins for a project and leaves when the project moves into the next stage, which is why documentation, build automation, and onboarding are treated as core deliverables rather than as overhead.

The studio’s service pages describe the work in the same language used in this article. The Game Design Agency page describes how a full-line engagement starts at the concept and audience layer, with risk assessment and reference analysis as the first artifacts. The 3D Game Developers page describes the engineering and technical art capability that carries the project from vertical slice through certification, and the 3D Outsourcing Companies page describes the partner network the studio uses to add niche specialists without breaking the line. Together those pages show how the line is staffed and run, and they are a useful reference when comparing a full-line proposal to a co-development or work-for-hire alternative.

Validation: how a client checks the line before signing

A prospective client has more leverage in the first week of a conversation than at any later point, and a few practical checks turn vague promises into verifiable evidence.

• Ask for the last three milestones the studio delivered and the acceptance documents that closed them. A studio that can produce those is a studio that runs on contracts rather than on handshakes.
• Ask which risks on the studio’s own risk register tripped on the last project and how the pre-planned response was used. The answer tells the client whether the register is a live document or a template.
• Ask for a one-day paid diagnostic, with a written output, rather than a free consultation. A studio that is willing to be paid for a small piece of work is a studio that will be willing to be paid for the larger piece.
• Ask to see the production schedule, with the same level of detail, for two previous projects. Schedules that change in format between projects are schedules that have been rewritten after the fact.
• Ask who owns the studio’s internal tools and how the client licenses them. A clean answer is a short answer; a vague answer is a future dispute.

The checks take a week and turn a sales conversation into a production conversation, which is where the work actually happens.

Frequently asked questions

What does “vend of the line” mean in game production?

The phrase is a common rendering of “end of the line” applied to a full-line service studio. A vendor of the line takes a brief at the start of a project and returns a shipped, supported title at the end, owning the work across concept, pre-production, production, release, and live operations under a single contract and a single production owner.

How is a full-line game studio different from a co-development studio?

A full-line studio signs up for the integration of every discipline and is accountable for the final product. A co-development studio signs up for a defined feature set inside someone else’s project, with the project owner carrying integration, certification, and live operations risk. Both are valid, and the right answer depends on whether the client needs a single owner or a specialist extension of an existing team.

What is a vertical slice and why does it matter in a full-line contract?

A vertical slice is a short, playable section of the game that uses the final art style, runs on target hardware, and exercises the production pipeline end to end. It is the artifact that lets a vendor of the line replace a range estimate with a fixed price, because the slice resolves the technical and artistic risks that drive most production cost.

How does a full-line studio price a project that is not yet scoped?

The honest approach is a two-stage estimate. Stage one is a low and high range bound to the assumptions in the brief. Stage two is a fixed price after the vertical slice, when the assumptions have been replaced by measured evidence. The two-stage model protects both sides from committing to a number that the project has not yet earned.

What is the difference between release and live operations in a full-line contract?

Release is the work that takes the build from code-complete to day-one live, including certification, store submission, and the first day of monitoring. Live operations is the work that keeps the build healthy afterwards, including content drops, balance patches, platform compliance, and player support. A full-line contract names which period is included, which deliverables sit in each period, and how work after the contract ends is priced.

Who owns the internal tools and pipeline the studio uses to ship the game?

The studio owns its internal tools, and the client licenses the use of those tools for the duration of the project. The contract should make this explicit, because tools that are not named in the contract become a dispute at the end of the engagement. Studios that assign their tools outright to the client are usually the studios that have to rebuild the same tool for their next project.

How does a full-line studio handle a platform certification rejection?

The studio treats the rejection as a pre-planned risk and runs a focused fix sprint against the documented rule. The fix is regression-tested against the rest of the submission checklist, and the rule is added to the pre-cert audit so the same defect cannot return on the next submission. The cost of the fix is inside the production budget, and the timeline impact is communicated to the client before the fix begins.

When is a full-line contract the wrong choice?

Full-line is the wrong choice for a short prototype, for a single-discipline augmentation of an existing team, and for a contained platform port where the scope is known up front. In each of those cases, a time-boxed co-development engagement, a staff augmentation contract, or a fixed-scope port contract is faster and cheaper than wrapping the work in a full-line agreement.

How long should a live operations contract run?

The honest answer is “as long as the live service earns its keep.” Most full-line studios structure live operations as an initial period of six to twelve months, with an option to renew in defined increments. The renewal is tied to a quarterly operating review so the publisher and the studio can see the cost and the live metrics before extending.

What is the single biggest production risk a full-line studio has to manage?

Scope drift is the risk that most often turns a fixed price into a loss. The defenses are a brief that is signed before the estimate, a vertical slice that locks the feature list, a written change order process, and a milestone acceptance window that forces the client to accept or reject the deliverable inside a defined period. A studio that runs all four defenses is a studio that ships on margin.

Related reading

• 3D Character Design Services: Ultimate Studio Guide
• Crimson Desert interactive map: regions, landmarks, and navigation