Building an AI Layer That Runs an E-commerce Business

• Role: Full-Stack Developer → AI Engineer (self-initiated)
• Project: Multi-tenant e-commerce platform (company project)
• Stack: MCP Server SDK, Express.js, PostgreSQL, Redis, BullMQ, TypeScript, Zod

---

Quick Facts

---

The Setting

I joined a startup that builds custom e-commerce platforms. Their flagship product was a Shopify-like multi-tenant system — multiple client stores running on shared infrastructure, each managing their own operations independently.

Two clients drove most of the business. Client A sold sports equipment and processed roughly 100 website orders plus 200+ marketplace orders every single day. Client B sold home appliances.

The admin dashboard was the operational backbone. Every day, teams of administrators, product managers, order managers, and inventory managers lived inside this tool — managing products, processing orders, creating shipments, updating inventory, writing SEO content, adjusting prices, and handling customer accounts.

The software worked. The problem was somewhere else.

---

The Problem I Noticed

After working across multiple modules of the platform, I started seeing the same pattern everywhere:

Employees weren't struggling because the software lacked features. They were struggling because of how they had to use it.

Every task followed the same ritual. Open one screen, search for data, copy information, navigate to another screen, fill in a form, switch to ChatGPT for a product description, copy the result back, then continue.

Five patterns kept showing up:

1. Same workflow, every day. Shipment creation alone required employees to repeat nearly identical steps hundreds of times daily. Different orders, same process.

2. Constant context switching. Dashboard → ChatGPT → Dashboard → Google → Dashboard → shipping portal → back to Dashboard. Each switch cost attention and time.

3. Business knowledge trapped behind UI navigation. People understood the business deeply. They didn't always remember where every button lived. The software was a wall between knowing what to do and doing it.

4. Growing complexity. Every new feature made the dashboard harder to navigate. Classic SaaS problem — more power, less usability.

5. Predictable, repetitive logic. Most operations were deterministic. The inputs changed, but the steps never did. That made them perfect candidates for automation.

The turning point was a simple realization:

Employees aren't paid to operate the dashboard. They're paid to run the business. The dashboard is just a tool.

If AI could understand what someone wanted to do and safely execute the right workflow, employees could focus on decisions instead of clicking through screens.

Nobody asked for this. There was no ticket. No spec. But because I'd built much of the platform myself, I knew it was technically feasible — and I believed it would create more value than any single feature in the backlog.

---

Validating the Idea

My hypothesis wasn't that people wanted AI. It was simpler:

If employees could describe tasks in plain English instead of navigating screens, they'd complete repetitive work faster — while keeping the same business rules and security.

Three signals gave me confidence:

• High frequency — Shipments, product updates, SEO changes, and price adjustments happened continuously, not weekly.
• Predictable workflows — Every task followed nearly the same steps. The inputs changed, the logic didn't.
• Existing backend — The platform already had APIs for all these operations. I didn't need to build business logic — I needed a better interface for it.

Since the APIs already existed and workflows were well-defined, I estimated an MVP could ship in about a week.

---

Choosing the Approach

I considered three options:

Option 1: Improve the dashboard UI. Add shortcuts, reduce clicks, introduce bulk actions. This would help, but users would still need to learn the interface and navigate between modules.

Option 2: Build a chatbot. Connect an LLM and let people ask questions. But chatbots mostly answer questions — they can't safely create shipments, update prices, or modify inventory in a production system.

Option 3: Build an AI execution layer using MCP. Expose the platform's existing business operations as structured tools that an AI can understand, select, and execute — with proper authorization at every step.

I chose MCP because the problem wasn't missing functionality. The backend could already do everything. The missing piece was an intelligent layer that could understand user intent and orchestrate existing operations safely.

I wasn't trying to make the dashboard AI-powered. I was trying to make the business operations AI-native.

DIAGRAM

The user thinks about the business. The system handles the software.

---

How It Works

The architecture was straightforward. The MCP layer sits alongside the existing admin dashboard and storefront — all three consume the same backend services.

DIAGRAM

The most important architectural decision: the MCP layer never bypasses the existing backend. It uses the same services, enforces the same business rules, and respects the same permissions as the admin dashboard. A product update through ChatGPT follows the exact same validation as one through the dashboard.

Tools Designed Around Business Language

I designed tools around what employees actually say, not around API endpoints.

Instead of POST /api/shipments/create, the tool is called create_shipment_for_order. Instead of PATCH /api/products/:id, it's update_product_details.

This distinction matters because the AI model thinks at the business intent level. Across 11 business domains — products, orders, shipments, inventory, SEO, pricing, customers, reports, categories, coupons, and system — I built 60+ tools covering the full operational surface.

Security That Mirrors the Dashboard

The most critical design principle:

If an employee can't do it on the dashboard, the AI can't do it either.

