> ## Documentation Index
> Fetch the complete documentation index at: https://notifizz.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Marketing Team Autonomy on Notifications
> Notifications are the only customer-facing channel where Marketing depends on Dev for every change. Notifizz makes Marketing autonomous for real — by composing event primitives, AI codegen, enrichers, and one shared platform.
# Marketing autonomy, for real
Notifications are the only customer-facing channel where Marketing depends on Dev for every change. The website? Marketing edits in a CMS. The pricing page? A copy doc. The product tour? A no-code tour builder. Notifications? Open a ticket, wait four weeks, hope nothing's broken when it ships. Every other tool gives Marketing a brush; for notifications, they wait for an engineer.
The market's response has been to hide the dev half — no-code platforms that pretend the engineering doesn't exist, until it does, and then Marketing is stuck. That's not autonomy; that's a brittle illusion. Notifizz takes a different position.
## What we believe
Marketing autonomy on notifications isn't a feature. It's the **emergent property of four ingredients composed correctly**: event-driven primitives that match how product engineers already think; AI that turns intent into code, reading those primitives; enrichers that pull live data without warehouse-sync; and one platform where Marketing, Dev, and Product see each other's work. Take any one out and the autonomy collapses — that's why the rest of this section makes the case for each ingredient separately.
## The status quo
Two camps dominate the notification platform market, and both fail Marketing autonomy in different ways.
### Camp 1: dev-first platforms (Knock, Novu, Courier)
Engineering loves these. Clean APIs, good types, well-documented webhooks. Marketing… opens a ticket. Every campaign is a code change; every copy tweak is a deploy. The platform's elegance reaches Marketing as a four-week ticket round-trip — and the marketing-led changes that *do* land are the ones engineering finds acceptable, not the ones Marketing actually wanted.
### Camp 2: no-code marketing platforms (Customer.io, Braze, Iterable)
Marketing loves these. Visual canvases, drag-and-drop journeys, segments, A/B testing. Engineering… pipes data into them. Every customer attribute that matters lives in the platform's database, copied via a sync. New attribute? New ETL job. Real-time data? Wait for the next sync. And when Marketing's intent exceeds what the canvas allows ("only send if their support ticket from yesterday is still open"), Engineering writes a custom integration, ships it through the platform's plugin system, and Marketing waits — same ticket round-trip, dressed up.
Both camps' "autonomy" is conditional. Camp 1 hides the dependency; Camp 2 hides the data plumbing. The dependency and the plumbing are still there.
## The Notifizz alternative
We compose four ingredients. Each is a deliberate choice.
### 1. Event-driven primitives
Notifications are reactions to product events. Period. `client.track(eventName, properties)` from your code; campaigns react server-side. Marketing edits the campaign's reaction (orchestrator, copy, channel) without touching code. Dev edits the events (what fires, what properties carry) without touching campaigns. The split is clean because the **primitive** is event, not segment. See [why event-driven](/docs/why/event-driven).
### 2. AI codegen on real primitives
When Marketing describes a new campaign, the AI reads the existing event catalog + enricher catalog and generates the orchestrator. Not from nothing — from your actual primitives. The AI knows what `user.signed_up` carries because the catalog says so. It knows `fetchUser` exists because you registered it. The result is real code, on real primitives, that Dev can review in a diff. Marketing didn't write code; Marketing *got* code. See [why AI](/docs/why/ai).
### 3. Enrichers — no warehouse sync
Customer data stays where it lives. The orchestrator calls `enrichWith("fetchUser", { userId })` at notification time; your enricher returns live data from your DB or wherever the truth lives. No ETL pipeline, no overnight drift, no separate copy of the customer in a marketing tool's database. See [why enrichers](/docs/why/enrichers).
### 4. The whole team on one platform
Marketing sees the campaigns. Dev sees the orchestrator code, the events, the enrichers. Product sees the funnel. Same platform, same activity log, same review surface. The AI can do its job because it has full visibility — Marketing's intent and Dev's primitives in one graph. See [why whole team](/docs/why/whole-team).
## The workflow, side by side
> "Marketing wants to send a notification when a user upgrades to Pro, congratulating them and surfacing the three features they unlocked."
### Customer.io / Braze workflow
1. Marketing opens a Linear ticket: "Send congrats notif on Pro upgrade."
2. Eng investigates: the `plan` field isn't in the marketing platform yet — needs a sync extension.
3. Eng writes the sync extension; QA runs through staging.
4. Marketing builds the journey in the canvas.
5. QA discovers the canvas can't list "the three unlocked features" because that's per-user, computed live.
6. Eng adds a webhook trigger; ships another integration.
7. Marketing rebuilds the journey to consume the webhook.
8. **4 weeks elapsed.** Notification ships.
### Notifizz workflow
1. Marketing opens the campaign editor: "Congrats on Pro upgrade, list unlocked features."
2. AI reads `subscription.upgraded` event catalog (already exists). Generates orchestrator that reads `event.properties.tier`. Suggests `enrichWith("fetchUnlockedFeatures", { tier })` — surfaces a dev task because that enricher isn't registered.
3. Marketing tags Dev on the dev task. Dev registers `fetchUnlockedFeatures` in the Node SDK (10 lines, points at existing internal API). Pushes.
4. Dashboard auto-resolves the dev task. AI proposes the final orchestrator; Dev reviews the diff (15 lines), approves.
5. Marketing previews, edits copy, promotes to `Dev`. Tests in dev.
6. Promotes to `Live`.
7. **Same day.** Notification ships.
The work is the same — events, enrichers, copy, QA. The difference is **where the time goes**. In the first workflow, the time is in handoffs (ticket queues, context-switches, double-explanations). In the second, the time is in the work itself.
## Why the four ingredients can't be unbundled
A no-code marketing tool with a sync. Sounds familiar — that's Customer.io. Without event primitives, Marketing's intent flattens into segments. Without AI codegen on those primitives, Marketing has to learn the platform's DSL. Without enrichers, Dev maintains the sync forever.
Add AI to a no-code tool? It still doesn't see the primitives — it's guessing. Add enrichers to a dev-first platform? Marketing still can't author. Each ingredient compounds the others; remove any and the system reverts to one of the two camps that fail.
That's why this section makes the case ingredient by ingredient — they're orthogonal in the literature but not in practice.
## But what about…
No. The no-code tool gives Marketing autonomy on the *visual* side — what the email looks like, what the journey diagram shows. The data + delivery side stays a black box that Engineering maintains via a sync. When Marketing wants something the canvas doesn't allow, the gap reopens. Notifizz's autonomy is data + delivery + visual all together, because the AI sees the data and the dev side sees the visual.
There's still a dev gate — for orchestrator changes that touch new primitives. But it's a *diff review*, not a *ticket queue*. The AI generates code; Dev reviews the diff; if there's nothing new (the events and enrichers exist), the gate is one-click. The gate moves from "every campaign needs Dev" to "campaigns that introduce new primitives need Dev". Most marketing campaigns don't introduce new primitives.
Yes. Even in dev-led cultures, marketing teams spend weeks waiting for engineering on notification work. Notifizz doesn't force Marketing autonomy — it makes it possible. If your culture wants Dev to author every campaign, do that — the tool supports it. The benefit is asymmetric: when Dev is busy on real engineering and Marketing wants to ship a copy tweak, the loop completes without a ticket.
Small teams suffer most from the four-week ticket loop because they don't have the ticket *queue* to absorb it — every Marketing-blocking-on-Dev moment is a real outage of marketing velocity. A 5-person startup has the same notifications-need-events problem as a 500-person company; Notifizz's value compresses with team size, it doesn't dilute.
Most "AI in marketing tools" generates copy variants (subject line A/B, body rewrites). That's useful but local. Notifizz's AI generates the *orchestrator* — the code that decides who receives the message and how data flows in. Subject-line AI doesn't replace engineering; orchestrator AI does. See [why AI](/docs/why/ai) for the distinction.
Migration is per campaign, not big-bang. Each existing journey maps to one Notifizz campaign on one event. There's no automated migration tool — you port the orchestration logic by hand. The good news: a typical journey ports in an afternoon once you've picked the equivalent event and registered the enricher that replaces the warehouse-sync data source. Most teams migrate high-value campaigns first, leave low-traffic ones on the old platform, and decommission when traffic drops below the floor.
## Where to go next
The first ingredient. Notifications are reactions to events.
The second ingredient. Live data without warehouse-sync.
The third ingredient. AI codegen on real primitives.
The fourth ingredient. Marketing, Dev, and Product on one platform.
See the four ingredients in action — five minutes.
Talk to the team about your migration.