Every studio eventually faces the same crossroads: you need a tool that doesn't exist, or the tool you have doesn't do what you need. At that point, someone in the room asks the fateful question: "Should we build it ourselves?"
I've been on both sides of this decision — shipping custom rigging frameworks from scratch, and also bending commercial DCC software until it does exactly what we need. Neither approach is universally correct. The right answer depends on a matrix of factors that most teams evaluate intuitively when they should be evaluating systematically.
The Decision Framework
After years of tool development across multiple studios, I've distilled the build-vs-buy decision into four questions. Answer them honestly, and the path forward usually becomes obvious.
A systematic decision tree for the build-vs-buy question. Most pipeline tools fall into the "Buy + Script" quadrant.
The Three Strategies
Strategy 1: Buy and Extend ("Tinkering")
This is the most common and usually the smartest approach. You license a commercial tool — Maya, Houdini, ShotGrid, Perforce — and then write scripts, plugins, and custom UIs on top of it to fill the gaps in your specific workflow.
The advantage is clear: you inherit decades of development and testing, and you only write the 10-20% that's unique to your studio. The risk is vendor lock-in: your custom scripts become dependent on the commercial tool's API, and when the vendor changes that API (and they will), your scripts break.
| Factor | Buy + Script | Build In-House | Open Source |
|---|---|---|---|
| Initial Cost | License fees + dev time | High dev time only | Dev time only |
| Time to Ship | Weeks | Months to years | Weeks to months |
| Maintenance Burden | Low (vendor handles core) | High (you own everything) | Medium (community helps) |
| Competitive Advantage | Low (everyone has access) | High (unique IP) | Medium |
| Vendor Risk | High (API changes, price hikes) | None | Low (you can fork) |
Strategy 2: Build From Scratch
This is justified in exactly one scenario: the tool IS your competitive advantage. If your proprietary rigging system lets you ship characters twice as fast as your competitors, that system is worth building and maintaining in-house. It's IP, not overhead.
But building from scratch comes with obligations most teams underestimate:
- Documentation. If it's not documented, it doesn't exist. And "the person who built it knows how it works" is not documentation.
- Testing infrastructure. You need automated tests, or your custom tool will silently break in ways that cost more than the time it saves.
- Release management. Rolling out new versions of internal tools to 50 artists mid-production is terrifying. You need staged rollouts, rollback capability, and a clear communication plan.
In-house tools need a proper release cycle — develop, test on staging, roll out gradually, collect feedback, repeat.
Strategy 3: Open Source as a Foundation
The game and VFX industries have increasingly embraced open-source foundations: OpenUSD for scene description, OpenColorIO for color management, Alembic for geometry caching. These aren't second-rate alternatives — they're industry standards backed by Pixar, ILM, and the Academy Software Foundation.
The open-source strategy gives you the best of both worlds: a battle-tested foundation you didn't have to build, with full freedom to customize. But it also means you're responsible for keeping up with upstream changes and contributing fixes back to the community.
The Scripting Layer: Where Value Lives
Regardless of which strategy you choose, the true value of a pipeline team lives in the scripting layer — the custom Python, MEL, and C++ code that wraps around commercial or open-source tools and makes them do exactly what your production needs.
This is where I spend most of my time. Writing the 200-line Python script that automates a task an artist was doing manually for two hours a day. Building the PySide2 widget that lets a supervisor validate 50 rigs in the time it used to take to check one. These "small" automation wins compound exponentially across a production.
The 10x Rule
Before building any tool, ask: "Will this save at least 10x the time it takes to build?" If an artist spends 30 minutes a day on a task, and your script takes 3 days to write, the break-even point is less than a month. After that, it's pure velocity gain — multiplied by every artist on the team.
A single well-placed automation script compounds its value every week — the ROI accelerates as more artists and projects benefit from it.
Error Reporting: The Unsexy Superpower
The most underrated aspect of tool development is error reporting. When a tool fails silently, artists develop workarounds. Those workarounds become habits. Those habits become "the way we do things here." And suddenly, your carefully designed pipeline is being bypassed by artists who simply can't afford to wait for a fix.
Every tool you ship — whether it's a shelf button or a full application — should have three error-handling properties:
- Fail loudly. If something goes wrong, the artist should know immediately. No silent failures that produce corrupt data.
- Fail clearly. The error message should tell the artist what went wrong in language they understand — not a Python traceback.
- Fail helpfully. If possible, suggest a fix or an alternative. "The rig version you referenced has been deprecated. Would you like to update to v008?"
Release Discipline
The final piece that separates amateur tool development from professional pipeline engineering is release discipline. You wouldn't ship a game build without QA. Don't ship an internal tool without testing it against real production data in a staging environment.
My release process:
- Dev branch: Develop and unit-test on an isolated branch. No live data.
- Staging: Deploy to a small test group of artists (ideally volunteers who understand they're testing). Collect feedback for 2-3 days.
- Canary release: Roll out to 10% of the team. Monitor for errors.
- Full release: If the canary period passes cleanly, deploy to everyone.
- Rollback plan: Always. Always. Always have a rollback plan.
A tool that breaks mid-production is worse than no tool at all — because artists already relied on it and now have to figure out the manual process they've forgotten.
Key Takeaways
- Most tools should be "Buy + Script" — license proven software and customize the last 20% through scripting.
- Build from scratch only when the tool is your IP — your competitive advantage that no commercial solution can replicate.
- Leverage open-source foundations — OpenUSD, OCIO, Alembic. Don't reinvent the wheel.
- Invest in error reporting — fail loudly, clearly, and helpfully. Silent failures are pipeline cancer.
- Follow a real release process — staging, canary, full rollout, with rollback always ready.
- Apply the 10x rule — only build tools that save at least 10x the development time, then watch the ROI compound.