EmbedChat AI—also presented publicly as ConvoCommerce—is a multi-tenant ecommerce assistant platform I built end to end as the sole developer over approximately one month. It combines a merchant dashboard, content and catalog ingestion, agent workflows, background jobs, and an embeddable storefront widget. I delivered and deployed the product for internal use.
The Brief
The product brief was to create one configurable assistant platform that could work across Shopify, WooCommerce, custom ecommerce stores, and general websites. A merchant needed to be able to connect store knowledge, configure an assistant, place a lightweight widget on the storefront, and let the assistant retrieve information or invoke approved commerce tools during a conversation.
That sounds like a chat interface. The harder problem was everything behind it: separating tenant data, keeping ingestion work away from live requests, routing different store capabilities, maintaining conversation context, and making one backend serve both an administration product and a customer-facing widget.
The dashboard was the control plane: agent configuration, connected knowledge, store-specific behavior, conversations, and widget settings lived in one product surface.
What I Owned
I was the only developer on the project and handled the complete implementation:
- product and application architecture;
- responsive Next.js dashboard and embeddable chat widget;
- FastAPI services and agent orchestration;
- MongoDB tenant, assistant, conversation, and configuration models;
- Redis-backed caching, rate controls, and background-work coordination;
- Celery workers for ingestion and other long-running jobs;
- retrieval, memory, routing, product-search, and cart-tool workflows;
- Shopify, WooCommerce, custom-store, and general-site integration paths;
- deployment and the internal-use release.
The one-month constraint forced clear boundaries. I could not treat every store platform as a separate product, and I could not let expensive ingestion or model work block the interactive path.
How the System Was Split
1. Tenant and configuration layer
Each business needed isolated configuration, connected sources, agent behavior, conversations, and widget settings. I designed tenant context as an application boundary rather than a dashboard filter, so requests and background jobs could resolve the correct business before reading or changing data.
2. Content and catalog ingestion
Store content and product information needed processing before it could support retrieval. I moved this work into Celery jobs coordinated through Redis instead of running it inside a user request. That kept the dashboard responsive and gave long-running work a separate failure and retry path.
Connected material was prepared outside the live conversation path, then made available to the tenant’s assistant.
3. Agent routing, memory, and tools
The runtime had to decide whether a request needed retrieved knowledge, product search, cart behavior, or a normal conversational response. I used an agent layer with platform-specific tools rather than pretending every store exposed identical actions. Conversation memory supplied continuity, while tenant and platform context constrained which sources and tools were available.
4. Dashboard and storefront surfaces
The administration dashboard and storefront widget shared a system but served different jobs. The dashboard exposed configuration and operational context; the widget had to remain compact, embeddable, and focused on the shopper conversation. Keeping those interfaces separate prevented merchant controls from leaking into the customer experience.
The widget was designed as a small storefront surface backed by the same tenant-aware conversation system.
Decisions That Mattered
Background work instead of request-time ingestion
Catalog and content processing can be slow or fail for reasons unrelated to the active browser request. Celery and Redis added operational complexity, but they kept that work out of the interactive path and made job state easier to reason about.
Platform adapters instead of one universal store tool
Shopify, WooCommerce, and custom stores do not expose the same data or actions. I kept platform behavior modular so product search, cart operations, and synchronization could vary without turning the core conversation flow into a chain of platform checks.
Multi-tenancy as a backend concern
A tenant selector in the UI is not data isolation. Tenant context had to follow API requests, stored records, jobs, retrieval, memory, and agent tools. Designing that boundary early was more work, but retrofitting it after multiple stores were connected would have been riskier.
A configurable system, not a scripted demo
The dashboard allowed assistants, sources, store behavior, and widgets to be configured rather than hard-coded for one storefront. That made the build larger than a single chatbot, but it was necessary for the product brief.
Delivery
I completed the end-to-end build in approximately one month and deployed it for an internal group. The product included the merchant dashboard, embeddable widget, tenant-aware backend, ingestion workers, retrieval and memory workflows, platform routing, and commerce tools described above.
The screenshots show the delivered product surfaces, and the ConvoCommerce link reflects the product’s public identity.
Operational Priorities at Scale
A broader rollout of a system like EmbedChat should prioritize:
- representative evaluation cases for retrieval, tool selection, and unsupported questions;
- monitoring for answer grounding, tool failures, latency, and escalation behavior;
- load testing across the widget, APIs, queues, and ingestion jobs;
- dedicated authorization and abuse cases around tenant data and commerce actions;
- operational alerts and a clear human handoff;
- continuous validation of store adapters as third-party APIs and permissions change.
What This Project Taught Me
The interface is the most visible part of an ecommerce assistant, but it is not the product’s hardest boundary. The difficult work is deciding which tenant context, source, memory, platform capability, and tool can participate in each request—and what should happen when one of them is missing or fails.
EmbedChat changed how I approach conversational products. I now start with the operational boundaries and evaluation cases before polishing the assistant’s tone. A fluent answer is useful only after the system has earned the right context and the right action.
