The practical answer is rarely “build everything” or “buy everything.” For most Unity teams, the strongest starting point is a hybrid architecture: keep the product behaviour that differentiates your experience in-house, then decide whether character-performance production should also become an internal software product.
Build the performance layer yourself when it is core intellectual property, when your characters or deployment environment are unusually specialised or when you need capabilities that Snippets3D does not currently provide. Consider Snippets when your project uses supported Unity versions, your dialogue is authored or approved and the recurring burden is turning that content into reviewable, reusable 3D performances.
The choice should be based on ownership, fit and full lifecycle cost. It should not be based on a generic promise that buying is always cheaper or that building is always more flexible.
First, define what you are deciding to build
A talking 3D character is not one system. It is a stack of responsibilities:
The character asset, skeleton, facial rig and visual style
Dialogue, branching, state, scoring and other application logic
Voice, timing, lip-sync, facial animation, body movement, gaze and text
Review, approval, versioning and content updates
Runtime sequencing, events and engine integration
Quality assurance, localisation, security and ongoing maintenance
Snippets is a controllable production layer for creating and delivering synchronised 3D character performances in Unity. It is not a character generator, an autonomous NPC brain or a complete application platform.
This distinction changes the decision. You are not choosing between “our product” and “Snippets.” You are deciding which parts of the stack deserve permanent internal ownership.
What an in-house character-performance pipeline must own
Unity gives teams powerful building blocks. For example, Animation Rigging provides constraints for procedural motion, inverse kinematics and rig interaction. Timeline sequences cinematic, gameplay and audio content.
Those components are useful foundations. They are not, by themselves, a complete script-to-performance production system. A team building in-house still needs to decide how it will handle the following responsibilities.
1. Character and rig preparation
Someone must define supported skeletons, facial shapes, retargeting rules, corrective animation and character-specific exceptions. The broader the character range, the more mapping, validation and repair logic the pipeline may need.
2. Performance creation
The pipeline needs a way to produce or import voice, word timing, lip-sync, facial movement, body animation, gestures, gaze, pauses and emphasis. These may come from internal systems, artists, motion libraries or external providers. The team still owns how those outputs become one coherent performance.
3. Authoring and human review
Production users need to preview a result, identify a weak section, request or make a change and approve the final content. Without a usable review workflow, technical automation can simply move work into engineering tickets and manual file handling.
4. Packaging and Unity delivery
Audio, animation, text and metadata must arrive together with stable identities and predictable dependencies. Updating a performance should not quietly break scene references, prefabs or downstream logic.
5. Runtime orchestration
The application needs to trigger performances, sequence them with other actions and connect them to movement, gaze, subtitles and events. If the experience includes branching dialogue, real-time conversation, scoring, analytics or multiplayer state, those remain separate application responsibilities.
6. Content operations
Scripts change. Reviewers ask for new timing. Products add languages. Characters and Unity versions evolve. The pipeline therefore needs versioning, permissions, release rules, regression testing and a clear owner after the first project ships.
This is the real in-house option: not a successful prototype, but an operated production capability.
What Snippets3D provides today
Snippets turns scripts, prompts or recorded audio into reusable character-performance assets that can combine voice and word timing, lip-sync, facial and body animation, gaze, text, subtitles and runtime events.
The current workflow is:
Create or select a compatible character.
Create a Snippet Set and add dialogue from a script, prompt or recorded audio.
Generate, preview and refine the performance in a browser.
Publish the approved Snippet Set.
Import or update synchronised prefabs through the Unity SDK.
Play the content directly or connect it to controller-driven scenes.
The current documentation covers Unity 2022.3 LTS, Unity 6.0 LTS and Unity 6.3 LTS. Updates preserve existing Unity references when the underlying Snippet ID remains stable, although structural changes, removals and renaming can still require review.
Snippets does not currently provide the surrounding narrative, application or intelligence layer. Your product commonly remains responsible for:
Branching logic and scenario state
Real-time conversational AI and speech recognition
Learner assessment, scoring and feedback
Analytics, reporting and LMS integration
Multiplayer and save-state management
Domain, clinical, legal or compliance validation
Complete performance generation is currently batch-oriented and cloud-assisted. Real-time or hybrid performance generation and Unreal support at parity with Unity are roadmap directions, not current promises. Custom rig compatibility, offline or on-premises deployment, API access, performance requirements and private-model integration must be verified for each opportunity.
Seven questions that usually decide build versus Snippets
1. Is character-performance technology part of your core advantage?
Build when the way performances are generated, controlled or executed is itself a differentiating product capability that you intend to own and improve.
Consider Snippets when the performance layer enables your product but is not the reason customers choose it. In that case, internal engineering time may create more value in scenario logic, learning design, gameplay, analytics or the customer experience.
2. Is the content authored or generated live?
Snippets is designed for authored or approved dialogue that can be generated, reviewed and published before or during production.
If the experience requires continuous low-latency body and facial performance from live conversation, Snippets is not the complete solution today. You will need an internal real-time path or another specialist component, potentially alongside Snippets for controlled content.
3. Does the current engine and deployment model fit?
The clearest current fit is a Unity project using a documented supported version with internet access for authoring and import.
Build or investigate other options when current requirements depend on Unreal parity, air-gapped generation, sovereign deployment or another unverified environment. Do not assume that a planned capability is available.
4. How unusual are the characters and control requirements?
If the project uses uncommon rigs, proprietary facial systems or strict animation-authoring controls, make compatibility a pass-or-fail pilot criterion.
Build when those requirements are non-negotiable and cannot be supported without turning a purchased product into a heavily customised fork. Consider Snippets when supported characters and the available refinement controls meet the production brief.
5. How often will content change?
One short scene can make a manual or bespoke workflow look inexpensive. The operational difference becomes clearer when scripts, approvals, languages, characters and releases multiply.
Estimate the expected number of performances, revision cycles and language variants. Then measure the effort needed to create, review, integrate and update a representative sample. Do not convert an internal estimate into a promised saving.
6. Who owns the pipeline after launch?
An in-house build needs named owners for engineering, technical art, animation quality, content tooling, infrastructure and support. Include maintenance through Unity upgrades and staff changes, not only the initial implementation.
A purchased layer still needs an internal owner, integration tests and a support process. Buying changes the ownership map; it does not remove ownership.
7. What must remain reversible?
Decide what happens if requirements change or the supplier no longer fits. Review asset formats, stable identifiers, data access, commercial terms, migration effort and fallback behaviour.
This matters for both choices. Internal systems can also create lock-in through undocumented code, specialist knowledge and unmaintained tools.
A transparent 12-month cost model
The Government Digital Service build-versus-buy guidance recommends evaluating full lifecycle cost rather than only acquisition or creation cost. Apply that principle with your own numbers.
For an in-house build, include:
Discovery, architecture and prototyping
Engineering, technical art and animation time
Voice, motion, lip-sync or infrastructure providers
Authoring, review and approval tooling
Unity integration, packaging and update logic
Content production, localisation and QA
Monitoring, support, documentation and training
Maintenance through engine, rig and provider changes
The opportunity cost of delaying other product work
For Snippets, include:
The current commercial subscription or agreement, confirmed with Snippets
Onboarding and Unity integration
Character compatibility and any required preparation
Content creation, review, localisation and QA
The surrounding application logic that Snippets does not provide
Security, legal and vendor-management work
Internal support, integration testing and an exit plan
Use loaded staff costs rather than salary alone. State the expected content volume, time horizon and risk contingency. Run sensitivity checks for the assumptions most likely to change, such as revision volume, custom-rig work and maintenance demand.
The result is not “buy cost versus developer salary.” It is the cost of operating two different production models.
Run one difficult pilot before committing
A polished demo is not enough. The GDS guidance recommends testing a small but difficult problem, integration with the existing stack and fit with delivery processes.
Choose a representative scene that includes the constraints most likely to fail. Depending on the project, that might mean a custom character, a demanding emotional beat, a content revision, a Unity update or a localisation case.
Run the same brief through the credible in-house approach and Snippets. Record:
Calendar time and specialist hours to the first acceptable performance
Time and people required for a meaningful revision
Manual repair work and unresolved defects
Integration effort and effect on existing Unity references
Reviewer acceptance against agreed quality criteria
Runtime behaviour on the target device
Ease of versioning, approval and content updates
Security, deployment and support gaps
Document the baseline, participants, tools, project versions and acceptance criteria. A result from one scene is evidence for that decision, not a universal benchmark.
When to build, use Snippets or combine both
Build in-house when
Performance generation or control is core intellectual property
The project requires current real-time performance that Snippets does not provide
Engine, rig or deployment requirements fall outside the verified product boundary
Your team needs deep bespoke control and has the capability to operate it long term
A representative pilot shows that external constraints outweigh workflow benefits
Consider Snippets when
The project uses a supported Unity version
Dialogue is scripted, bounded or approved before release
The team repeatedly coordinates voice, timing, lip-sync, animation, gaze, text and revisions
Browser review, reusable content and stable Unity updates solve a real operational problem
A representative technical pilot passes character, quality, integration and deployment requirements
Choose a hybrid architecture when
Your team wants to own narrative logic, scenario state, scoring or AI conversation while using Snippets for approved performance assets
Some content is controlled and reusable while other interactions are generated live
Bespoke hero moments stay artist-authored while higher-volume dialogue uses a repeatable production workflow
You need to validate the product with Snippets before deciding whether any layer should later move in-house
For many teams, hybrid is the most honest default. It keeps differentiated behaviour close to the product while avoiding the assumption that every supporting production system must become internal infrastructure.
Final decision checklist
Before approving either path, confirm that you have:
Defined the user need and the exact performance layer being evaluated
Separated non-negotiable requirements from preferences
Assigned ownership for every part of the stack
Verified current capability rather than roadmap language
Tested a difficult representative scene in the real Unity project
Compared 12-month lifecycle cost using the same assumptions
Included maintenance, support, security and exit costs
Recorded quality criteria and human review responsibilities
Chosen build, Snippets or hybrid for explicit reasons
If your project uses authored or approved dialogue in Unity, the next useful step is to see how a script becomes a speaking character, then test one representative scene through the Snippets early-access process. Keep the decision tied to your own evidence, constraints and product priorities.
Frequently asked questions
Is using Snippets always cheaper than building in-house?
No. The answer depends on content volume, team capability, character compatibility, integration effort, commercial terms and long-term maintenance. Compare the same lifecycle period and expose every assumption.
Does Snippets replace an animation team?
No. Snippets is a production and orchestration layer, not a universal replacement for writers, actors, animators or technical artists. Bespoke characters, hero animation and quality review may still require specialist work.
Can Snippets power a fully autonomous NPC?
Not by itself. Real-time conversation, branching logic, scenario state and other intelligence usually come from the surrounding product. Snippets can serve controlled or approved performances within that wider architecture.
Can a team start with Snippets and build later?
Potentially. Treat reversibility as a design requirement from the beginning. Review asset formats, integration boundaries, stable identifiers, retained source content and the cost of replacing each component before committing.
Written by Tomas Budrys
