Agent-Ready E-Commerce Store for AI-Powered Growth

An e-commerce store may have its own domain, branded design, and paid development — and still not be technologically independent. One business depends on a SaaS platform and its pricing plans. Another formally owns the source code, but cannot change a button without the team that remembers how the project is built. In both cases, the problem is the same: the store cannot be safely developed without the owner of the hidden context.

We went through this with our own fashion store, IWANT: we moved it from InSales to our own engine and then turned that experience into a reusable migration package. One of its principles is to hand the client not just a working website, but a agent-ready repository together with a deployment environment.

An agent-ready online store is a client-owned repository where an AI agent or a new developer can understand the architecture, make a limited change, test it, and prepare it for release without relying on verbal knowledge from the previous contractor. Production, meanwhile, is protected by separate permissions, checks, and human approval.

This is not a promise that “the store now writes itself.” Payments, personal data, database migrations, and production releases remain high-risk areas. But routine product changes — a new filter, a block on a product page, an integration, or a report — no longer automatically mean a new contract with the previous agency.

In short. We hand over four connected assets: code, the project map, automated checks, and controlled deployment. If the client owns only a source-code archive, but not the Git organization, cloud account, DNS, database, secrets, and rollback process, the transfer is not complete.

What it means for the store to belong to the client
Three types of dependency: SaaS, CMS, and contractor
Why Cursor alone does not make a project agent-ready
What an agent-ready repository includes
How an AI agent changes an online store
Three development modes for one codebase
How we hand deployment over to the client
Safe production: what an agent can and cannot do
How agent-ready relates to migration from InSales
What should remain with the client after handoff
Limits of the approach
FAQ
Bottom line

What it means for the store to belong to the client

Legal ownership of the code is only the first layer. For operational independence, a business needs three more.

Ownership layer	What the client should have	What happens without it
Code	Git repository, change history, dependency licenses	the source code exists, but it is unclear what changed and why
Data	access to the production database, export, backups, retention policy	the store cannot be restored or moved independently
Infrastructure	cloud/hosting, DNS, CDN, email, and analytics under the client’s accounts	the contractor effectively controls the launch and the domain
Knowledge	project map, runbook, contracts, validation commands	the new vendor has to do archaeology from scratch

An archive site-final-v7.zip does not solve the problem. It does not show history, does not guarantee a reproducible build, and often does not include infrastructure configuration. It is also not enough to create a repository in a developer’s personal account and “grant access”: the business owner must have admin rights, a clear process for changing vendors, and the ability to revoke someone else’s keys.

That is why we consider the handoff complete only when the client can answer five questions:

Where is the source code, and who is the repository administrator?
What commands does a new person use to start the project and verify a change?
Where is the data stored, and how can the store be restored from backup?
Who can release a version to production, and how is it rolled back?
Which actions require mandatory human review?

If even one answer sounds like “our developer knows that,” lock-in is still not gone.

Three types of dependency: SaaS, CMS, and contractor

Here it is important not to mix different models. InSales, OpenCart, and “1C-Bitrix: Site Management” cannot honestly be put in the same category under the headline “the code is not yours.”

SaaS platform

InSales is a hosted platform: the store runs on the service’s infrastructure, and the business manages it through the admin panel, templates, apps, and API. The platform supports product, order, and customer export; its API lets you read and modify store objects. These are useful portability channels for data, but not the full source code of the platform itself. The official documentation explicitly describes import and export and working with an external server via the InSales API.

The advantage of SaaS is fast launch and ready-made operations. The limitation is that you develop the store within the allowed extension points. An AI agent can change a template or work through the API, but it cannot redesign the platform’s closed core.

Open-source CMS

OpenCart is a different case. It is a free open-source e-commerce platform, and the official repository is distributed under GPLv3. You can store the code yourself, deploy it on your own server, and modify it.

But open code does not automatically mean agent-ready. A project can be overloaded with conflicting extensions, manual core edits, and undocumented dependencies. In that case, lock-in appears not at the licensing level, but at the level of a specific build and the person who knows its history.

Commercial boxed CMS

“1C-Bitrix: Site Management” is a commercial self-hosted product. After purchase, the client receives a distribution package and can install it on their hosting independently. Here, the dependency is not about the lack of files as such, but about the license, CMS architecture, updates, modules, and the market for specialists.

Custom codebase

Custom development gives maximum freedom only with the right handoff. If the cloud account is set up under the agency, deployment runs from one engineer’s laptop, and the business rules live in that person’s head, a “custom engine” turns into the same black box.

