<![CDATA[The future of advertisement - Advertisement Automation Workflows]]> https://veedee.xyz/forum/ Tue, 03 Nov 2026 17:15:15 +0000 MyBB <![CDATA[[Tool] Campaign production cost calculator]]> https://veedee.xyz/forum/thread-8.html Mon, 26 Oct 2026 22:31:51 +0000 VeeDeeAdmin]]> https://veedee.xyz/forum/thread-8.html campaign cost calculator a new tool that we've made to use as a production asset and helper for marketing teams. It is a free to use automation and campaign calculator that can be used to calculate number of assets produced, yearly costs for running campaigns and also for creating campaign naming schemes. 

Use it for your own projects, share the campaign numbers and download PDF reports right from the page. You can use it to compare your costs to the VeeDee pricing model too.

VeeDee.xyz/calculator

Give it a go]]> campaign cost calculator a new tool that we've made to use as a production asset and helper for marketing teams. It is a free to use automation and campaign calculator that can be used to calculate number of assets produced, yearly costs for running campaigns and also for creating campaign naming schemes. 

Use it for your own projects, share the campaign numbers and download PDF reports right from the page. You can use it to compare your costs to the VeeDee pricing model too.

VeeDee.xyz/calculator

Give it a go]]> <![CDATA[The whole package!]]> https://veedee.xyz/forum/thread-6.html Wed, 21 Oct 2026 09:23:40 +0000 Darko]]> https://veedee.xyz/forum/thread-6.html
That is why I think having people who understand the whole production process matters so much. You need people who can look at a problem from different angles and understand how one decision affects everything else. A beautiful design is not particularly useful if it cannot be produced efficiently. A technically perfect system is not much use if the creative team cannot work with it. And a clever automation is pointless if the final campaign no longer feels like the brand it was created for. It all leads to the cohesion of the system, so that total efficiency is achieved, which might include less mistakes that the QA team has to go through, faster render times for the render farm, quicker previews for the advertising teams and correctly presenting the final product so that the audience connects with it and gets actual value from it. 

We don't and can't just build the machine and walk away. We help think through the campaign, prepare the scenarios, create the systems, test the outputs, solve the strange little problems that inevitably appear along the way, and make sure that the final result still feels like it came from the brand in the first place. Sometimes that means writing code. Sometimes it means fixing a template. Sometimes it means going through data. And sometimes it means sitting down with someone and asking a few more questions before building anything at all.

There is something particularly satisfying about watching a team go from worrying about how they are going to produce everything to calmly discussing what they want to produce next. At the beginning, there is usually a lot of uncertainty: Can we do this? How long will it take? What happens if the number of versions doubles? What happens if the client changes something? But once the system starts working and people begin to trust it, the conversation changes. Suddenly, instead of worrying about production, everyone can start thinking about the work itself.

That is probably my favourite part of this job. The automation is impressive, of course, and there is something very satisfying about seeing a complicated process become simple and repeatable. But seeing people relax because they finally have a system they can trust is even better. When a team stops worrying about whether something can be produced and starts thinking about what they could create with that freedom, you know the system is doing what it is supposed to do.

So, a (not so) small appreciation post for the people who make the complicated things look simple. The people who jump between creative, technical and operational problems without making a big deal out of it. The people who keep asking questions, finding solutions, testing things, fixing things and somehow making the whole process feel a little easier than it did yesterday.

You know who you are.]]>
That is why I think having people who understand the whole production process matters so much. You need people who can look at a problem from different angles and understand how one decision affects everything else. A beautiful design is not particularly useful if it cannot be produced efficiently. A technically perfect system is not much use if the creative team cannot work with it. And a clever automation is pointless if the final campaign no longer feels like the brand it was created for. It all leads to the cohesion of the system, so that total efficiency is achieved, which might include less mistakes that the QA team has to go through, faster render times for the render farm, quicker previews for the advertising teams and correctly presenting the final product so that the audience connects with it and gets actual value from it. 

We don't and can't just build the machine and walk away. We help think through the campaign, prepare the scenarios, create the systems, test the outputs, solve the strange little problems that inevitably appear along the way, and make sure that the final result still feels like it came from the brand in the first place. Sometimes that means writing code. Sometimes it means fixing a template. Sometimes it means going through data. And sometimes it means sitting down with someone and asking a few more questions before building anything at all.

There is something particularly satisfying about watching a team go from worrying about how they are going to produce everything to calmly discussing what they want to produce next. At the beginning, there is usually a lot of uncertainty: Can we do this? How long will it take? What happens if the number of versions doubles? What happens if the client changes something? But once the system starts working and people begin to trust it, the conversation changes. Suddenly, instead of worrying about production, everyone can start thinking about the work itself.

