How to build a real-time personalization platform in a weekend

A post you don't see from vendors often: you should build this yourself. The core of a real-time behavioral decisioning layer is now a weekend project. The catch isn't in the build — it's in everything after.

The Founder of AXO

Notes on agentic personalization

Here's a post you don't see from personalization vendors very often: you should build this yourself.

Not as a rhetorical trap. As an actual plan. I spent fifteen years implementing the platforms in this category — Evergage, Salesforce Personalization, the CDP alphabet soup — and the honest truth of 2026 is that the core of a real-time behavioral decisioning layer is now a weekend project. Claude Code plus a credit card gets you to a working MVP by Sunday night. I know because that's roughly how AXO started.

So this post lays out how to do it properly. The catch isn't hidden and I'll get to it, but it isn't in the build. It's in everything after the build.

The weekend: a real MVP, not a toy

A personalization platform, stripped to its skeleton, is four things: a way to observe behavior, a way to turn behavior into a decision, a way to act on that decision on the page, and a place to store the rules. That's it. Everything else — the dashboards, the AI copy generation, the integrations — is elaboration.

Here's the weekend build, in the order I'd do it.

Saturday morning: the tag. Write a small JavaScript snippet that a site owner pastes into their head. It listens for behavior — pageviews, clicks, scroll depth, dwell time, what categories of pages someone is moving through. This is maybe 200 lines of code. Claude will write it in one shot.

Saturday afternoon: the scoring. Now the architectural decision that matters more than any other, and it's the core of the thesis, so pay attention here: score the session on the client, not the server.

The instinct — the one every legacy platform in this category was built on — is to stream events to a server, run a decisioning engine there, and send the answer back. That's a network round-trip standing between a visitor's behavior and your response to it. It's latency, it's infrastructure cost, and it's the reason this category historically required six-figure contracts: real-time server-side decisioning at scale was genuinely expensive to run.

But a session's behavioral signal is small. A handful of counters and recency weights. A modern browser can evaluate "this visitor is behaving like a price-sensitive researcher" in a fraction of a millisecond, locally, with zero round-trip. So define a few segments as simple scoring rules over the events you're already capturing — a deal-seeker leans on sale pages and price interactions, a researcher accumulates dwell on comparison content — and let the tag compute segment membership right there on the page. The server's job shrinks to syncing configuration down and telemetry up, in the background, off the hot path.

Sunday morning: the actuation. A decision that doesn't change anything on the page is analytics. Define zones — a CSS selector pointing at the hero, the product grid, the announcement bar — and variants — alternate content mapped to a zone plus a segment. When the tag scores a visitor into a segment and that segment has a variant for a zone on the current page, swap the content. This is DOM manipulation, the oldest trick on the web.

Sunday afternoon: the storage and the API. A serverless Postgres database (Neon is free to start), a few tables — sites, segments, zones, variants, events — and a thin API the tag calls to fetch its config. Deploy it on Vercel. You will pay approximately nothing until you have real traffic.

Sunday night: you have a tag that watches behavior, buckets visitors into segments in real time, and changes the page accordingly, with no CDP, no data warehouse, no identity graph as a prerequisite, and no server round-trip blocking the decision. That is, functionally, the product a category of vendors spent the 2010s selling for $200K a year.

Why this works now: the category collapse

That weekend build isn't possible because you're clever. It's possible because the economics under this category quietly fell apart.

The real-time behavioral martech stack was historically sold as five or six separate products — a CDP to unify data, an identity vendor to resolve people, a decisioning engine to pick experiences, a testing tool to measure them, an ESP integration layer to extend them into email — and each one existed as a separate line item for one underlying reason: real-time was hard and infrastructure was expensive. Streaming pipelines, low-latency serving, resolution graphs. You bought the category because you couldn't build the plumbing.

Every one of those constraints is gone. Serverless Postgres costs dollars. Edge functions and modern CDNs make the config-serving path effectively free. LLMs generate on-brand variant copy on demand, which used to be the content bottleneck that made personalization programs stall out. Embeddings give you semantic understanding of a product catalog without a taxonomy team. And most decisively: the client device is now the cheapest, fastest, most distributed compute you have access to, and it's sitting right where the decision needs to happen.