Model	Who controls the core	Can you give the agent the entire project	Main dependency risk
Hosted SaaS	platform provider	no, only the allowed layers	pricing, API, and platform boundaries
Open-source CMS	client and community	yes	chaotic customization and plugins
Commercial self-hosted CMS	vendor + client team	yes, within the license	updates, modules, ecosystem-specific dependencies
Custom agent-ready	client	yes	repository discipline has to be maintained

The takeaway is not that a custom engine is always better. The takeaway is that the types of dependency are different, and you need to choose based on the cost of change, risk, and your business horizon.

Why Cursor alone does not make a project agent-ready

An AI editor can see files, but it does not know implicit agreements. It does not know why a discount is applied after a promo code, which payment status counts as final, whether a column can be removed from the orders table, or why one webhook must be idempotent.

In an unprepared codebase, an agent often generates a plausible but wrong change. The code compiles, the interface looks convincing, but a hidden invariant is broken. In e-commerce, that can mean double charges, an incorrect inventory balance, a lost order, or a personal data leak.

Agent-ready starts not with choosing a model, but with reducing ambiguity:

project rules are documented alongside the code;
one task is solved with one recognizable pattern;
contracts between layers are typed;
checks run with a single command;
risky areas are marked and protected;
the infrastructure separates preview from production;
every change has a reversible path.

TypeScript is useful here not as a trendy stack label, but as one of the feedback loops. By the definition in the official Handbook, TypeScript statically checks a program before it runs. It catches some data-shape errors — for example, a missing field or an incompatible type — before execution. But types do not prove the correctness of pricing, tax rules, or a business process. For that, you need tests and domain invariants.

What an agent-ready repository consists of

We treat the repository as an executable contract between the business, the developer, and the agent.

1. Project map

The first file should answer not the question “what brand is this,” but “how to work safely.”

It should include:

the purpose of services and directories;
local startup commands;
required environment variables without secret values;
commands typecheck, lint, test, build;
database interaction rules;
a list of risky areas;
pull request readiness criteria;
instructions for staging and production;
contacts for the people responsible for money, data, and infrastructure.

The map should be short enough for an agent to read before its first edit, and specific enough for a new developer to get up to speed from it. A huge wiki that does not match the code is worse than ten current pages living next to the project.

2. End-to-end types and contracts

A product passes through the database, backend, API, storefront, checkout, payment, analytics, and admin panel. If its shape is described separately at each layer, changes start to drift apart.

That is why critical entities — Product, Variant, Money, Cart, Order, Payment, Shipment, Customer — get explicit contracts. At external boundaries, data is validated: TypeScript types disappear after compilation and by themselves do not protect runtime from a bad webhook or import.

Domain types that prevent confusing similar values are especially useful:

a price in minor currency units and a formatted string;
an internal order ID and a public order number;
a paid order and an authorized payment;
inventory on hand and quantity available for sale;
a UTC date and the user's local time.

3. Predictable patterns

If one API endpoint validates input at the boundary, a second validates it in the service, and a third trusts any JSON, the agent has to guess the right style. The more options there are, the higher the chance of accidentally choosing the weaker one.

We reduce variation:

one feature-module structure;
a single approach to errors and logging;
one authentication mechanism;
single access to data;
repeatable test patterns;
centralized integration adapters;
a ban on business logic inside UI components.

Consistency here is not about aesthetics. It is a way to manage the likelihood of error.

4. Closed Validation Loop

The agent must not only write code, but also receive a machine-readable response explaining what is wrong with it.

Minimum cycle:

formatting and linting;
strict type checking;
unit tests for domain logic;
integration tests for the API and database;
production build;
smoke test for the critical path;
preview or staging for visual verification.

Checks do not guarantee the absence of defects. They turn part of the hidden errors into specific messages that the agent can fix on its own.

5. Guardrails for Risky Areas

In the repository, clearly mark code that must not be changed or released without a human:

payment creation and confirmation;
refunds and duplicate charges;
access rights and personal data;
migrations that delete or transform data;
tax calculations and fiscalization;
bulk inventory synchronization;
production secrets and DNS;
irreversible administrative operations.

For these areas, a generic "be careful" is not enough. You need CODEOWNERS/required review, separate tests, minimum permissions, and a ban on direct pushes to production.

How an AI agent changes an online store

A normal workflow looks like a short engineering cycle, not a "make it pretty" chat.

