Skip to content
Write once, posted everywhere: a marketing system inside your own application

Write once, posted everywhere: a marketing system inside your own application

· Bert Altena

Five packages that each report on themselves and none of which knows your customers. What changes when the calendar, the channels, the video and the figures run on your own data.

Most companies that run their own marketing pay for about five packages. A planner for the posts, something for the ads, something for the analytics, a video editor and a survey tool. Each one does its job well. None of the five knows what the other four have done.

The stack of subscriptions nobody chose

That stack builds itself. A channel is added, so a tool is added. A video is needed once, so a subscription is added. Two years later there is a row of charges nobody deliberately said yes to.

The fragmentation costs more than the money does. Every package reports on itself: reach, clicks, opens, views. Five reports you have to lay side by side by hand, and at the end you still do not know which post brought in a customer.

Why those packages never see the whole picture

They sit outside your own system. They do not know your customers, your offering or your revenue. They see reach and clicks, so that is what their figures are about. What a campaign actually produced sits in your database, and the planner never gets in there.

The input side works the same way. Your photos, your copy and your product pages are already in your own system. Getting them into the planner means exporting, uploading, and rewriting the text per channel. Every single time.

What changes when marketing sits inside the application

Over the past few weeks I built a module like this inside an existing application: its own window next to the CMS, with its own sidebar and its own permissions. It holds an overview, goals, a budget, a calendar, the channels, the campaigns, measurement, audiences and a reels studio.

A package can offer those screens too. The difference is that they all run on the same data: the same customers, the same image library, the same revenue, the same pages.

One item, its own shape per channel

In the calendar an item is one post in one language. You pick the theme, the channels and the time. You can attach a page or an article from your own site. The link then points at that page in the right language, and the photos from that page are already waiting in the picker.

Every selected channel gets its own text box with its own character limit. An AI button writes a proposal in the language of the item, using the brand profile for tone and facts from your own system for content. Prices and quantities come out of the database and are never invented. Translations become their own items that stay tied to the original, each landing on the page for its own language.

That is where the time comes back: think it through once instead of rewriting the same text eight times for four channels in two languages.

Video belongs in it, not beside it

The reels studio fills templates with material from your own image library and renders them on your own server, in vertical, square and wide formats, with voice-over and subtitles. An approved reel arrives as a draft in the same calendar, and you choose per item which format goes where.

That saves the detour through a separate video tool, and more importantly, the video sits in the same row as the rest of the planning.

Approval stays human work

An item passes through five states: draft, awaiting approval, scheduled, posted, failed. Whoever creates drafts gets as far as awaiting approval. Whoever may publish approves and schedules. A cron job posts at the agreed time. Failed shows up in red with the reason attached and can go back to draft.

That is not a detail, it is the house rule of the whole module. AI writes, people publish.

The figures come back to the same place

Every night the module pulls the figures from the channels. Each channel has a dashboard with key numbers, a daily line, the best times based on your own posts, the top posts and the audience. A number a platform does not supply shows as not applicable and never as zero, so you never read a figure that does not exist.

For the ads, the system counts conversions from its own database, through the origin recorded on the order. Not the conversions the platforms report themselves, because Meta and Google both claim the same customer.

What was deliberately left out

No ad manager of its own. The big platforms build campaigns better and their screens change too often to rebuild. What is in there is the layer around it: pausing, adjusting the daily budget, and boosting an existing post, with that boost always created in a paused state.

The keys are not in there either. Tokens and API keys live outside the web root; the screen only shows whether a key is present, never its value.

Who this is interesting for

Companies that already have an application holding their customer data, their offering and their image material. This is the layer the separate packages cannot deliver, simply because they do not hold that data.

Without that foundation, separate tools are cheaper and faster for now. That is a more honest answer than a story about building everything yourself.

Honest about where it stands

The module is a few weeks old. It runs, it posts and the figures come in. What it delivers over a year I will know in six months, not today. Return figures would have to be invented right now, and that helps nobody.

What does exist is in the portfolio of modules I have built. If you are considering something like this for your own software, I am happy to talk it through via the contact page.

Frequently Asked Questions

What is a marketing system inside your own application?
A marketing module that sits inside your own software instead of beside it. The calendar, the channels, the budget, the video and the figures all run on the same data as your customers and your offering. That is what lets a report cover revenue instead of only reach and clicks.
Does a system like this post automatically?
The posting is automatic, the approval is not. An item moves from draft to awaiting approval, scheduled, posted or failed. Only someone with the publish right can approve and schedule it; a cron job then posts it at the agreed time.
Why build this instead of buying tools?
Only if you already have an application holding your customer data, your offering and your image library. Then it is the layer the separate packages cannot deliver. Without that foundation, separate tools are cheaper and faster for now.
Chat met ons