Build or buy a creative simulator?

Sooner or later almost every sizeable out-of-home media owner asks the same question: we need a tool that shows customers their creative on our sites — do we build it or buy it?

It sounds like a budget decision. It is mostly a question about what such a tool has to do. And that is where it gets interesting.

What a creative simulator has to do

A creative simulator puts an advertising creative onto a real ad surface and shows how it works in its actual surroundings. That sounds like image compositing. The difference sits in four points:

1. Perspective. A billboard is rarely square to the camera. The creative has to be fitted into the surface, with the same tilt and distortion the surface has in the footage. Laid on flat, everyone can see it is a montage.
2. Motion. Digital sites run in a loop. A still frame says nothing about whether the message lands in the time available.
3. Inventory. A media owner does not have three sites, but hundreds. Each one needs footage, a mask and metadata. That is not a one-off job — it is an ongoing one.
4. Speed. The value appears in the conversation. Anyone who waits ten minutes for a preview will not use it in a client meeting.

Solve only point 1 and you have built a demo. Solve all four and you have a product.

The four things in-house builds routinely underestimate

Perspective is not a filter. The first prototype takes a photo, cuts out the surface and lays the creative over it with a CSS transform. For that one photo it looks fine. The moment the second site arrives, the manual work starts — and it never stops.

Video is its own path. Producing a still image is one thing. Holding a creative frame-accurate on a moving surface for several seconds and turning that into a downloadable file is another. This is where most in-house builds stop — or where they quietly turn into a rendering project.

The inventory is the real effort. The software is not what costs time; loading the sites is. Treat it as a one-off and a year later you have a tool with twenty sites and a queue.

Browser performance is a requirement, not a detail. This has to run on a client’s laptop in a meeting room, not on a workstation. That rules out several otherwise obvious technical routes.

What is actually in the calculation

An honest make-or-buy calculation contains more than development days:

Item	In-house	Bought in
Initial build	several person-months	none
Loading the inventory	needs its own process	part of onboarding
Video export	your own rendering problem	included
Maintenance, browser updates	permanent	with the vendor
Time to productive	months	weeks
Your own branding	a given	via white-label

The item most often missing is the last row of the maintenance column: a simulator is not a project that finishes. It runs in browsers that change every year, showing an inventory that changes every month.

Where white-label shifts the maths

The most common reason for building in-house is not technology but brand: you do not want to show your customers someone else’s logo. That is fair — the simulator appears in client meetings, in proposals and in site conversations.

Which is exactly why white-label is the norm for this kind of tool rather than the exception: your design, your domain, your inventory, separated per tenant. That removes the strongest argument for building it yourself, and what is left is a plain question about time and ongoing effort.

The short version

Build it yourself if the simulator is your product and you have a team to run it for years. Buy it if it is a sales tool — then what counts is how quickly it stands in your next client meeting, with your sites and your logo on it.