Task. The owner describes the expected result and acceptance criteria: for example, add an in-stock filter for a specific store.
Discovery. The agent reads the project map, finds the current filter, catalog contracts, and existing tests.
Plan. Before making changes, it lists the affected files, risks, and checks.
Implementation. Makes a minimal diff within the existing pattern.
Self-check. Runs types, lint, tests, and the build.
Preview. Creates an isolated version for review.
Review. A human checks the business meaning and UX, and for a risky area, engineering safety as well.
Release. CI/CD deploys the approved commit, runs a smoke test, and preserves rollback capability.

In this process, the agent does not get unrestricted access to the store. It works with the change and proof of its correctness. The right to release a version is a separate capability.

Three Modes for One Codebase

A client does not choose one mode forever. One codebase supports all three.

Self-service through the admin panel

Content, products, prices, promotions, collections, SEO fields, and operational settings change without development. A good admin panel is more important than trying to solve every problem with code.

With an AI agent

The agent adds limited features from instructions: a new block, filter, report, export, or integration adapter. This approach pays off when the task is formal enough and the repository provides fast feedback.

It is useful to define an autonomy limit in advance:

the agent can read all code;
can create a branch and pull request;
can run CI and preview;
cannot read production secrets;
cannot independently approve a production deploy;
cannot perform a destructive migration;
cannot change payments without specialized review.

Together with us

Complex integrations, architectural changes, security, and SLA-backed development remain with the team. At the same time, the client is not locked in: all work happens in their repository and infrastructure.

We define the support boundary in advance. Client self-serve changes and the contractor's retainer are different areas of responsibility. If a third-party agent changes checkout outside the process and it reaches production, that incident should not automatically be treated as the contractor's SLA issue. Otherwise, the price of freedom is quietly shifted to the party that did not control the change.

How We Hand Deployment Over to the Client

Deployment is not the final button after development; it is part of the product. If only the former contractor can deploy the store from their own laptop, the client has not received an independent system.

The basic flow looks like this:

commit → automated checks → preview/staging → manual approval → production → smoke test → monitoring → rollback on error

The specific cloud may differ. The contract remains the same.

1. Infrastructure is Set Up in the Client's Name

On the client side, the following should be in place:

GitHub/GitLab organization;
cloud or hosting account;
domain registrar and DNS;
production database and backup storage;
CDN/object storage;
email and SMS provider;
payment dashboard;
analytics, error tracking, and uptime monitoring.

The contractor gets the role needed to work, but does not become the sole owner. The client retains at least two admin users and a process for revoking access.

2. Environments Are Separated

Local, preview, staging, and production should not share the same database or the same keys. Preview uses test integrations. Staging mirrors the production architecture as closely as cost justifies. Production accepts only approved versions.

GitHub describes environments as separate targets development, staging and production; for them, you can restrict branches, control access to secrets, and require approval. In the official GitHub documentation , this is a built-in deployment governance model.

3. CI Is the Gatekeeper

Direct file uploads over FTP are not allowed. Before merge, the following are required:

types;
lint;
tests;
production build;
migration verification;
dependency/security scan according to the chosen policy;
preview or staging smoke test.

A protected branch does not accept changes until the required checks pass. GitHub separately notes that when required status checks are enabled, a protected branch cannot be updated if a required check is failing.

4. Secrets Do Not Live in the Repository

Payment, database, email, and external API keys are stored in a secret manager or environment secrets. The agent sees variable names and test values, but not production credentials.

GitHub Actions allows secrets to be stored at the organization, repository, or specific environment level. An environment secret becomes available to a job only after environment protection and approval are passed — this is described in GitHub Secrets.

At the same time, the principle of least privilege applies: a deploy credential can deploy the app, but does not need to be able to delete a cloud project; the storefront gets only the database permissions required by runtime.

5. Production Requires Human Approval

Green CI means "known automated checks passed," not "the business has definitely approved." For production, we keep approval with the responsible person. For payment changes or migrations, a subject-matter reviewer is added.

The agent can prepare release notes:

what changed;
which commit is being released;
which checks passed;
whether there is a migration;
how to verify the result;
how to roll back.

But approval remains a separate human action.

6. Database Migrations Ship Separately from Hope

The most dangerous deploy is the one where new code is incompatible with the old schema, and the migration deletes data.

A safe model prefers reversible steps:

add the new structure without removing the old one;
release code that understands both versions;
move or backfill data;
switch reads;
confirm correctness;
remove the old field in a separate later release.

