Skip to content

What is SWIM

Commerce infrastructure for independent sellers

SWIM — Seamless Web Infrastructure for Merchants — is the layer that lets independent sellers run a real commerce business on the web without surrendering their economy, their customers, or their identity to a platform that eventually outgrows them.

Most commerce tools follow the same playbook: get sellers dependent on proprietary storefronts, lock in payment rails, and harvest the relationship between seller and buyer for platform growth. SWIM follows a different one. We build the infrastructure. Sellers own what flows through it.

That means sellers bring their own brand, set their own prices, define their own offers, and keep their customer relationships regardless of what happens to SWIM. The platform serves the seller. Not the other way around.

SWIM is built for the indie brand builder — the seller who has grown an audience but isn’t yet running a full e-commerce operation, and doesn’t want to. Sellers drive their own traffic. SWIM is the infrastructure. That’s the model — and it’s what separates us from every marketplace that treats internal discovery as the product. Sellers bring their audience directly to their stream; customers who land on SWIM can explore other streams if they choose, but no algorithm is working to redirect them there. Rather than handing off a blank canvas that demands a developer and a design budget, SWIM gives sellers brand placement: the storefront carries their identity, products, and offers in a way that feels unmistakably theirs — without building a custom site from scratch. What sellers keep is what matters: every customer relationship belongs to them — buyer contact, order history, sales data — not the platform’s. No pay-to-play tiers. No terms that quietly shift when the platform grows large enough to extract more. SWIM is infrastructure designed to stay on the seller’s side permanently.

The problem we’re solving

Independent sellers face a structural disadvantage. The same tools that give them a storefront also make them tenants. Rent goes up. Terms change. Algorithms decide who gets visibility. A seller who spends years building a customer base on a rented platform can lose it overnight — because the platform, not the seller, owns the relationship.

SWIM exists because that trade-off is bad for sellers, bad for buyers, and bad for commerce. Commerce is healthiest when it’s direct — when the person selling something can reach the person who wants it without a middleman extracting rent from both sides.

We don’t claim to be neutral. We have a point of view: sellers deserve infrastructure that serves them permanently, not platforms that use them as inventory.

Programmable commerce, not a website builder

SWIM is programmable commerce — the building blocks for a seller’s economy, not a template with a store attached.

Offers are first-class units. A Stream is a composition of those units, arranged by the seller. Templates are configuration presets, not visual themes. This means a seller can define exactly what they sell, how it’s priced, and what buyers receive — without the platform deciding what “a store” should look like.

What SWIM provides: routing, identity, payments, Drop economy infrastructure, and offer management. What sellers provide: the commerce. SWIM doesn’t curate, rank, or compete with its own sellers by launching private-label products.

This distinction matters as SWIM grows. When a platform becomes large enough to matter, the temptation to extract increases. We’ve built the five pillars below as a binding constraint on that temptation — not just principles, but architectural decisions that make extraction structurally difficult.

Every 10% of SWIM’s net revenue goes to the Kingdom Fund — a commitment to commerce that serves people and communities, not just capital.

The 5 pillars

SWIM’s design is grounded in five principles that govern every architectural and product decision:

  • Economic Continuity — your Drop economy and MBO history belong to you, not to SWIM
  • Proportional Exchange — value flows to the people creating it; no hidden fees, no platform rent
  • Identity Minimization — we collect only what’s necessary; privacy is architecture, not policy
  • Payment Plurality — we actively diversify our payment infrastructure to deliver the best rates and coverage; no permanent lock-in to any single processor
  • Modular Governance — platform rules evolve through community input, not unilateral decisions