How to build a catalogue with WhatsApp ordering
You sell through Instagram and WhatsApp, and it works. The problem is not the selling, it is everything around it: answering "how much is it?" forty times a day, digging through the chat for what somebody ordered, and finding out while packing that the item is gone.
This guide is about building the catalogue that answers those questions on its own, without taking WhatsApp out of the loop.
What an ordering catalogue has to have
Five things. Most solutions deliver three.
- A catalogue you update yourself, without asking anyone and without remaking an image;
- Prices and availability that do not lie. An item that ran out disappears or shows as sold out, rather than becoming an awkward conversation later;
- A cart. It sounds like a detail and is not: a one-item order is a conversation, a five-item order with no cart is a typo waiting to happen;
- The order landing somewhere that is not the chat. This is the point that decides everything, and the next section explains why;
- History per customer, which is what turns a buyer into someone who comes back.
Why the order cannot live in the chat
While an order exists only as a message, it has a message's problems: it gets buried under other messages, it cannot be sorted, you cannot count how many came in today, and it is gone for good when you change phones or when a second person starts answering.
WhatsApp is excellent as a notification channel and terrible as a database. The catalogue that works is the one that records the order somewhere and uses WhatsApp to announce it, not the other way round.
The four paths, and where each one breaks
| Path | Costs | Breaks when |
|---|---|---|
| Instagram and WhatsApp by hand | nothing | you pass a handful of orders a day, or hire a second person |
| WhatsApp Business catalogue | nothing | you need a cart, delivery, size variants or stock |
| A ready-made store or marketplace | subscription and commission | you want the customer in your own base, not the marketplace's |
| Your own app or site | subscription | never, which is why it is the most work to start |
By hand. It is the right answer at the beginning and it is honest to say so. The sign that it is time to move is not volume, it is you starting to make mistakes: a forgotten order, a stale price, an item sold twice.
The WhatsApp Business catalogue. It handles the shop window well and stops exactly where selling starts to get serious: no cart, no delivery calculation, no idea an item ran out, and nothing kept about who bought.
A ready-made store or marketplace. It arrives finished and charges for that twice, in the subscription and in the commission. The second one is the one that hurts: beyond the percentage, the customer belongs to the platform, and starting again elsewhere means starting the base again.
Your own app or site. More work to start and the only one with no ceiling built in. It used to be expensive; that is what changed in the last two years.
How to build yours
What follows is the shape that works, whatever tool you use to build it.
The data
Three collections, and no more than that in a first version:
- Product: name, description, photo, price, available (yes or no), category. If you sell variants, a list of options with their own prices;
- Order: customer, items, total, delivery method, address when there is one, status (received, preparing, out, delivered);
- Customer: name, phone, address. It is born from the first order; nobody has to fill in a sign-up form before buying.
The common mistake here is storing the order as a single block of text. If the items are not a list, you will never be able to answer "which product sells most".
The flow
Shop window, item, cart, delivery details, confirmation. Five screens, and the fourth is where most sales are lost: ask for the minimum. Name, phone, and an address when it is a delivery. Every extra field is another chance to give up.
Where WhatsApp comes in, and it is two different places
This is the distinction almost every tutorial blurs.
The link, which needs nothing. On confirmation, the app opens the chat with the order already written. It is a wa.me link with the message in the address, it works on any phone, and it needs no account, no API and no approval. For most businesses this is enough, and it is what you should do first.
The API, when you want the system to speak on its own. An automatic confirmation, an "out for delivery" notice, a booking reminder: for those the app has to send a message without anyone pressing anything, and that is where the WhatsApp Cloud API comes in, on your own Meta account. It is more work to connect and it is what turns support into a process.
On Fabapp the second path is an integration you connect with your own Meta account, after which the app sends confirmations and reminders by itself. The first is just a button, and needs no integration at all. The integrations and the rest of what the platform does are on features.
And payment
Taking the order and then negotiating payment by message is half the job. With a payment method connected, the customer pays at confirmation and the conversation starts with that already settled.
This is where the choice of tool matters if you sell outside the United States: most platforms assume Stripe, which is not the path for anyone who needs local rails. Check which gateways the tool accepts before you start, not after the catalogue is entered.
The prompt, to start this afternoon
If you are building with AI, the result depends far more on the request than on the tool. This one works:
Build a product catalogue with ordering. I need: a shop window with photo, name, price and category; a product page with a description and an add-to-cart button; a cart with quantity and total; a checkout screen asking for name, phone and address, with pickup or delivery; and, on confirmation, open WhatsApp with the order already written. I also need an admin area where I add products, mark an item as unavailable, and see orders by status: received, preparing, out for delivery, delivered.
Two things make that prompt work, and they hold for any request: it says who uses each screen (the customer and you) and it says what happens on confirmation. A vague request returns a vague app.
Once the first version stands up, ask for changes one at a time. Delivery fees by area, coupons, opening hours, size variants: each is one request, and that way you check one thing at a time instead of receiving twenty screens with no idea where to start.
What to check before you share it
Three tests, in this order, and nobody does the third:
- Place an order end to end, on a phone. Not on a computer: your customers will buy on a phone;
- Check the admin area to see the order arrived. The success message on screen is exactly what a broken form also shows;
- Mark an item unavailable and try to buy it. It is the test that catches the problem that annoys customers most.
Once it is running
The catalogue is the beginning. In the order in which it usually pays off:
Payment at confirmation, which cuts both the conversation and the drop-off. Customer history, which is what makes "the usual?" possible. Coupons and a loyalty scheme, once people are already coming back. And the app in the stores, when the people coming back are enough to justify an icon on their phone.
On Fabapp the Free plan does not ask for a card, and an ordering catalogue is exactly the size of app worth standing up and testing before deciding anything.