Before a risky migration, a backup is created and verified. Rollback describes not only reverting the app to a previous image/commit, but also the fate of data already changed. The phrase "we'll roll back Git" does not restore a deleted column.

7. A Release Needs Monitoring and Rollback

After deployment, the homepage, catalog, product page, cart, test order creation, and health endpoint are checked automatically. The team sees errors, latency, and key business events.

Rollback should be a preplanned operation:

the previous image or build remains available;
the configuration version is known;
the rollback command is documented;
the migration is classified as reversible or irreversible;
the owner knows when to roll back and when to fix forward.

This makes deployment a reproducible process that a new team can operate — and that an AI agent can safely prepare without getting unilateral control over production.

Safe Production: What an Agent Can and Cannot Do

It is convenient to divide capabilities not by the principle of "AI or human," but by potential damage.

Action	Agent independently	Human required	Additional protection
change a text UI block	yes, in a branch	review before merge	preview + UI smoke test
add a catalog filter	yes, in a branch	product review	types + API/integration tests
update a dependency	can prepare a PR	engineering review	lockfile, tests, security scan
change the discount calculation	prepare only	domain reviewer	money scenario tests
change payment/refund	no standalone release	senior review + approval	sandbox payment, audit log
perform destructive migration	no	DBA/responsible engineer	backup, rehearsal, rollback plan
change DNS or production secret	no	infrastructure owner	MFA, least privilege, audit
deploy to production	can prepare a release	required approval	protected environment

The most important point: the ability to write a change and the right to apply it are not the same thing. A repository can be made agent-friendly without turning production into an open console.

For more on choosing the tasks where autonomy is actually useful, see our article “AI Agents in Business: Where They Deliver and Where It’s Hype”. And the link between AI development and new team roles is covered in the article “What Comes After AI: Seamless Development”.

How agent-ready connects to migrating from InSales

An agent-ready repository is not a separate cosmetic add-on after migration. It is the result of the way the migration itself is built.

Based on IWANT’s experience, we identified six parallel workstreams.

1. Data inventory

A catalog is not just names and prices. You need to list:

products, variants, attributes, and collections;
images and files;
inventory and warehouses;
customers and consents;
orders, statuses, and history;
promo codes and discount rules;
SEO fields;
content pages;
integration identifiers.

InSales provides CSV/YML export and API, but every real export has its own fields, gaps, and historical quirks. That is why the migration is built around the specific data, not an ideal schema from the documentation.

2. URL map and SEO

Before launch, the old URLs are exported and matched to the new ones. The decision is based not only on catalog structure, but also on traffic, external links, and page value.

For changed addresses, permanent server-side redirects are set up. Google recommends using 301 or 308 where possible for permanent URL moves — this is noted in the Site Moves and Migrations guide.

The wrong “all old pages → homepage” setup destroys relevance. A product should lead to the same product, a category to the relevant category, and a removed page to the nearest real alternative only when one truly exists.

3. Double-checking the data

An import is not considered complete when the message says “the script finished.” We compare counts and sample checks:

number of products and variants;
required fields;
prices and currencies;
inventory;
images;
order-customer links;
statuses;
high-traffic URLs;
test orders.

All discrepancies are classified: fix, intentionally transform, or exclude with a documented decision.

4. Cutover rehearsal

The migration is first run in staging. The team measures the duration of the final sync, checks redirects, integrations, payments, shipping, email, and analytics. Then it documents the launch runbook minute by minute, along with owners.

The goal is not to promise “we’ll switch over sometime at night,” but to know in advance:

when structural changes stop in the old store;
which data is synced last;
who changes DNS;
who checks payments;
what condition triggers rollback;
where the issues found are logged.

5. Launch without losing new orders

The old store keeps taking sales until the agreed cutover. Before the switch, a final delta import is run. After launch, both sources are compared so that an order created during the transition window does not disappear.

The specific approach depends on the API and the architecture. Sometimes near-real-time sync is possible; sometimes a short freeze on admin changes is needed. An honest plan states this upfront.

6. Operations handoff

After stabilization, the client gets more than just the production URL. They get the repository, infrastructure, instructions, access, backup/restore, release process, and a list of known limitations.

That is how migration turns a store from a platform service into a manageable business asset.

What should remain with the client after handoff

Below is the acceptance checklist. It can be used not only for our development work, but also in conversations with any contractor.

Code and knowledge

[ ] The repository is in the client’s organization.
[ ] The client has at least two administrators.
[ ] The commit history and decision history are preserved, not just an archive.
[ ] There is an architecture map and a directory catalog.
[ ] There are commands for running, testing, and building.
[ ] The domain invariants for checkout, payments, and inventory balances are documented.
[ ] Risky areas and required reviewers are listed.

