WHY I'M BUILDING NEXUM

The short version: I think the distribution stack is quietly collapsing, and the companies that survive it will be the ones with durable, membership-style relationships with their customers. Nexum is a bet that the infrastructure to build those relationships is still missing.

The setup

For the last twenty years, the default growth playbook for consumer businesses was paid acquisition through a handful of channels — search, social, affiliate, email. The channels extracted rent, but the game was predictable: pay for clicks, measure conversion, optimize the funnel.

That game is in the process of breaking.

Agents are going to be the new interface between users and products. When someone needs a flight, a meal, a piece of software, a pair of shoes, they’re going to ask an agent, and the agent is going to decide which product shows up. Paid search results mean less to an agent than they do to a human. SEO means less. Affiliate means less. The entire funnel — the thing most consumer businesses are built around — gets compressed.

What doesn’t get compressed is the relationships you already have. The customers who are already members. The ones who opted in. The ones whose history lives in your system.

Why membership isn’t loyalty

“Membership” and “loyalty” get used interchangeably, but they’re not the same thing.

Loyalty is points for purchases. It’s transactional, and mostly bolted-on. Existing SaaS options — Loyalty Lion, Smile.io — do this well, for a specific definition of well: Shopify-only, points-only, no composite rules.

Membership is different. It’s tiers, it’s qualification by behavior, not just spend. It’s “attend 50 classes in 90 days,” “refer 3 people and maintain a subscription,” “spend X and engage Y.” It’s programmable benefits — digital delivery, inventory holds, third-party coupons, pricing overrides. It’s progress tracking so the member knows how close they are to the next tier.

Every business that tries to build this ends up writing the same six things from scratch:

1. An event ingestion pipeline that can handle spikes without losing events.
2. A tier-qualification engine that can express composite rules over rolling windows.
3. A benefit-fulfillment layer that integrates with payment and inventory.
4. A webhook dispatcher with retries, idempotency, and signature verification.
5. Progress tracking so members see how close they are to the next tier.
6. An admin surface so the business team can edit rules without an engineer.

This is six to twelve months of engineering work. And then every rule change requires an engineer.

The bet

My bet is that this is a platform problem, not a product problem.

Just like Stripe abstracted payments by saying “you don’t need to know about card networks, you need an API,” Nexum abstracts membership: you don’t need to know about event pipelines, tier engines, and webhook retry queues. You need an API that says here is a program, here are its tiers, here are the qualification rules, here’s an event — evaluate it.

Three architectural decisions are load-bearing:

• The tier engine is a pure function. No DB, no HTTP, no side effects. It takes events and rules, returns evaluations. This is the intellectual core, and it’s separable from the API server.
• Events are synchronous; evaluation is async. Writes are fast (queue the event, return 200). Workers pick up the evaluation, run the engine, dispatch webhooks. This is the only way the system can scale to the real event volume of a real membership program.
• The shared types package is the source of truth. The API server, the engine, the Node SDK, and the dashboard all import the same types and the same Zod schemas. Drift between them is impossible.

Why now

Three forces, same idea from three angles:

1. Channel displacement. When agents compress the funnel, the durable asset is the membership base, not the acquisition spend.
2. Stripe-like DX is now the floor, not the ceiling. Developers expect typed SDKs, webhooks, idempotency keys, and an OpenAPI spec from day one. Most membership tools haven’t caught up.
3. The brands that need this aren’t big enough to build it. A fitness chain, a mid-sized retailer, a DTC brand — they have the customer relationships but not the platform engineering team. They need infrastructure.

I’ll expand on each of these in later posts.