That is probably my favourite part of this job. The automation is impressive, of course, and there is something very satisfying about seeing a complicated process become simple and repeatable. But seeing people relax because they finally have a system they can trust is even better. When a team stops worrying about whether something can be produced and starts thinking about what they could create with that freedom, you know the system is doing what it is supposed to do.

So, a (not so) small appreciation post for the people who make the complicated things look simple. The people who jump between creative, technical and operational problems without making a big deal out of it. The people who keep asking questions, finding solutions, testing things, fixing things and somehow making the whole process feel a little easier than it did yesterday.

You know who you are.]]> <![CDATA[Teaching the machine - Understanding the process ourselves]]> https://veedee.xyz/forum/thread-5.html Wed, 21 Oct 2026 09:07:40 +0000 Darko]]> https://veedee.xyz/forum/thread-5.html
Before a system can automate something properly, somebody needs to teach it what "properly" means. That also means we and the clients also need to understand what that means.

What happens when the text is too long? What happens when there are three different prices? Which logo belongs to which market? What happens when a translation is longer than the original? Which parts of the design are allowed to change and which parts should never move? What happens when the client wants a completely different format?

These are not just programming questions. They are production, design and flow questions.

Our job at VeeDee is to understand those questions and turn them into a system that both humans and machines can understand. Sometimes that means programming, sometimes After Effects, sometimes data management, sometimes 2D or 3D work, and sometimes it is simply sitting down with a client and figuring out what they actually want to achieve as an end result.

We even spend time teaching teams how to prepare their own information in a way that makes sense, using simple CSV (excel or sheets) structures that people can understand and that our systems can process.

Because good automation isn't about making humans fit the machine. It's about building the machine around the way the humans need to work. And once that part is done, something quite nice happens.

People stop fighting the system.

They can finally get on with their actual (fun) job.

Thanks for reading
.jpg
0584.jpg
Size: 390.05 KB / Downloads: 1
]]>
Before a system can automate something properly, somebody needs to teach it what "properly" means. That also means we and the clients also need to understand what that means.

What happens when the text is too long? What happens when there are three different prices? Which logo belongs to which market? What happens when a translation is longer than the original? Which parts of the design are allowed to change and which parts should never move? What happens when the client wants a completely different format?

These are not just programming questions. They are production, design and flow questions.

Our job at VeeDee is to understand those questions and turn them into a system that both humans and machines can understand. Sometimes that means programming, sometimes After Effects, sometimes data management, sometimes 2D or 3D work, and sometimes it is simply sitting down with a client and figuring out what they actually want to achieve as an end result.

We even spend time teaching teams how to prepare their own information in a way that makes sense, using simple CSV (excel or sheets) structures that people can understand and that our systems can process.

Because good automation isn't about making humans fit the machine. It's about building the machine around the way the humans need to work. And once that part is done, something quite nice happens.

People stop fighting the system.

They can finally get on with their actual (fun) job.

Thanks for reading
.jpg
0584.jpg
Size: 390.05 KB / Downloads: 1
]]> <![CDATA[Why do the work twice?!]]> https://veedee.xyz/forum/thread-4.html Wed, 07 Oct 2026 21:14:36 +0000 Darko]]> https://veedee.xyz/forum/thread-4.html
This happens more often than people might think. Teams are so used to proving that something works manually that they sometimes create an enormous amount of manual work before they allow themselves to automate it. They build the first version, then the second, then the twentieth, and only when everyone is completely exhausted do they start thinking about how the process could have been designed differently from the beginning.

I don't think the answer is to automate everything immediately. Sometimes you absolutely need to understand the manual process first. You need to know what the designer does, where the problems appear, what information changes and which decisions require a human. But once those rules become clear, continuing to perform the same actions manually just because that is how it has always been done doesn't make much sense.

This is one of the lessons we have taken from our own projects. Automation works best when you design for it from the beginning, rather than taking a very large pile of manual work and asking the computer to somehow clean it up afterwards.

The best automation is not a faster version of a bad process.

It is a better process altogether.]]>
This happens more often than people might think. Teams are so used to proving that something works manually that they sometimes create an enormous amount of manual work before they allow themselves to automate it. They build the first version, then the second, then the twentieth, and only when everyone is completely exhausted do they start thinking about how the process could have been designed differently from the beginning.

I don't think the answer is to automate everything immediately. Sometimes you absolutely need to understand the manual process first. You need to know what the designer does, where the problems appear, what information changes and which decisions require a human. But once those rules become clear, continuing to perform the same actions manually just because that is how it has always been done doesn't make much sense.

This is one of the lessons we have taken from our own projects. Automation works best when you design for it from the beginning, rather than taking a very large pile of manual work and asking the computer to somehow clean it up afterwards.

The best automation is not a faster version of a bad process.

It is a better process altogether.]]>