Choosing between an online shop vs catalogue site comes down to one question: does the buyer pay on your site, or do they talk to you first? A shop takes payment and tracks stock. A catalogue presents what you sell, then routes the enquiry to a form, a phone call or a messaging app.
Key Takeaways
A shop and a catalogue solve different problems, and the wrong pick shows up later as abandoned carts or an inbox nobody answers. Judge both by what you will operate every week after launch: payments and stock on one side, content and enquiry follow-up on the other.
- An online shop is worth building only when buyers will pay without a conversation. Otherwise checkout adds friction instead of removing it.
- A catalogue site wins when price depends on scope, measurement, quantity or a site visit.
- Taking payments pulls in refunds, chargebacks, tax rules, stock reconciliation and card-data scope that never fully go away.
- Enquiry-based sites live or die on response time. A form that lands in an unread inbox is worse than no form at all.
- Most businesses here end up hybrid: a catalogue with a quote request, plus a small shop for the few fixed-price items.
- The build is the cheap part. Content, hosting, payment fees and someone to answer buyers are the recurring cost.
- Pick the option your team can run on a bad week, not the one that looks best in a demo.
What actually separates an online shop from a catalogue site?
An online shop completes a transaction. The visitor picks a variant, pays, and the system records an order, reduces stock and issues a receipt. A catalogue site stops before payment — it presents products or services in enough detail to start a conversation, then hands the visitor to an enquiry form, a phone number or a messaging app.
That one line decides almost everything downstream. A shop needs a cart, a payment gateway, order states and a fulfilment process. A catalogue needs good content, a fast enquiry path and someone who replies. If you have ever compared a WordPress build against a custom website, the reasoning is similar: the tool follows the job, not the other way round.
Why does the choice matter in production?
The choice decides what you operate after launch. A shop carries payment credentials, order state, refunds, stock reconciliation and tax rules; a catalogue carries content, enquiries and follow-up. Build the shop only when you cannot sell without it, because the operational load never really disappears.
Here is the part that catches people out. A catalogue with ten products is a content problem. A shop with ten products is a systems problem — sessions, inventory, emails that must actually send, and a payment provider that will hold your money if a dispute goes unanswered. The blast radius of a broken shop is revenue; the blast radius of a broken catalogue is a quiet week of fewer calls.
When do you actually need an online shop?
You need a shop when buyers already know what they want and will pay without speaking to you. Standard sizes, fixed prices, repeat purchases and shipping you can describe in a table all sell themselves. If every order needs a quote, a measurement or a site visit, checkout adds friction.
Practical signals that a shop will pay for itself: more than a handful of orders a day, the same products ordered again and again, buyers outside business hours, and a team already comfortable processing payments digitally. If two of those are missing, start with a catalogue and add checkout once the demand is proven.
When is a catalogue site the right answer?
A catalogue wins when price depends on scope, when the buyer wants reassurance before committing, or when the order value makes a conversation cheaper than a checkout. Law firms, trekking operators, fabricators, clinics and B2B suppliers all fit here. The site's job is to qualify the enquiry, not to close it.
The risk shifts too. With a shop, your bottleneck is the payment flow. With a catalogue, it is response time — the first business to reply usually wins the job. Track how long it takes to answer an enquiry, and if the honest answer is "a day or two", fix that before you spend anything on design.
How does each one work under the hood?
A shop runs on a cart session, a product catalogue with variants, a payment gateway that authorises and captures, and an order record that survives the browser closing. A catalogue runs on structured content, a form that lands in a mailbox or CRM, and a tracking sheet someone actually reads. Both need hosting that stays up.
For a shop, the order record is the important artefact. Sessions expire, browsers close and cards get declined — the order row is what lets you reconcile money against stock at month end. For a catalogue, the important artefact is the enquiry record: name, contact, what they asked for, and who replied. Search engines also read your product data, so mark it up properly:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "PRODUCT_NAME",
"sku": "SKU_CODE",
"offers": {
"@type": "Offer",
"availability": "https://schema.org/InStock"
}
}
</script>If you build on WordPress, the WordPress plugin handbook is the honest place to check what a plugin will and will not do before you install it on a live store.
How do you decide, step by step?
Work through these in order and the answer usually picks itself. The point is to decide on evidence from your own order book, not on what a competitor's site looks like.
- Pull your last fifty orders or enquiries and mark how many closed without a phone call or a meeting.
- Write down whether your price is fixed at the moment of enquiry, or quoted after a conversation.
- Count who updates the content today and how often — daily stock changes need a shop, quarterly updates do not.
- List the payment methods your buyers actually use and check whether a gateway supports them for your business type.
- Estimate order volume and whether stock counts must be accurate to the unit.
- Name the person who will handle refunds, failed payments and delivery questions, and get their agreement.
- Choose the smaller build that answers the first six points, then set a date to revisit the decision.
Configuration that decides whether it holds up
Five settings cause most of the pain: tax and shipping rules, stock decrement timing, guest checkout, email deliverability, and the gateway's capture mode. Get these wrong and you will spend launch week apologising rather than selling. Write them down before development starts, because changing them later means touching live orders.
Stock decrement timing is the classic example. Reduce stock at payment, and two buyers can pay for the last item within seconds of each other. Reserve at cart, and abandoned carts lock inventory. Either way, you need a rule for oversells and a person who owns it. Email matters just as much: order confirmations that land in spam look like fraud to a first-time buyer, so configure SPF, DKIM and DMARC on your sending domain and test with real mailboxes.
How do you verify the buying path works?
Run a real transaction end to end before launch, using a live card for a small amount and refunding it afterwards. Confirm the order appears in your admin, stock moves, the confirmation email arrives, the invoice numbers correctly and the refund posts back to the card. Then repeat on a phone.
For a catalogue, verification is simpler but no less important. Submit the enquiry form from a mobile network, confirm it reaches the right inbox and not a spam folder, check that the auto-reply sets expectations, and time how long a human takes to respond. Test the WhatsApp link on a device that does not have your business number saved.
What breaks in production, and how do you debug it?
Most shop failures are payment-related: declined cards with vague messages, webhooks that never arrive, and orders marked paid while the gateway says otherwise. Check the gateway dashboard first, then your webhook log, then the order record. In practice the gateway is right and the site is wrong about 90% of the time.
Other common ones: stock drifting out of sync after a manual edit, shipping charges that ignore remote postcodes, and discount codes that stack when they should not. Catalogue sites fail differently — forms silently stop sending because an SMTP password rotated, or a plugin update broke the mailer. Either way, set up an alert that fires when a test enquiry or test order does not complete, rather than discovering it from an angry customer.
What drives the cost of each option?
Cost comes from what you operate, not from the size of the site. Shops carry payment gateway fees, higher hosting needs, plugin or licence renewals, and the engineer time to keep checkout working. Catalogues cost less to run but need more content work up front, plus discipline on enquiry follow-up every single week.
Cloud and hosting bills follow the same logic: storage class, egress, database size and whether you need a staging copy alongside production. Payment providers charge per transaction and per dispute, and those numbers move. Confirm current rates on the vendor's own pricing page or calculator before you commit, and ask us for a quote on the build side rather than guessing.
Security: what changes when you take payments?
Taking card payments widens your responsibility. Card-data scope applies to anything that touches a card number, so use a hosted checkout or tokenised fields and let the provider handle the sensitive data. Then add TLS everywhere, keep admin accounts separate, enable two-factor authentication and patch the platform on a schedule.
Catalogue sites are not exempt. Enquiry forms are the most common spam and injection target on small business sites, and an exposed admin panel with a weak password is how most WordPress sites get cleaned out. Rate-limit the form, validate on the server, keep backups you have actually restored once, and store credentials in a password manager rather than a shared spreadsheet.
Common mistakes we see
The same handful of errors turn up again and again. Most of them are decisions, not bugs, and they are far cheaper to fix before launch than after.
- Building checkout for products that always need a quote, then wondering why carts sit abandoned.
- Launching a catalogue with no owner for the inbox — enquiries go unanswered for days.
- Skipping guest checkout, which quietly removes a large share of first-time buyers.
- Never testing the refund path, then discovering it during your first dispute.
- Treating stock counts as a website problem when they are really a warehouse process.
- Choosing a theme or plugin for looks, then discovering it cannot handle variants or tax.
A realistic scenario
A Kathmandu furniture workshop sells about forty pieces a month, each priced after a conversation about size, fabric and delivery. They built a shop first because a competitor had one. Six months in, most orders still arrived by phone, and the cart had processed a handful of small accessory sales. Nothing was broken — the model was wrong.
They kept the shop for accessories and moved the furniture onto a catalogue with a quote request, photographs, dimensions and a clear delivery note. Enquiries went to a shared inbox with a one-working-day reply target. Order value went up because the awkward size questions got answered before the first call. That hybrid shape is what we usually recommend, and it is the one our team can help you scope honestly.
Alternatives compared
Four shapes cover almost every small business case. The differences are mostly about who does the closing, and what you have to keep running afterwards.
| Option | Best for | What you operate | Main risk |
|---|---|---|---|
| Online shop | Fixed prices, standard items, repeat buyers | Cart, gateway, order states, stock, refunds | Payment and stock failures hit revenue directly |
| Catalogue with enquiry form | Quoted work, custom sizes, high order values | Content, inbox, follow-up process | Slow replies lose deals quietly |
| Catalogue plus phone or WhatsApp | Buyers who want to talk before committing | Content, messaging, one person on duty | No record of what was promised |
| Hybrid shop and quote request | Mixed catalogue of accessories and made-to-order goods | Both of the above, lightly | Two processes to keep in sync |
| Marketplace listing | Fast start with no site to run | Someone else's platform and rules | You do not own the customer or the data |
If you are weighing a platform build against something you own outright, our comparison of custom software and off-the-shelf tools covers the same trade-offs. You can also see how we have approached similar builds in our portfolio of client work.
In short
Build a shop when buyers will pay without a conversation, and a catalogue when they will not. Judge both by what you must operate every week, not by what the demo looks like. If you are unsure, start with the catalogue plus a quote request, watch where the enquiries actually go, and let real demand tell you when to add checkout.
People also search for
- Custom software vs off-the-shelf for an online store
- WordPress vs a custom website for selling online
- What goes into a web development quote
- Connecting a website to payments and inventory systems
- How long it takes to build an online shop
- Who owns the website code once it is built
- Should you rebuild your website or extend it?
- The website handover checklist
Not sure which shape fits your order book? Our team can help you look at how you actually sell today, then write up a plan covering the build, the hosting and who answers the enquiries — see our web development services, check the questions we get asked most, or contact us and we will tell you plainly if a catalogue is all you need.
0 comments
Be the first to share your thoughts.
Leave a comment
Replying to — cancel