Stop Renting Your Commerce

A proposal for ownership-model agentic commerce before the category is closed off by SaaS defaults.

The Pattern That Keeps Repeating

Every wave of commerce tooling in the last 25 years has followed the same arc. Software you bought. Then software you leased. Then software you rented monthly. Then software you rented and didn’t actually own anymore even when you stopped paying.

The pattern isn’t accidental. It is the natural outcome of venture-backed software companies discovering that recurring revenue is more defensible than license sales. They start with ownership because it gets customers in the door. Then they graduate the category to rental because rental creates compounding switching costs that make it expensive to leave. By the time the customer understands what has happened, leaving costs more than staying.

The receipts:

Shopping carts. osCommerce launched in 2001 as free, open-source software you installed on your own server. You owned it. Magento followed — more powerful, still owned. Then Shopify: $79–$299/month, vendor-managed, no local install, data lives in Shopify’s infrastructure. A million-dollar store built on Shopify is built on rented land. If Shopify changes their pricing, raises their take rate, or deprecates an API, the merchant absorbs the cost.

Payment processing. Authorize.net sold software integrations you licensed and controlled. Stripe is a rented API that takes a percentage of every transaction forever. 2.9% + $0.30 per transaction is not a fee — it is a permanent stake in your revenue that compounds as you grow.

Email marketing. In 2005, a serious e-commerce operator ran their own mail server. Today they pay Klaviyo $700/month for 50,000 contacts, with pricing that scales with list size — creating a direct financial incentive for the platform to help you grow your list regardless of list quality. The data is Klaviyo’s to retain when you leave.

Analytics. Server log files were free, owned, infinitely queryable. Google Analytics replaced them with a free tool — but the data belongs to Google, not to you. When businesses moved to paid analytics platforms (Mixpanel, Amplitude), they gained better tooling and lost ownership again. They now pay for access to their own behavioral data.

Customer support. Kayako and HESK were owned helpdesk installations. Zendesk and Intercom are $50–$150 per agent per month, vendor-managed, with customer conversation history that exits with you on a paid migration plan if you decide to leave.

The direction of travel is identical across every category: from ownership to rental, from control to dependency, from one-time cost to permanent line item.

By the time a typical SMB e-commerce operation reaches maturity, they are spending between $2,000 and $8,000 per month on commerce tooling they do not own and cannot customize without paying the platform for the privilege. The stack is rented. The roadmap is someone else’s. And the exit cost — migrating data, rebuilding integrations, retraining staff — is often two to five times the annual subscription cost.

Agentic Commerce, On the Same Trajectory

The same arc is forming in real time for AI-powered commerce agents.

Stripe Agentic Commerce Protocol (ACP) Suite is built for enterprises with internal engineering teams. It ships as a managed service integrated into the Stripe ecosystem — the same ecosystem that already takes a percentage of every transaction. Adding AI agents to Stripe’s surface area means those agents operate on Stripe’s infrastructure, under Stripe’s pricing model, with Stripe’s roadmap determining what they can and cannot do.

Shopify’s AI agent rollout is locked to Shopify’s platform. Agents built in Shopify’s ecosystem cannot be ported to a non-Shopify store. They are bundled with Shopify subscriptions and positioned as a reason to stay on Shopify — not as infrastructure the merchant controls.

The SaaS platform plays currently raising rounds are, without exception, structured as recurring subscription services. Every pitch deck in the agentic commerce space is a SaaS pitch deck. Monthly fees. Usage-based pricing that scales with your volume — meaning your AI costs grow as your business grows, permanently. Vendor-controlled roadmap. Eventual lock-in as behavioral data accumulates inside the platform.

The honest read: in 18 to 24 months, “agentic commerce” will mean “the agentic commerce service you subscribe to from one of three or four dominant platforms.” The same way “shopping cart” came to mean “Shopify.”

For small and mid-market businesses generating $10,000 to $10 million per year in revenue, this means paying a permanent percentage of their AI-driven revenue back to platforms that had no stake in building the business. The operators who move now — before the category consolidates — can own their AI infrastructure outright. The operators who move in two years will rent it.

What You’re Actually Paying For

When people compare SaaS costs, they compare monthly bills. That is the wrong comparison. The monthly bill is the visible fraction of the total cost. The invisible costs are the ones that compound.

Vendor lock-in. Your customer behavioral data — browsing history, abandonment patterns, checkout behavior, post-purchase sequences — accumulates inside the platform’s data model. It is integrated with the platform’s tooling. When you leave, the data leaves in whatever format the platform chooses to export it, reformatted for no other system, requiring custom rebuild work to make usable elsewhere.