Data and Infrastructure

[ ] Cloud, DNS, and the production database are set up under the client’s ownership.
[ ] Secrets are not present in Git.
[ ] Local, staging, and production use different credentials.
[ ] Automatic backups are configured.
[ ] Restore has been tested at least once in a test environment.
[ ] Analytics, error tracking, and uptime monitoring are accessible to the client.

Development and Deployment

[ ] The pull request runs typecheck, lint, tests, and build.
[ ] The production branch is protected from direct pushes.
[ ] A preview or staging environment is created before production.
[ ] Production deploy requires approval.
[ ] Migrations have a separate review and a data plan.
[ ] The previous version can be restored using the instructions.
[ ] After release, a smoke test of the key purchase flow is run.

If 5–7 items are missing, the project is probably still dependent on the performer’s memory. If infrastructure access and rollback rights are missing, the dependency is already operational, even if the source code is available.

Scope of the Approach

Agent-ready does not eliminate engineering responsibility.

An AI agent does not replace a specialist in critical tasks

Complex integration with 1C/ERP, security, payments, taxes, fiscalization, high-load architecture, and incident recovery require a specialized professional. An agent accelerates analysis and implementation, but it does not automatically bring experience or accountability.

A repository degrades without discipline

The project map gets outdated, tests stop reflecting behavior, and exceptions multiply. Agent-ready is not a forever certificate. Every change must preserve system predictability.

A custom engine does not pay off for everyone

If the business is fine with a platform, changes are infrequent, and revenue does not justify owning the operation, SaaS may be the better economic choice. A platform buys speed and removes part of the infrastructure burden. Don’t build a custom system for status.

Transferring control means transferring responsibility

By owning production, the client is responsible for access, renewals of services, backups, security, and release decisions—either independently or through a support agreement. Control never exists separately from operational responsibility.

FAQ

What is an agent-ready repository?

It is a repository with an up-to-date project map, predictable architecture, typed contracts, automated checks, and a documented safe release process. An AI agent can make a change and prove that the known checks have passed, while production remains protected.

Is it enough to open an existing online store in Cursor?

No. The editor gives the agent access to files, but it does not create missing domain rules, tests, permissions, staging, or rollback. On a chaotic project, the tool only makes changes faster, with unknown risk.

Can an AI agent deploy a store on its own?

Technically it can, but for production that is a poor authorization model. It is safer to let the agent create a branch, pass CI, deploy a preview, and prepare the release, then launch production after human approval.

How is this store different from OpenCart?

OpenCart already provides open source code and self-hosting. The difference with the agent-ready approach is not the fact of code access itself, but the specific build: contracts, consistent patterns, tests, documentation, limits on risky areas, and reproducible deployment.

How is it different from 1C-Bitrix?

1C-Bitrix: Site Management is a self-hosted commercial CMS with a license, distribution package, modules, and its own ecosystem. A custom agent-ready repository does not depend on that CMS architecture, but it does require independently maintaining the core, infrastructure, and security.

What happens to SEO when migrating from InSales?

SEO risk is reduced if, before cutover, you collect the old URLs, map them to the new ones, set up relevant 301/308 redirects, preserve metadata and content, update the sitemap/canonical tags, and check priority pages after launch. Temporary fluctuations cannot be eliminated completely.

Who is responsible if the client’s agent breaks production?

This is defined by the contract and the access process. By default, the client’s independent changes are not covered by the contractor’s SLA. That is why production is protected by approval, and support boundaries plus the incident-response process are documented before handoff.

Bottom Line

A custom online store is not the same as a “hand-coded website.” It is a system that the business can manage even if the tool, agent, or contractor changes.

The deliverables should be:

the code and history in the client’s repository;
a clear project map;
types, tests, and repeatable patterns;
isolated environments and protected secrets;
CI/CD with human approval;
backups, smoke tests, and rollback;
a clear boundary of responsibility.

We completed the migration to our own IWANT store and deliver exactly this kind of system to clients: an e-commerce core, data migration, an SEO map, infrastructure, and a repository that can be developed through the admin panel, with an AI agent, or together with us.

If your store runs on InSales, 1C-Bitrix, OpenCart, or a website builder and you want to understand the real level of dependency, we’ll do a free assessment. We’ll break down what already belongs to the business, what is still missing for handoff, what the migration looks like, and where a custom engine truly pays off.