Build it in-house when video automation is a core part of what your company makes and you have engineers who want to own every layer, and bring in Dataclay custom development when you would rather build only the parts that are truly yours on top of Templater, Que and Projector. Most teams land somewhere between those two poles, and the useful work is deciding, one of five pipeline layers at a time, where your line falls.
We sell software and services, so you can guess which way our bias leans. We will try to keep it honest by treating “build it ourselves” as a serious option, because for some companies it is the correct one. The question is never whether your engineers are capable. The question is which parts of the pipeline are worth their time.
What “building it in-house” actually means
It sounds like one decision, and it is really several. A video automation pipeline has distinct layers, and each layer can be built or bought on its own.
There is the template layer, which is where the design lives and how it is made to accept changing content. There is the data layer, which is where the content comes from, how it is stored, and who can change it. There is the render layer, which turns a template and a row of data into a file, and does it at volume without falling over. There is the delivery layer, which sends the files to where viewers are and records what happened. And there is the control layer, which is how a person or another system requests a video and sees its status.
An in-house build means your team writes and runs some or all of those. A hybrid means you use a product for some layers and write the rest. A full buy means you use products for everything and write only glue.
Our products map onto those layers directly. Templater covers the template and the render work inside After Effects. Que is a data layer with an API and a status dashboard. Projector is a render-and-delivery layer. Custom development, our professional services, is the work of fitting those to what is distinctive about you.
So the honest question is layer by layer. Which of these five does your company gain an advantage from by building itself? Build those. For the others, ask whether your engineers’ time is better spent elsewhere.
The case for building in-house
There are strong reasons to build, and we will list them without hedging.
Control over everything. When you write every layer, you decide every behavior. No vendor roadmap, no product update that changes something you depended on, no license server to think about. For a company whose product is video, that independence has real value.
Deep integration with your own systems. If your video pipeline has to sit inside a large internal platform, with your identity system, your asset store and your deployment practices, code you own will fit more naturally than a third-party tool that you adapt. A product has its own opinions. Your platform has yours.
A different technology choice. Not every pipeline needs After Effects. Some teams want to describe videos in code. There are tools built for that. Remotion, for example, lets you create videos with React, with code as the source of truth, and its page lists batch rendering on your own infrastructure. Nexrender is an open-source, MIT-licensed Node.js project that automates After Effects rendering from JSON job descriptions and can run as a queue with workers across several machines. Both are real, serious options. If your team lives in JavaScript and you would rather not depend on a commercial plugin, they are worth a look, and you can read each project’s own page for terms. See their pages for licensing.
Learning and retention. Building teaches your team how video automation really works. If that knowledge is strategic, owning the build keeps it in the building.
If most of those describe you, an in-house build is not a mistake. Do not let a vendor, us included, talk you out of it.
The case for buying the foundation and building on top
Now the other side, which is where we think a lot of teams end up.
You skip the long middle. The parts of a video pipeline that look simple are usually the parts that take months. Templater handles layout rules that position and scale dynamic layers relative to their container and siblings, Time Sculpting that trims and stretches layers to fit footage of differing lengths, and text in any language including right-to-left scripts. It supports previewing compositions with your data before a render, logging of its own activity, custom output names from a data source and switching templates by row. None of that is hard to describe. All of it is slow to get right, and your designers will find every edge case you did not think of.
Your designers keep their tool. Templater lives inside After Effects, so motion designers work where they already work. They rig a template and see how data changes it with a preview. A pipeline built in code often means designers hand off to engineers for every change. Whether that matters to you depends on how often your templates change and who makes the changes.
There is a product behind it. With a product comes ongoing compatibility work and support. Our FAQ says Templater’s price reflects continued feature development, maintenance to keep up with version compatibility and support. When After Effects updates, that is our problem. In an in-house build, it is yours.
You can build the layer that is yours. Templater exposes a command line interface, an Event Scripts API and support for JSON-based data sources. Que has an API and a Zapier connection. The point of those is that your engineers can build the differentiated parts, the intake, the business rules and the delivery logic, without rebuilding rendering.
That last point is the heart of the hybrid. You are not buying a finished product and accepting its limits. You are buying a foundation with extension points, and your team writes what is specific to you.
Where Dataclay custom development fits in the hybrid
Suppose you choose the hybrid. You still have a decision about who writes the custom parts, and we offer to be one option.
Event scripting for Templater is the most common form. Templater can be extended with shell scripts and ExtendScripts that hook into the events it broadcasts. Your own developers can write them, and our GitHub repositories, case studies and documentation give them a head start, with sample scripts for Windows, Mac and Node.js. If you lack the skill or the time, we offer scripting engagements. Examples we have done include authenticating with a third-party database before extracting data, transforming data into a different format, and sending an email or text message when a render completes.
Feature enhancements are another form. If something should exist in the product, customers can ask for it, and if it is vital to your business, a customer can pay an engagement fee for us to prioritize it. Features built that way become part of the application and may be offered to other customers. That is a trade-off you should weigh. You get it built and maintained inside the product, and you also accept that it may not stay exclusive to you.
Implementation and consulting engagements sit alongside those. Our description of consulting says the goal is to build your skills so you can fly solo. That suits a team that wants to bring the work in-house eventually, and would like a guide on the way.
All engagements are quoted individually, so we cannot put a number on any of this here.
A worked example: the same company, three ways
Consider a company that produces product videos for hundreds of listings that change often. Each listing has a name, photos, a few attributes and some text. The company wants a video generated whenever a listing is created or updated.
Full in-house. The engineering team builds an intake service that watches for changes, a template system in code, a render queue on its own machines, a delivery step to its video host and a dashboard. It is a meaningful project with continuing maintenance. In exchange, every part is theirs, and nothing depends on a vendor. For a company with a strong platform team and video at the center of its business, this is a defensible choice.
Product foundation, built on top. The designers rig a template in After Effects with Templater. Listings flow into a data source, which could be a JSON feed or Que. Templater Bot watches for new data and renders. Projector, or an event script, delivers the file and writes the link back. The engineering team writes the intake and the business rules, and a little glue. The video part is mostly configuration.
Product foundation, with our help on the scripts. Same as above, except the company does not have anyone to write the delivery and notification scripts, so it engages us for those, and engages for consulting so its own team can take them over later.
None of these is wrong. They trade control against effort and time. The second and third reach a working pipeline with far less engineering. The first gives the most control. Which you prefer depends on how strategic video is to the company and how much engineering capacity you have to spare. The numbers on both sides are yours, not ours.
Questions to settle before you commit
Is video part of your product or part of your marketing? When it is the product, owning more layers makes sense. When it is marketing, engineering time is usually better spent elsewhere.
Who will maintain this in two years? A pipeline built by one engineer who leaves is a liability. A product with support and a documented extension model is easier to hand to the next person.
How often do templates change, and who changes them? If designers change them weekly, a tool in their own application matters a lot.
What does your environment require? Our FAQ notes that Templater can run on Windows Server virtual machines in the cloud, such as AWS, and an After Effects server license comes from Adobe sales. Your own infrastructure constraints should be checked against that.
Can you try before you decide? Templater has a 30-day free trial with a fully featured Bot, and if you buy and it does not work for you, you can ask for a refund within 30 days. That means you can build a small proof on your own data before committing either way. You can also read our post on batch rendering in After Effects for the basics, or our piece on the case for on-premise video automation if infrastructure is your concern.
The costs that do not show up in the plan
Every build-or-buy comparison gets lopsided because one side’s costs are visible and the other’s are not. These are general-practice observations, and they apply to us as much as to you.
When you build, the invisible costs arrive after launch. Someone has to keep the render machines running, handle a font that went missing, deal with an After Effects update, and answer the question “why did this video come out wrong” at an inconvenient hour. The first version of a pipeline gets attention. The tenth month of it gets whoever is left. If you build, plan for that person by name before you start.
When you buy, the invisible costs are fit and dependence. A product has opinions about how work is done, and you will sometimes work around one. You also depend on the vendor’s decisions, including pricing and the roadmap. That is the honest downside of a foundation, and it is the reason to look at the extension points before you commit. If the thing you most need can only be done by changing the product, a feature engagement is possible, but it is a request to us and not a thing you control.
When you mix, the invisible cost is the seam. Where your code meets ours, someone has to own the contract between them, and that someone has to read release notes. It is manageable, and teams do it every day, but it is real work that should be assigned.
None of this points in a single direction. It points to a habit. Before you choose, write down who will own each layer a year from now, and what happens when that person is out sick or on vacation. If you cannot answer, the plan is not finished, whichever route it takes.
What to do in the first two weeks
If you are still undecided, this is the least risky way we know to spend two weeks.
Pick one real template and one real batch of your own data. Not a demo. Include the awkward rows, the long names, the missing values, the footage that runs the wrong length. Rig the template with Templater during the trial, using a spreadsheet or a JSON file as the data source, and render the batch. Note what took effort and what did not.
In parallel, ask your engineers to sketch what they would build for the same batch. Not a design document, just a list of the components and who would own each. Compare the lists honestly. Where the product covered a layer you would have had to build, count it. Where it got in your way, count that too.
At the end, you will have an actual comparison, with your data and your people, and you will know which layers you want to own. That is the only comparison that counts.
The bottom line
Build it in-house when video automation is central to your company and you want to own every layer. Buy the foundation and build on top when you want your engineers working on what makes you different, not on layout rules and render queues. Bring in our custom development for the scripts and features you lack time or experience to write, and ask for consulting if you want to take them over yourselves.
If you are not sure, run a small proof with the trial on a real batch. It will tell you more in a week than a month of planning.
A few questions come up again and again when engineering teams are weighing a build against buying.
Frequently Asked Questions
Can my engineers extend Templater themselves?
Yes. Templater is extendable with shell scripts and ExtendScripts, and it offers a command line interface and an Event Scripts API. Our GitHub repositories include sample scripts and documentation for Windows, Mac and Node.js. Many teams build their own integrations without any engagement from us. Dataclay offers scripting services for teams that lack the time or experience.
Is there an open-source alternative to building on Templater?
Yes. Nexrender is an open-source, MIT-licensed Node.js tool that automates After Effects rendering from JSON jobs. Remotion creates videos with React and treats code as the source of truth. Both have their own licensing and requirements, so read their pages. Which fits depends on whether your team wants After Effects templates or code-defined videos.
What can Dataclay custom development build for us?
Our professional services include scripting engagements, feature enhancements, implementation and consulting. Past scripting examples include authenticating with a third-party database before extracting data, transforming data into a different format, and sending an email or text when a render finishes. Each engagement is quoted individually, so describe your project and we will scope it.
Does Templater come with a front end for our users?
No. According to our FAQ, Templater does not currently come with a front-end, web or mobile application. Templater Bot was designed to be flexible, with documentation so developers can build whatever interface they need with Templater as the back end. If you lack the staff or skills, Dataclay can help.
Who maintains the product when After Effects updates?
We do, as the maker of Templater. Our FAQ describes the price as reflecting ongoing feature development, maintenance to keep up with version compatibility, and support.
How do I test whether building on Templater suits us?
Use the 30-day free trial, which is a fully featured Bot. Run a real batch of your own data and your own template, including awkward rows. If you purchase and it does not work for you, contact us within 30 days for a refund.
Will features you build for us stay private?
Per our description, features developed in a feature enhancement engagement become part of the application and may be made available to other customers. If you need something kept private, a script in your own environment is the better route. Raise it when you scope the work.