Roadmap subordination. Features you need are prioritized behind features that enterprise customers on six-figure contracts need. When you report a bug, you join a queue. When you request a capability, you vote on a public board and wait. The platform serves its highest-value customers. You are not that customer.

Pricing changes you did not agree to. The history of SaaS commerce tooling is a history of pricing resets. Klaviyo changed their pricing structure in 2022. Shopify raised their take rate. HubSpot added contact tiers. No merchant agreed to these changes — they received a 30-day notice and a choice between absorbing the increase or migrating. Most absorb the increase.

Feature deprecation on the platform’s timeline. The API your automation depends on gets deprecated in 6 months. The webhook format changes. The integration you built 18 months ago now requires a rebuild. You absorb the engineering cost because the alternative is leaving.

Data exit penalties. Leaving a mature SaaS commerce platform requires custom data export, reformatting work, integration rebuild, and often a paid migration service the departing platform is not incentivized to make easy. The pattern across the industry: the cost of leaving is typically two to five times the annual subscription cost in engineering time and data fidelity loss.

The cost of the platform isn’t the monthly bill. It’s the increasing cost of the exit you’ll eventually want to make and won’t be able to afford.

The Path That’s Available Right Now

The proposal is direct.

Install the four agentic commerce capabilities that actually move revenue — product discovery, cart recovery, checkout intelligence, and post-purchase automation — as code you own, on infrastructure you own, with no recurring fee to the implementer.

The four agents and what they each do:

Product Discovery Agent. Surfaces the right product at the right moment based on browsing signal and catalog logic — not a generic “recommended for you” rail. The agent reads session behavior, weights by margin and inventory velocity, and responds to the specific thing the customer is actually looking for.

Cart Recovery Agent. Responds to the specific signal that caused the abandonment. A customer who stalls on shipping cost gets a different response than one who stalls on product uncertainty or one who got distracted. Generic cart emails are 10-year-old technology. Signal-specific responses are not.

Checkout Intelligence. Instruments the checkout flow to identify stalls and act on them in real time. Friction at a specific field. A pricing hesitation. A shipping option mismatch. The agent identifies the stall and reduces it — not with a popup, but with the right intervention at the right moment.

Post-Purchase Agent. Automates the full delivery lifecycle — confirmation, tracking, delivery handoff, follow-up — with zero manual touch per order. Eliminates a category of support tickets before they exist.

What makes this ownership-model rather than rental:

The code lives in your repository. It runs on your VPS — compute you pay for directly, not marked up through a platform. There is no license fee after delivery. No usage-based pricing that scales with your volume. No vendor on a permanent line item on your P&L. The implementer is gone after delivery, not a dependency. You can extend the code yourself, hire any developer to extend it, or fork it entirely. Because you own it.

The one requirement that makes this real: a VPS the customer owns or controls. If the agents run on someone else’s compute, they are not owned. The infrastructure requirement is not a technical constraint. It is the thing that separates ownership from rental at the infrastructure level.

How the Build Actually Works

This is not a theoretical proposal. The build pattern is operational and has been applied to three production sites.

The process:

A customer applies. The application takes ten minutes — what they sell, what their current stack looks like, where their funnel leaks, what they want built. Applications are reviewed individually. If it’s a fit, there is a scoping call. If it’s not, they hear that directly with a reason. No ghost, no form letter.

After the scoping call, the agents are designed for that specific store. Not a template — a design that accounts for their catalog structure, their abandonment patterns, their checkout flow, their customer behavior data. The build window is 30 days for a Foundation build (single agent), 60 days for the Full Suite (all four agents).

At the end of the build, the agents are deployed to the customer’s VPS. Then a verified test purchase: an autonomous agent completes a purchase on the store. The transaction lands in the customer’s Stripe. They see the agent work end-to-end before handoff. Not a demo. An actual purchase.

After handoff, the customer owns the deployed code. The 60-day support window covers tuning and anything that surfaces in production. After 60 days, the formal engagement structure ends. The code stays. The direct-line email stays open. The dependency on the implementer does not.

Three live implementations as proof the pattern works:

• sidratnam.com/agents — contact endpoint for this site
• cinematiccard.com/agents — digital greeting card purchases
• tradeexecutor.ai/agents — software license purchases

These are not pilots. They are running in production, processing real transactions, on infrastructure each site owner controls.

What It Actually Costs to Run

The operating cost of JARVIS across all three production sites — sidratnam.com, cinematiccard.com, and tradeexecutor.ai — running daily for SEO analysis, content generation, image generation, internal link auditing, and reporting:

