AnySeller is a commerce system connecting buyers, sellers and drivers through WhatsApp. Behind the conversation are a marketplace catalogue, search, carts, payment integrations, preparation rules, delivery dispatch, cash reconciliation and an operations dashboard.
I have worked across that system: translating product requirements into workflows, connecting external services, modelling how orders move, investigating failures and operating what we build. It has pushed me beyond making an API call succeed into understanding what a business needs to happen afterwards.
My contribution
My contribution spans the WhatsApp commerce and last-mile integration layer: architecture, workflow behaviour, Python services, database state, payment and fulfilment integrations, operational visibility and deployment decisions.
The existing WooCommerce marketplace is an integrated dependency. I am not claiming to have created every platform or provider underneath AnySeller. The work is making those components behave as a coherent product and collaborating around the business rules that connect them.
Implementation has been heavily AI-assisted, including coding, debugging and documentation. I remain responsible for understanding the design, reviewing changes, deciding what reaches production and investigating whether the behaviour matches the requirement.
The tools and how they connect
WhatsApp through Zernio. Zernio provides the messaging API, inbound webhooks, interactive messages, templates and WhatsApp Flows. Incoming messages enter the workflow layer; replies go back through the provider. This integration uses Zernio rather than calling Meta’s Graph API directly.
n8n for orchestration. Workflows interpret incoming events and coordinate buyer, seller and driver journeys. They connect conversational actions to backend operations, dispatch and notifications. The challenge is keeping routing understandable as more roles and purchase paths share one entry point.
Python and FastAPI for the application layer. The operations service exposes internal APIs and the administrative dashboard. It connects checkout, payments, routing and fulfilment. HTTPX handles external HTTP calls, asyncpg connects to PostgreSQL, and Jinja2 renders the operations interface.
PostgreSQL for durable state. Carts, purchases, delivery records, contacts and messaging attempts need to survive beyond a single workflow execution. Database records let the workflow layer and operations dashboard work from shared state. pgvector supports semantic catalogue search alongside keyword matching; catalogue embeddings are requested through Purple Guard.
WooCommerce and Dokan for marketplace integration. Products, variations and sellers are synchronised into the local catalogue. The integration creates WooCommerce orders and preserves the selected variation and its price. Catalogue freshness matters: search results must reflect what sellers can actually offer, not just what was imported once.
Ozow and TradeSafe for distinct payment paths. Ozow handles EFT payments. TradeSafe provides the card-based buyer-protection escrow path. Cash on delivery and payment at the seller have their own operational rules. These methods share parts of fulfilment, but cannot share assumptions about when money is available or who holds it.
Google Maps for location and road distance. The implemented adapter uses Geocoding and Distance Matrix, with navigation links for drivers. The maps layer separates provider access from delivery logic. Alternative routing providers and continuous driver tracking are possible future work, not capabilities I am presenting as delivered.
Docker, Caddy and Grafana for operation. The service is self-hosted with containerised deployment and a reverse proxy. Grafana reads business records and n8n execution data to show operational queues and workflow health. That gives me a way to investigate the journey beyond the chat window.
Following one order through the system
A buyer asks for products in WhatsApp. The incoming event is parsed and routed, catalogue matching finds candidates, and the buyer selects the actual product, variation and quantity.
Those selections become cart state. Delivery or collection changes what information is required. A delivery needs a usable pickup location, destination and quote; the order total and payment choice then determine the next steps.
For an online payment, a browser return or a received callback is not enough to declare success. Provider verification and local order state have to agree before fulfilment proceeds. The TradeSafe integration also checks provider state directly rather than depending only on callbacks.
Payment does not mean an item is ready. Seller preparation and the buyer’s chosen timing are separate conditions. Cash on delivery adds another sequence: confirm availability, collect buyer cash, pay the seller, wait for preparation, collect the product and complete delivery. Seller and buyer handovers use distinct verification steps.
The operations view has to explain where an order is waiting and what someone can do next. A conversation, a payment and a delivery are related records with different lifecycles.
The decisions that made this engineering work
Keep business state outside the conversation. A customer can change their mind, tap an old button or send another message while work is in progress. I need to distinguish their latest intent from an existing order or payment that must be preserved.
Treat retries as a correctness problem. A provider timeout does not tell me whether a message was accepted. The shared outbound transport records attempt identities, coordinates recipient pacing and distinguishes retryable failures from uncertain outcomes. Blindly replaying a workflow can duplicate an action even when the original user only tried once.
Separate cash custody from earnings. A driver can be holding money for the platform while the platform owes them earnings. Modelling those amounts separately makes settlement meaningful. A single generic balance concealed the business relationship.
Use intelligence where it helps, with explicit selection where it matters. Semantic search can help someone find a product without knowing the exact catalogue wording. It must not invent stock, choose an ambiguous variation or silently change the cart. The buyer still needs clear choices.
What I have learned
Integration work is largely about reconciling different meanings of success. The messaging provider accepted a request; the buyer may not have received a useful reply. The payment callback arrived; the money may not be cleared. The order exists; the seller may not be ready.
I have also learned to measure the experience at the right boundary. Workflow execution time is useful, but it is not the same as the time until a person sees the product images and selection list on their phone.
And operational data is part of product quality. Missing seller information or poorly classified catalogue items cannot always be repaired with more application logic. Sometimes the right engineering decision is to make the missing information visible and improve the process that supplies it.
What operates, and what still needs work
The September 2026 documentation records deployed commerce components, connected payment paths and real messaging activity. That is meaningful progress, but it is not proof of a completed, reliable marketplace at scale.
The latest interaction audit still identifies search and intent-routing errors, messaging contention and delivery-processing gaps. Some repairs are prepared rather than deployed. Controlled end-to-end acceptance, recovery exercises and pilot sign-off remain work to complete. I want the site to show that stage honestly.
The scaling challenge I want next
I want to experience what happens when more people depend on the system at the same time: more conversations, concurrent orders, provider limits, larger catalogues and more operational exceptions.
My proposed sequence is to earn that complexity gradually:
- Prove the complete journey. Resolve the known failures, exercise real-device buyer–seller–driver journeys with agreed participants, reconcile payments and demonstrate recovery before expanding the pilot.
- Measure the user’s wait. Instrument receipt, routing, first reply, image delivery and selection-list delivery separately. Track queue age, uncertain attempts, database contention and provider errors alongside successful orders.
- Make outbound work durable. The current shared transport has an attempt ledger and pacing, but callers still wait synchronously. A durable per-recipient background queue would need ordering, bounded retries, backpressure and a controlled way to resolve uncertain sends.
- Separate responsibilities where the evidence supports it. Smaller workflow components and clearer checkout, payment and fulfilment boundaries should make change safer. Adding workers or replicas also requires checking shared locks and state; more processes alone do not establish correctness.
- Increase volume within operational capacity. Seller readiness, driver availability, support and reconciliation must grow with traffic. I want each increase to have an explicit observation period and a practical way to pause new work.
These are the challenges I want to be stretched by. The next achievement is not simply accepting more requests. It is understanding which assumptions stop holding as the system grows, and improving it without losing track of customers, money or responsibility.
What I would bring to a team
This work is where product thinking, backend integration and infrastructure meet for me. I can follow a requirement from the person using it through APIs, workflows, database state and operational consequences—and work with others to decide where the design needs to change.
I would bring that experience to a team building integrations, automation or products with real operational dependencies. I also want to work alongside people with deeper experience of scale, learn from their decisions and take responsibility for an increasingly demanding system.
About this account
Based on my experience and dated project documentation. The private source material is not reproduced here. Results describe the period in the story; they are not a claim about today’s runtime state.