About PlatformDTC
PlatformDTC is a commerce platform for direct-to-consumer brands. Storefront, checkout, subscriptions, payments, fulfilment, marketing and support run as one system — and AI agents operate that system through the same audited API a person would use.
What we build
A brand doing real volume usually ends up running a commerce platform plus half a dozen applications synced to it. The daily work becomes the disagreements between them: stock counts that two systems report differently, two discount engines that stack in different orders, a renewal nobody can attribute to the campaign that produced the first order. PlatformDTC is built to remove that whole class of problem by keeping one set of records for the entire order lifecycle, from the first page view to the fourth renewal.
The other half of the product is agents. An agent that can only draft is a text box; an agent that can act needs somewhere safe to act. So the agents here write through the same API and the same permission model a member of staff would use, and every action they take is attributable and reversible. That is the part that makes an agent usable in a business rather than impressive in a demonstration, and it is where most of the engineering has gone.
What runs today
Themes edited visually or by describing the change, published to the brand’s own domain behind a CDN.
Runs on the store’s own domain in the brand’s own styling, with express wallets and post-purchase offers.
Card and PayPal acceptance through accounts the brand owns, so settlement lands with the brand.
Plans, renewals and dunning that read the issuer decline code, separating the churn nobody chose from the churn somebody did.
One stock ledger across locations, and one order record every other surface reads from.
Campaigns, flows and checkout recovery built on the same customer and order records the storefront writes to.
Reporting against real cost inputs — cost per variant, shipping, processing fees, ad spend — rather than gross sales.
A shared inbox that ingests the brand’s own mailbox, with the customer’s order history beside the thread.
Skills that perform real work — building a storefront, running campaigns, answering support — through scoped keys and an audit log.
Moving an existing brand across, which is a diligence exercise about payment tokens and URLs before it is a data import.
The next seven years
Horizons rather than dated phases. What follows is what we intend to build and roughly when — a plan, not a commitment — and where we are behind, it says where.
The first horizon is mostly finishing work, and it is deliberately not the interesting one. The plan is the three after it, and they get less certain as they go, which is the honest shape of a seven-year plan rather than a defect in this one.
The floor: one system, with an address agents can reach
A brand’s storefront, checkout, subscriptions, payments, fulfilment, marketing and support already read and write one set of records, and agents act on it through per-agent keys, an audit log and an approval gate on anything that spends. Two things finish the floor. Reach: several markets and currencies from one catalogue. And an address — today our storefronts publish no protocol endpoint an agent can discover, so an AI agent sent to buy something has to pretend to be a person with a browser. Protocol discovery, a machine checkout surface and agent payment handlers go on every storefront we publish, with the rule that a purchase needs the buyer’s approval at the moment it happens kept intact rather than engineered around. None of this is the ambition. It is the ground the rest of the plan stands on.
Objectives instead of tasks
Today you tell an agent what to do. The work of this horizon is that you tell it what you want and what it may not do — a margin floor, an inventory position, the things the brand will never say — and the system runs the loop itself: sourcing, pricing, assortment, creative, spend, replenishment, retention, all reading the same records and correcting against what actually happened. A person moves from operating the business to setting its intent and ruling on the exceptions it escalates. This is the point at which the number of people a brand needs stops scaling with the number of products, channels and countries it sells in.
Commerce between machines
The last assumption to go is that a person is on the other side. When the buyer is an agent too, a product page is the wrong artifact: an offer becomes something structured and negotiable, discovery happens agent to agent instead of through a search box, and payment needs authority that is issued per transaction with limits attached rather than a stored card with none. Building for that means an offer and negotiation surface, delegated spend authority a seller can verify, and an identity layer that answers who an agent is acting for and under what mandate — because a market where neither side is human only works if both sides can prove what they are allowed to do.
The brand as something portable
The bet underneath all of it is that the unit of commerce software stops being an application and becomes a skill: one capability, authored once by anyone, installed into any brand on the platform, running under the same scoped keys and audit trail as everything else. A brand’s whole operation then becomes a portfolio of those — which is also the point at which it belongs to the brand rather than to us, because a thing assembled from portable parts can leave. We would rather build the version people stay on by choice.
How we build it
The brand owns its money
Card and PayPal processing runs through accounts registered to the brand. We are not the merchant of record, we do not hold a balance between a sale and its payout, and a brand that leaves takes its processing relationship with it.
An agent acts under limits
Agents get their own keys, restricted to the operations they need and revocable one at a time. Writes are idempotent, so a retry cannot charge twice; anything that spends waits for a person. What an agent did is recorded against the key that did it.
Half-built does not ship
If a feature can only be built to a fraction of what it should be, we reshape it rather than ship a version that looks finished. The rule runs down to the pixels: where there is no photograph there is no grey square standing in for one, and where there is no destination there is no link.
Who we are
A Delaware limited liability company
16192 Coastal Highway
Lewes, Delaware 19958
United States
General enquiries: contact@platformdtc.com
Support, security, privacy, press and partnerships each have their own address — the full list is on the contact page.