What a SaaS-equivalent stack running comparable functionality across three sites would cost:

JARVIS running across all three sites operates at a rate that is approximately 45,000× cheaper than a SaaS-equivalent stack. Every dollar of that cost is variable token spend on infrastructure the customer controls — not vendor margin.

This cost profile is not accidental. JARVIS is built credit-efficient by design. Local sentence-transformer embeddings handle every operation that does not require a frontier model — similarity work, clustering, deduplication. Imagen 4.0 generates images on demand only when a new blog post publishes, with Gemini as fallback. Claude gets called for the work where reasoning quality actually matters — strategic content decisions, copy generation, daily synthesis. The architecture is the budget.

The Objections, Named in the Proposal

“I don’t have engineering resources to maintain this.”

You don’t need them to maintain it. The maintenance is minimal because the agents run on stable infrastructure, not on a constantly-churning SaaS platform. If something does break, you hire a developer for a few hours. You don’t pay $500 per month to a platform forever on the theory that something might break and the platform will handle it.

“SaaS is faster to get started.”

Yes. And faster to get trapped in. The decision isn’t speed-to-launch. It’s whether you are building a business that grows or a business that is locked into vendor pricing escalators that will suppress your margins five years from now. The 30-day build window is not meaningfully slower than a SaaS onboarding for operators who take the setup seriously.

“What about updates? AI models change.”

The architecture is designed for model swappability. Anthropic releases a new Claude version — you update one config value. Gemini changes their pricing — you switch to a competitor or a smaller model for the tasks where quality matters less. Because you own the code, you control the upgrade path. No platform deprecation notice, no forced migration, no pricing surprise.

“What if the implementer disappears?”

That is the point. After delivery, you don’t need the implementer. The code is documented, in your repository, accessible to any developer you hire. No platform dependency means no platform-vanishing risk. The implementer being gone is the feature, not the risk.

“But Stripe and Shopify will build more sophisticated tools.”

Maybe. Eventually. But “more sophisticated” in a SaaS context means “more locked-in, more expensive, more aligned with enterprise customers who generate more revenue for the platform.” The sophisticated version of agentic commerce that is actually optimized for your store is the one custom-built for your catalog, your abandonment patterns, your checkout flow — not the version optimized for a platform’s median customer across a hundred thousand stores.

Who This Proposal Is For

This proposal is not for everyone. Part of what makes the build work is that it is only applied to operators where it will actually work.

This proposal is for operators who:

• Generate $10,000 or more per month in commerce revenue
• Know where their funnel leaks and want it fixed permanently, not patched with a subscription
• Want to own their AI infrastructure rather than rent it
• Can manage or hire someone to maintain a VPS
• Recognize the rental trap and want out before the category consolidates

This proposal is not for operators who:

• Are pre-launch with no behavioral data — there is no signal to optimize against until you have real customers
• Want AI without understanding what it does
• Are looking for a cheaper version of a SaaS tool
• Are uncomfortable owning and controlling their own server

The filter matters because the build is custom. Applying it to an operator who isn’t ready wastes both parties’ time and delivers worse results. The application process exists to find the fit before the build starts.

Possible. Honest. Right.

Every proposal in this series is measured against three standards. This one is no different.

Possible. The proposal is operational. Three live implementations are running today on real stores processing real transactions. The economics are documented. The build pattern is proven. The implementer is named. This is not a concept or a roadmap item — it is a deployed system available for replication right now.

Honest. Every claim in this proposal has receipts. The agents are visible at the URLs cited. The token logs will be real when filled in — the placeholder structure exists to prevent publishing fabricated numbers as production data. The objections are named in the proposal itself, not buried. The filter that disqualifies most applicants is stated plainly. If you apply and it is not a fit, you will hear that directly.

Right. Ownership-model commerce infrastructure serves the operator, not the platform. It aligns the implementer’s incentives with the customer’s outcomes — the build is delivered and then the relationship ends on schedule. No recurring fee that requires the customer to keep paying regardless of value. No platform that profits from making it expensive to leave. The goal is infrastructure the operator actually controls — not dependency dressed up as a feature set.

What Happens Next

The build is operational. The path is documented. The receipts are public. The window is open right now.

See the offering in full: sidratnam.com/agentic-commerce →

Apply at sidratnam.com/agentic-commerce/apply.

If it’s a fit, you’ll hear back within 48 hours. If it’s not, you’ll hear that too — directly, with a reason.

— Sid Ratnam
April 2026