The MCP layer reused the exact same role-based access control built into the Express APIs. An order manager who can't edit products on the dashboard can't edit products through AI. An inventory manager who can only read product data gets the same restriction through ChatGPT.

Every request passes through six security layers: authentication, rate limiting, scope enforcement, tenant isolation, input validation, and output sanitization. No exceptions.

Guardrails for Risky Operations

Not every action should execute immediately. Deleting a product is not the same as listing products.

I classified every tool into three risk tiers:

• Low risk (reads) — Execute immediately. No friction.
• Medium risk (single writes) — Validate inputs, enforce permissions.
• High risk (deletes, bulk operations, financial changes) — Require explicit confirmation before executing.

For high-risk operations, the system returns a warning and a server-generated confirmation hash. Only after the user explicitly confirms — and the hash is validated — does the action proceed. The AI can't forge the hash or skip the confirmation step.

Background Processing for Bulk Operations

When someone asks to "create shipments for all pending orders," the system doesn't block waiting for every shipment to complete. Instead, it validates permissions, enqueues individual jobs to a durable queue (BullMQ), and returns immediately. Workers process shipments in the background, and the user can check progress anytime.

This made bulk operations both safe and responsive.

---

Shipping the MVP

Instead of building the perfect system, I focused on one question:

What's the smallest version that proves we're solving the right problem?

I picked only the highest-frequency workflows:

• Shipment creation — hundreds daily, most repetitive
• Product management — frequent updates, descriptions, variants
• SEO content generation — repetitive and time-consuming
• Pricing updates — regular adjustments
• Order inquiries — status checks and summaries

Since every backend API already existed, I spent zero time rewriting business logic. All the work went into exposing those capabilities safely through MCP.

From idea to working MVP: one week.

That speed wasn't because I cut corners. It was possible because I already understood the architecture, the business workflows, and the backend services.

The moment it worked:

An employee types: "Create shipment for order #12345"

The system finds the order, validates permissions, calls the shipping API, creates the shipment, and returns confirmation. No dashboard. No navigation. No manual search.

---

What I Learned From Real Usage

Once the MVP shipped, my focus shifted from "Can we build this?" to "Can people rely on this?"

Instead of adding features, I observed:

• Where does the AI pick the wrong tool?
• Which tasks produce inconsistent results?
• Where could users accidentally trigger destructive actions?

The biggest realization: building the AI was the easy part. The hard part was making it behave consistently inside a real business where every action has consequences.

New questions kept emerging:

• What if someone has permission to edit products but not pricing?
• What if a prompt change breaks an existing workflow?
• What if someone asks to delete 500 products?
• What if the model updates and tool selection gets worse?

I deliberately slowed down feature expansion. Reliability mattered more than capability. Every new tool increased the system's responsibility, so I needed confidence in existing workflows before adding more.

---

Impact

The biggest outcome wasn't adding AI to the platform. It was changing how employees interacted with it.

Reduced operational friction. Tasks that required navigating multiple screens could now start with a single sentence. Less time operating software, more time running the business.

Simplified onboarding. New employees didn't need to memorize the dashboard before becoming productive. They could interact using business language, not software language.

Enabled new workflows. The conversational interface made things practical that weren't before — generating SEO for an entire product category, getting natural-language sales summaries, creating product descriptions with AI, comparing competitor pricing.

Zero duplicated logic. Because the MCP layer reused the existing backend, there was no separate business logic to maintain. New AI capabilities could be added incrementally.

---

Lessons Learned

AI is only one component. Most engineering effort went into authorization, validation, testing, observability, and error handling — not the LLM integration itself.

Understand the business first. Understanding how the company actually operated was more valuable than understanding another AI framework. Once I understood the business, the technical solution became obvious.

Ship small, learn fast. The focused MVP gave real feedback much earlier than a larger build would have. The things I thought mattered most weren't always what mattered in practice.

AI engineering is software engineering. Production AI systems need the same discipline as any other software — testing, versioning, monitoring, security, and maintainability. Prompt engineering alone isn't enough.

The hardest problem is trust. Balancing flexibility with safety was harder than integrating the LLM. Users should feel like they're having a natural conversation, but every action still needs deterministic validation, authorization, and error handling behind the scenes.

---

What I'd Do Differently

The architecture was right — separating business logic from the AI interaction layer proved to be the correct decision. But I'd invest earlier in three areas:

1. Observability from day one — Capture usage analytics, tool selection patterns, and error rates from the first deployment.
2. Evaluations as infrastructure — Build the eval harness before building the second tool. Treat AI behavior like software — tested, versioned, and gated.
3. Prompt lifecycle management — Version, test, and gate prompts with the same rigor as application code.

---

The Progression

DIAGRAM

This project started as an observation about dashboard friction. It became an exercise in AI system design, production engineering, and building technology that businesses can actually trust.

---

Technology Summary