Your campaign is ready, but the release isn't

A change that marketing can write in an hour often takes an engineering release to reach users. If that sounds like your team, the delay is rarely about effort. It's about where the change lives. This post is an opinion on how to cut that wait, and on when you shouldn't bother.

A made-up Tuesday

Here's an example, invented for this post. Picture this: a lifecycle marketer finishes a weekend-sale banner on Tuesday. The copy is approved, the discount is agreed, the end date is Sunday. She files a ticket.

The ticket is fair. A developer has to add the banner, someone has to review it, and it goes out with the next release. That release was already planned, and it doesn't happen to go out before the weekend. The sale runs without a banner, or the banner arrives after the sale.

Nobody in that story did anything wrong. Each step was reasonable. The result still isn't.

Steps in order, with who does each: Marketing or Engineering.

1. Marketing: Idea and copy
2. Marketing: Ticket written
3. Engineering: Waits in the backlog
4. Engineering: Built and reviewed
5. Engineering: Ships with a release
6. Marketing: Moment may have passed

What the wait costs

We can't give you a number, and we'd distrust anyone who does without knowing your team. What we can do is describe what it tends to look like.

The moment expires. Sales, launches, trial-ending reminders and seasonal offers have dates. A change that arrives after its date is just clutter.

Small ideas don't get tried. If every test of a headline costs a ticket and a place in a release, people stop proposing headlines. The ideas that die this way never show up on any report, which is why this cost is easy to miss.

Developers get pulled in for words. Changing a price label or a sentence isn't hard, and that's the problem. It interrupts work that needs the developer's attention, and it's work they didn't choose.

Learning slows down. One test a quarter teaches you less than a test a week. If you want to see why little traffic makes that worse, we wrote about it in A/B testing with little traffic.

I haven't measured any of this on your team, and the size varies a lot. Treat it as a checklist of where to look.

Three ways to shorten the wait

The reason a change is slow is that it's baked into the build. Each approach below moves some of it out. We covered the wider list in ways to change a live app without shipping a release, so this is the short, growth-flavored version.

1. A self-serve content layer. Words and images live in a CMS or a content service, and the app fetches them. The marketer edits text, previews it, and publishes. It works well when the content already has a place in the screen: a headline, a list of benefits, a banner slot the developers built once. It can't change the arrangement of the screen.

2. Remote config. A developer decides which values the app reads (a discount label, a flag that turns a banner on) and someone non-technical edits the values. It's the lightest option. Its limit is that it only moves what the code already reads, so a banner that doesn't exist in the build can't be added this way. The difference between flags, config and a CMS is in feature flags vs remote config vs CMS.

3. A remote UI tool. The server sends a description of the screen and the app draws it, so a non-developer can change layout and order, not just words. The price is a renderer inside the app, a schema, and a tool that has to be good enough that people trust it. What server-driven UI is goes through the levels.

We'd start with whichever one is lightest and still covers the change your team keeps asking for. If the repeat requests are all copy, that's the first. If they're all a number, the second. If they're "rearrange the offer screen", only the third gets there.

Pick by who edits, who approves, who undoes

The tool matters less than three questions. Ask them of anything you evaluate, including something you build yourself.

The third row decides how much freedom you can give the first. People will edit boldly if a mistake can be reversed quickly, and they'll hold back if it can't. A fast way to publish with no fast way back doesn't remove the bottleneck. It moves it, and adds risk.

Approval is the one that varies most between teams. Some want legal to read every offer; some trust the marketer. Neither is wrong, but write it down, and check that your tool matches the rule you actually have.

When the current process is fine

Leave it alone if changes are rare. A team that touches its upgrade screen twice a year doesn't need a system for it, and a new tool is one more thing to maintain.

Leave it alone if the wait is in approval, not in the release. When legal review takes longer than the build, a faster path to production changes nothing.

And leave it alone if the change is real logic: a new flow with new behavior, a feature that needs a native capability. That needs a release, and the useful work is making releases small and boring.

If your team already ships every few days and nothing on the list above is happening to you, you probably don't have this problem.

Sources

1. 1.
   Miniwall docs, How it works (publish to visitor, caching) (opens in a new tab)docs.miniwall.app · accessed Oct 26, 2026
2. 2.
   Miniwall docs, Publish and versions (roles, roll back) (opens in a new tab)docs.miniwall.app · accessed Oct 26, 2026
3. 3.
   Miniwall docs, Quickstart (what a developer sets up) (opens in a new tab)docs.miniwall.app · accessed Oct 26, 2026

Go further

• Guide: Quickstart (opens in a new tab)
• Guide: Publish and versions (opens in a new tab)