A new archive solution, a tool for the newsroom, an interface between MAM and playout: sooner or later, every media company faces the same question. Build it yourself, buy a standard product - or outsource operations altogether? This decision has always mattered. With agentic coding, however, it has fundamentally shifted.
In this post, we explain why, walk through the three paths with their strengths and weaknesses, and give you a decision tree and five key questions to find the right path for your project.
The Starting Point: Building Has Become Cheaper. Running It Hasn't.
With agentic coding - AI agents that independently write, test and revise code - a working prototype now takes days instead of months. What used to require a dedicated project team and half a year is on screen after just a few sprints. That noticeably changes the economics of building in-house.
What has hardly changed, though, is everything that comes after the first go-live:
- Security: dependencies need patching, vulnerabilities need closing, access needs to be properly managed.
- Updates: operating systems, frameworks and connected systems keep evolving - the solution has to keep up.
- Scaling: more users, more material, new formats - load rarely grows linearly.
- Support: someone has to be available when things get stuck in day-to-day operations.
And not for a few weeks, but for years. So the real question is no longer “Can we build it?”, but: who runs it?
The Three Paths: Each Has Its Strength - and Its Price
Broadly speaking, there are three paths to a new solution. None of them is better per se - they simply distribute control, effort and responsibility differently.
Build - develop it yourself
You develop the solution yourself or have it custom-built, and then run it in-house.
- Plus: maximum control and a solution that reflects exactly your workflow.
- Minus: know-how and maintenance stay with you permanently - even when the project team has long moved on to something else.
Buy - purchase a standard product
You rely on a product available on the market and run it in your own infrastructure.
- Plus: productive quickly, with proven features already in use elsewhere.
- Minus: customization has limits - and operations still remain with you.
Managed - outsource operations
A partner takes care of hosting, updates and support - whether for a standard product or a custom-built solution.
- Plus: updates, hosting and support from a single source - your team can focus on content.
- Minus: less direct control over the technology.
Important: “managed” is not the opposite of “build”. Agentic coding in particular makes the combination attractive - custom-built, but run externally.
The Decision Tree: Which Path Is Right for You?
To structure the choice, we've put together a simple decision tree. It needs just three questions and leads to four typical scenarios.
1. Is the solution a differentiator with a very specific workflow?
This is about strategic importance. Does the solution give you a real edge - for instance because it reflects a production process that only exists in your organization? Or is it a task that many companies solve in a similar way?
2a. If yes: do you have a team to run and evolve it for years?
- Yes → Build: in-house development. You have the know-how and capacity to carry the solution yourself in the long run.
- No → Managed: custom-built, run externally. You get your specific workflow without having to build up your own operations team.
2b. If no: do you want to handle operations, updates and hosting yourself?
- Yes → Buy: standard product, run in-house. Makes sense if you already have a capable IT department and want to keep control of the infrastructure.
- No → Managed: product as a service. The fastest and usually most predictable option when the solution isn't a differentiator.
And on every path: check where data and AI models live - and whether European law applies. With media content, archive material and personal metadata in particular, this isn't a detail but a basic requirement.
Five Questions Up Front
The decision tree sets the direction. Before you commit, though, it pays to take an honest look at five points that, in practice, make the difference between success and frustration.
- Team: Do we have the people and the know-how - three years from now, too? A prototype is quickly built. What matters is who knows the solution once the original developers are no longer available.
- Workflow: How special is our process really - or just familiar? Not every deviation from the standard is a competitive advantage. Sometimes adapting the process is cheaper than adapting the software.
- Maintenance: Who patches, updates and helps at 3 a.m.? In broadcast operations especially, on-call duty and response times are anything but theoretical.
- Data sovereignty: Where may content, metadata and models reside? This applies not only to the data itself, but increasingly to the AI models working with it.
- Total cost: What does it cost over five years - not just until go-live? Licenses, hosting, staff, updates and further development belong in every honest calculation.
Our Take: None of the Three Paths Is Always Right
The best solution depends on your project, your team and your data sovereignty requirements. That's why we support media companies on all three paths - from the idea to operations:
- Build: architecture sparring and guidance on agentic coding - so the quick prototype becomes a solution that can also be run in the long term. Learn more under Software Development.
- Buy: integration into your existing system landscape - so the standard product works seamlessly with MAM, archive and playout.
- Managed: operations and hosting in Europe - with predictable pricing. Learn more under Hosting and Operation and in our post on the MMI Cloud.
Facing a decision like this right now, or want to run the decision tree against a concrete project? Get in touch - we're happy to take the time.