How to Turn a Google Sheet Into an Online Store (Without Code)

Most small shops already have a Google Sheet. It tracks prices, sometimes stock, sometimes supplier costs. It's the closest thing they have to an inventory system, and the people who maintain it know exactly where every column lives.

Then comes the website conversation. Someone suggests Shopify. Someone else suggests Wix. Whatever they pick, the sheet gets copied into a new admin panel — and now there are two sources of truth, and they drift, and prices end up wrong on one of them.

This post is about not doing that.

If your prices already live in a sheet, the cleanest setup is to let the sheet be the store's backend, full stop. No re-entering data. No admin panel to keep in sync. You change a price in row 12, the storefront shows the new price within the minute. Here's how it works and how to avoid the obvious pitfalls.

Why a sheet is a good catalog backend

Sheets aren't a fancy database. They're actually a much better catalog backend than a custom admin for one specific reason: your team already knows how to use one.

You don't need to train anyone. The person who's been updating prices for two years just keeps doing it. The new staff member who's never touched Shopify in their life can still type a row into a sheet. That alone solves the biggest reason small-shop “online stores” go stale: nobody but the owner can update them.

The other big wins:

• Bulk operations are trivial. Discount everything 10% for the holidays? One formula, fill down. Mark a whole category out of stock? Select column, type “oos.” Done.
• History is built in. Sheets keeps version history. You can see exactly when a price changed and who changed it.
• Multiple editors. Share the sheet with staff like any other doc. Permissions and comments are native.
• It's your data, in your Drive. If you ever leave the storefront tool you're using, the sheet stays. You own it.

What you actually need in the sheet

Three tabs. (Or two, if you don't need analytics.) The exact column names depend on which tool reads the sheet — Ordify Store Builder uses these, others differ slightly — but the shape is the same.

Tab 1: Config

One row of store-level settings. Things like:

• Store display name
• WhatsApp number (with country code, no +)
• Currency code (USD, EUR, BDT, whatever)
• Open / closed toggle
• Address (optional)
• Logo URL (optional)
• Delivery rule (optional — “pickup only,” “delivery only,” “both”)

This tab changes maybe twice a year. Set it and forget it.

Tab 2: Menu (or Products)

The actual catalog. One row per product. Columns:

• name — what the customer sees
• category — what the customer browses by
• caption — short description (one line, two max)
• image URL — link to a public image
• price — a number, no currency symbol (currency lives in Config)
• available — yes / no / oos (out of stock but still shown)

That's the minimum viable schema. Six columns, totally readable on a phone.

Tab 3: Orders (optional)

If your store tool pushes order data back to the sheet, this is where it lands. Some do, some don't. Skip if you just want to receive orders on WhatsApp.

The variant problem (and how to solve it without losing your mind)

This is where most people's “just use a sheet” plan falls apart. Real shops have variants. A latte has three sizes. A bouquet has three colors. A burger has add-ons.

The brute-force approach is to make each variant its own row — “Latte Small”, “Latte Medium”, “Latte Large”. That technically works. It also makes your menu look like a warehouse manifest, with the customer scrolling past three lattes to get to the next drink.

The clean approach is variant syntax in the product name. Something like:

Latte :: Size // Small // Medium ((+0.50)) // Large ((+1.00))

One row, one product, customer picks a size. The ((+0.50)) is a surcharge on top of the base price. The ::separates the variant group from the product name. Tools vary in the exact syntax — Ordify Store Builder's is documented in the setup guide — but the principle is universal: variants belong in the product, not as separate products.

If a tool you're considering forces you to use a separate row per variant, that's a sign it's really a generic CSV importer rather than something built for catalogs. Pass.

Images: the part that trips everyone up

You can't just paste an image into a Google Sheet cell and expect the storefront to render it. The storefront needs a URL it can fetch over the public internet.

Three reasonable places to host your images:

1. Imgur. Upload, copy the direct link, paste it. Free, fast, no account required for casual use. The downside: Imgur sometimes removes images flagged as commercial. Not the safest for a long-running store.
2. Cloudinary. Free tier is generous. Built for image hosting. URLs are stable. Slight learning curve.
3. Google Drive.Set the file to “Anyone with the link can view,” then use the export URL format. Mildly fiddly, but everything stays in Google's ecosystem.

What to avoid: hotlinking from someone else's site, hotlinking from Instagram (the URLs expire), pasting an image into the sheet directly.

Publishing the sheet

This is the step nobody documents because it's in Google's product, not yours. To connect a sheet to a storefront tool, you usually have to publish it.

In Google Sheets: File → Share → Publish to web → Entire document → CSV. Hit publish. Copy the URL.

What that does: makes the published version of the sheet readable as a CSV from any URL. The original sheet stays editable in your Drive. Only the rows you publish are exposed publicly — the rest of your Drive isn't touched. Storefront tools then poll that CSV every minute or so and re-render the store.

What “updating the store” actually looks like

Once it's wired up, here's the entire workflow for changing your menu:

1. Open the sheet on your phone.
2. Tap the cell. Change the value.
3. Wait ~60 seconds. The store updates.

That's it. No dashboard to log into. No “save and publish” button. No designer to ping. The cognitive overhead of running an online store drops to roughly the same level as updating a contacts list.

This is the whole point of using a sheet as the backend. The tool gets out of your way and lets the data live where it already lives.

When this approach doesn't work

I'm not going to pretend the sheet approach is right for everyone. It's wrong for:

• Real-time inventory. If you need stock to decrement automatically when an order is placed, a sheet polling once a minute won't cut it. You need a real database.
• Card-checkout shops. If you actually take card payments on your site, you need a tool that handles checkout, fraud, taxes, and refunds. A sheet + WhatsApp won't do that.
• 10,000-product catalogs. Sheets fall over above maybe 1000-2000 rows in practice. If you're an Amazon-style storefront, this isn't the move.

If you're none of those — and most small shops aren't — a sheet as the catalog backend is the lightest, most maintainable setup I've found.

How to actually start

The fastest path: copy our template, fill in your products, publish, paste the URL into whatever storefront tool you're using. You can have the whole thing running in under 15 minutes.

Our version is at /google-sheets-store— there's a sample sheet and a step-by-step. If you want the niche-specific version (with the right variant syntax for a café, bakery, restaurant, etc.) the templates index is the better starting point.

Either way, the meta-point is the same. Your prices already live in a sheet. Let them stay there. Let the storefront read from there. The fewer copies of the truth, the fewer ways for it to go wrong.