Compare that to the legacy architecture, which made identity resolution a synchronous prerequisite: event up, graph queried, decision back, page waiting. Identity-graph-first wasn't wrong because identity is useless — a resolved profile is some of the strongest signal you can have. It was wrong because it put the slowest, most expensive, most privacy-fraught component in the blocking position, gating decisions that could have been made instantly from how someone is behaving in the last ninety seconds. The fix isn't anonymity as dogma. It's ordering: behavior decides now, identity enriches as soon as it arrives.

That's the collapse. The category didn't get disrupted by a better vendor. It got collapsed by its own infrastructure premises expiring.

Months one through four: what "enterprise grade" actually costs

Now the part the weekend version doesn't show you. Between the Sunday-night demo and something you'd let touch a Fortune 50 homepage sits one to four months of work, and almost none of it is glamorous. Here's the punch list you're signing up for.

Flicker. The gap between the original content painting and your swap landing. Visitors see the default hero flash before the variant appears, and it looks broken. Solving it means hiding zones pre-decision and revealing them fast — and failing open, because a bug that leaves a client's hero permanently hidden is a fireable offense. Getting reveal correctness right across every hydration framework on the internet took us longer than the entire original MVP.

Selector fragility. Your zones are CSS selectors, and CSS selectors are promises the client's site never agreed to keep. Every redesign, theme update, and A/B test on their end silently breaks your bindings. Enterprise-grade means detecting breakage, healing selectors automatically where possible, and surfacing the rest for review — a diagnostic subsystem the weekend version doesn't hint at needing.

Measurement. If you can't prove lift, you built a toy. That means an always-on holdout group — a slice of traffic that never sees personalization — and honest statistics comparing against it. It also means resisting the temptation every vendor in this category succumbed to: grading your own homework with metrics designed to flatter. Build the holdout in from day one; retrofitting it is miserable.

Allocation. Once a zone has multiple variants, something has to decide how traffic splits, and "50/50 forever" wastes the traffic you should be learning from. A multi-armed bandit that shifts allocation toward winners is the right answer, and the math is genuinely subtle enough to get quietly wrong.

The performance budget. Your tag is a guest on someone else's site. It needs to stay tiny — ours is under 30KB — load without blocking, and degrade to nothing when anything fails. Every feature you add for the next four months fights this budget.

The boring essentials. Consent handling. No PII in the behavioral stream. Render-error detection that auto-disables a misbehaving variant before the client notices. QA across browsers, SPAs, and whatever framework the client's agency chose in 2021. End-to-end testing on sites you don't control.

None of this is beyond a small, motivated team. All of it is real. One to four months is the honest range, depending on how enterprise your first enterprise client is.

The part nobody prices in: you own it forever

Here's the part of this post I hope resonates, and I mean it as sincerely as the build instructions.

The moment your tag is live on someone else's site, you have signed up for a permanent, uncapped operational commitment. Their redesign next quarter breaks your selectors. Their platform's theme update changes the DOM. Their new consent vendor changes when your tag can fire. Their email platform ships an API change and your Klaviyo trigger silently stops firing, and you find out when their marketing team asks why the win-back flow went quiet. Their analytics team disputes your lift numbers and you're in a meeting defending your methodology. Every browser release, every framework migration, every integration on both ends of every pipe — yours to watch, yours to fix, forever, on infrastructure you don't control, for a page you don't own, at whatever hour it breaks.

That's not a reason not to build it. It's the actual cost of the product, and it's invisible from the weekend and only faintly visible from month four. The build is a project. The ownership is a job.

So: do it like this

If real-time behavioral personalization is core to what your company does — if you're a product team that will amortize that permanent ownership across your own roadmap — then genuinely, build it, and build it the way I've described: client-side decisioning, in-session behavior first with identity as async enrichment, holdout-based measurement, a tag light enough to be a good guest. That's the right architecture. The old category isn't coming back, and you shouldn't rebuild its assumptions out of habit.

And if you got to the end of the ownership section and felt tired instead of excited — that's the other honest answer. We already did the weekend, the four months, and the two years of edge cases after that. The architecture in this post isn't hypothetical; it's AXO, running live on enterprise sites today, holdout measurement and self-healing selectors included.

Either way: if you need real-time and you need cheap distributed tooling, now you know the right way to do it.

The author is the founder of AXO, and spent fifteen years implementing the personalization platforms this post politely describes as collapsed.