S-ASHWATH
5 DOMAINS LIVE
// DOMAIN_01 / E-COMMERCE / AI SYSTEMS EXPERIMENT

What does it take to build an Amazon?

I've spent nearly two decades leading enterprise technology programs — so I know how many specialists a marketplace is supposed to require. I wanted to test that. So as an AI experiment, I built a working B2B marketplace system end to end: buyer and vendor AI, payments, logistics, and a self-running content engine — all functioning. It took 17+ distinct roles, every one my own.

01The Question

Everyone treats building a marketplace as a job for a company — engineers, ops, designers, marketers, each in their lane. Is that still true in the age of AI, or just how it's always been done? The only honest way to find out was to build the whole thing myself and count the hats. The answer turned out to be seventeen.

02What It Took

Every role a marketplace normally hires a person for — here's the same list, done solo. None from courses; each learned because the build wouldn't ship without it.

Storefront
Frontend & PWA DeveloperUX / Catalog Design
Catalog
Data EngineerCatalog & MerchandisingQA & Data Quality
Infrastructure
Server / DevOpsDatabase AdministratorCDN, Security & Performance
Intelligence
AI Agent BuilderPrompt EngineerAI Application DeveloperImage-Generation Engineer
Commerce
Payments IntegrationLogistics & FulfilmentMessaging & Notifications
Growth
SEO StrategistProgrammatic-Content EngineerBrand & Marketing
Business
FounderVendor OperationsProduct ManagerTechnical Writer

// 17+ hats · 1 operator · 1 question, answered

03The Systems

The list is easy to write. Here's the proof — seven systems behind it, each built and validated.

SYS_01

The Autonomous Content Engine

An agent that processes the catalog in batches, generates regional-language search content with an LLM, and applies it through a staging → apply → rollback workflow with backups and per-batch locks. Runs on a nightly schedule, unattended. ~9,300 products optimized to 99% coverage.

STACK: Python · Gemini Flash · MySQL · cron · staging+rollback
SYS_02

The Conversational Assistant

A storefront AI assistant answering buyer questions in plain language. The interesting part was the platform fighting me — the commerce engine strips JavaScript from page content, so I routed it through a server-level injection layer and standalone endpoints to make it work at all. The constraint taught me more than the feature did.

STACK: JavaScript · Claude · server-side injection · PHP endpoints
SYS_03

The Buyer Intelligence Tool

A location-aware recommendation engine: a buyer enters their area, an LLM-backed system surfaces the parts most relevant to that regional market. Turns a sprawling catalog from overwhelming into personal.

STACK: Claude · location lookup · rule layer
SYS_04

The Vendor Intelligence Dashboard

The one I'm proudest of visually — a demand-intelligence dashboard styled like a financial terminal, live heatmaps and hot/dead-stock lists across 15 regional markets. Two layers: instant rule-based data on every interaction, and a frontier LLM generating a personalized demand report on request. Built to turn browsers into registered vendors.

STACK: JavaScript · Claude (inference) · rule engine · real-time UI
SYS_05

The Product Imagery Studio

A bulk image-generation studio for a problem every marketplace has: vendors supply inconsistent, low-quality photos, and hand-editing thousands of SKUs alone is impossible. Pick a product, it generates a full set of standardized marketing shots in one batch and attaches them automatically. Best part: it runs the same prompt through two competing image models side by side, with live cost tracking — pick the better, cheaper result per job. Over a thousand SKUs styled this way.

STACK: Python · Gemini Flash Image + GPT Image (A/B) · batch pipeline · cost tracking
SYS_06

The Commerce Integration Layer

The plumbing that makes a marketplace real, not a demo: payments, shipping and logistics, transactional email, automated order and payment messaging, and government-API-backed vendor verification for onboarding. Half a dozen third-party systems, wired to behave as one.

STACK: Payments · logistics · SMTP · messaging API · gov-verification APIs
SYS_07

The Infrastructure & The Discipline

Linux administration, a CDN/security/performance layer, automated nightly backups — and the part that matters: a written set of operational safety rules. Diagnose with data before acting. Back up affected rows before any destructive change. Make every batch operation safely re-runnable. Anyone can build a system that works once; making one that fails safely is the engineering.

STACK: Linux · CDN/WAF · automated backups · ops runbook
9,300
Products auto-optimized
200+
Self-generating pages
7
AI / automation systems
1
Person · end to end
04Architecture

High-level system architecture — frontend to infrastructure, end to end.

L1 Frontend
PWA storefront + AI widgets
JavaScript · Progressive Web App · responsive UI · embedded assistant & dashboards
L2 Application
Multi-vendor e-commerce platform
PHP core · custom API endpoints · server-side injection layer
L3 Intelligence
Multi-LLM orchestration
Claude · Gemini Flash · GPT Image · agent loops · prompt layer · evals · model A/B routing
L4 Data
Catalog & storage
MySQL · large multi-vendor catalog · nightly automated backups
L5 Infrastructure
Server & edge
Linux server · CDN / WAF · cron automation · monitoring
L6 Integrations
Third-party commerce systems
Payments · logistics · transactional email · messaging API · government verification APIs
05What Broke

The lessons that stuck came from the incidents, not the launches. A run of pages vanished — the lazy move is a blind rollback, but diagnosing first proved the cause predated my work and let me recover cleanly instead of compounding it. A disk-capacity failure silently corrupted tens of thousands of records; fixing that taught me the failure modes that matter are never the ones the demo shows you. Those incidents are why the safety rules exist. The rules are the real product.

One experiment done. Three domains in the lab.

This marketplace was an AI experiment — evidence that one person, with the right AI leverage, can do what used to take a team. Fin-tech, insurance, and travel-tech are next. If you're putting AI into real operations, I'm happy to compare notes.

← Back to all domains