Building SelloHQ: Letting an AI Agent Draft Orders from WhatsApp, SMS & Voice

I'm currently building SelloHQ (sellohq.com), a business management platform that lets a business owner run their whole operation — catalog, inventory, and orders — from one dashboard. The idea came from watching how small businesses across Africa actually sell: not through a storefront, but through a flood of WhatsApp messages, SMS, and phone calls that someone has to manually turn into an order, a stock deduction, and eventually a payment. SelloHQ's bet is that this conversion — conversation to order — is exactly the kind of repetitive, structured task an AI agent should be doing, not a person.

The core loop

A business connects a WhatsApp Business number and/or an SMS or voice line to their SelloHQ account. From that point on, every inbound message is a potential order. An AI agent sits on that channel, reads the conversation, matches it against the business's actual product catalog, and drafts a structured order directly onto the owner's dashboard — items, quantities, customer details — without the owner touching a spreadsheet or a notebook. Once the order is confirmed, SelloHQ generates a Paystack virtual account for that specific order, and when the webhook fires, the payment is marked paid automatically. The owner's job shrinks to reviewing what the agent drafted and fulfilling it.

Why multi-tenancy shapes almost every decision

SelloHQ is multi-tenant from the schema up: every row that belongs to a business — products, inventory movements, customers, orders, channel connections, conversations — carries a businessId, and the service layer scopes every query to the authenticated tenant. That sounds obvious written down, but it has real consequences once an AI agent is in the loop: the agent's tool calls (look up a product, check stock, create an order) have to be scoped exactly the same way a human request would be, or you risk one business's agent drafting orders against another business's catalog. Tenant isolation isn't just a database concern here, it's a constraint on how the agent's tools are designed.

Modeling a conversation as a first-class thing

Orders carry a source — DASHBOARD, WHATSAPP, SMS, or VOICE — so the business owner can always see where a sale actually came from, and the underlying Conversation and Message models keep the full channel thread the order was drafted from. That thread does double duty: it's the audit trail an owner can check if an order looks wrong, and it's the session/context store the agent reads from on every new inbound message so it isn't reasoning from scratch each time. That context lives in Redis, separate from Postgres, which is the source of truth for the business data itself — a split that keeps the fast-changing, ephemeral conversation state out of the durable domain tables.

Business        — tenant root (currency, country, Paystack config)
User            — owner / admin / staff per business
Product         + InventoryMovement — catalog & stock ledger
Customer
Order           + OrderItem — source: DASHBOARD | WHATSAPP | SMS | VOICE
Payment         — Paystack virtual account + status
ChannelConnection — WhatsApp / SMS / Voice config per business
Conversation    + Message — channel threads the AI agent reads/writes

Payments as a natural extension of the conversation

The payment model follows the same philosophy as the ordering model: don't make the customer do anything unfamiliar. Instead of pushing a customer to a checkout page, SelloHQ generates a dedicated Paystack virtual account per order — the customer just transfers to it the way they'd pay anyone else. When paymentEnabled is on for a business, the Paystack webhook flips the order's payment status to paid with no manual reconciliation. It's a small design choice, but it matters: everything in the flow, from placing the order over WhatsApp to paying for it, stays inside channels the customer already trusts.

The stack

The dashboard is Next.js 16 (App Router, Turbopack) with React 19 and Tailwind CSS 4, using brand design tokens rather than default utility colors so the product has a consistent visual identity from day one. The API is NestJS 11 on TypeScript 5.7, with Prisma 6 over PostgreSQL 17 as the domain source of truth, Redis for session and conversation context, and MinIO/S3-compatible object storage for product and order images — the same API surface local Docker MinIO exposes in dev is what production talks to, so there's no storage-layer surprise between environments. A React Native mobile app rounds out the picture for owners who want to manage orders on the move. Swagger docs, Helmet, global validation, and rate limiting are baked into the API from the start rather than bolted on later.

What I've learned so far

The most interesting engineering problem in SelloHQ hasn't been the AI integration itself — it's been treating the conversation as domain data with the same rigor as an order or a product, instead of as a transient log line. Once a thread is a real, tenant-scoped, queryable entity, both the agent and the human owner can reason about it, audit it, and recover from it when something goes wrong. That's the piece I'd tell anyone building an AI-agent-backed product to get right early — it's much harder to retrofit than to design in from the schema up.

SelloHQ is still pre-launch at sellohq.com. If you're building something in the AI-agent-meets-commerce space, or run a business that lives in WhatsApp and SMS threads, I'd love to compare notes — reach out through the contact section of this site.