← All postsComparison

A buyer's checklist for WooCommerce app builders

By · Published September 26, 2026 · 4 min read

A buyer's checklist for WooCommerce app builders
Photo: Zeleboba / Pexels

Vendor comparison pages — including ours — are written by people with an interest in the outcome. A checklist is different: it produces answers from the vendors, in writing, which you can then compare yourself.

Copy these into an email. Send the same list to everyone, including us.

First: the ninety-second test that needs no vendor

Install any vendor’s demo app and do four things:

  1. Scroll a long product list and stop hard. Native scrolling has the platform’s own momentum and edge bounce.
  2. Airplane mode, then reopen. A native app shows its own state or a designed empty state. A browser view shows a browser error.
  3. Long-press a product image. A web image offers “copy link address.” A native one does not.
  4. Watch a category-to-product transition. A flash of white and text-before-images is a page load.

You now know more about the architecture than any feature list will tell you. Everything below is for the things you cannot test yourself.

Architecture

  1. Which screens render natively and which are a WebView? Screen by screen.
  2. Show me a screen recording from the cart to the payment page.
  3. Is the address and shipping step native, or part of the web checkout?
  4. After payment, does the customer land on a native confirmation screen?
  5. What happens to a product type your app cannot render natively — fallback to my store’s page, or an error?

Worrying answers: a refusal to be screen-specific; “it’s fully native” with no recording; anything that dead-ends the customer in a browser after payment.

Ownership and review risk

  1. Under whose Apple Developer account is my app published?
  2. Under whose Google Play account?
  3. Can you explain how Guideline 4.2.6 applies to your product?
  4. Is the bundle identifier mine, in my own reverse-domain form?
  5. If I leave, what happens to the listing, its ratings, and my installed users?

Worrying answers: “we publish under our account” without an explanation of 4.2.6; “we’d have to transfer it, it’s complicated.” Why this matters.

Money

  1. What is the price on the plan that includes iOS?
  2. List every metric that can increase my invoice — sessions, MAU, notifications, bandwidth, builds.
  3. Is there a setup fee?
  4. How many apps are included, and what does a second cost?
  5. Do you place ads in my app on any plan, and is removing them free?
  6. Do you take any commission on my sales?
  7. What happens to installed apps if my subscription lapses?

Worrying answers: a metered plan you cannot price at 3× your traffic; iOS on a tier above the one you were quoted; “the app is deactivated.” Question 17 is the tiebreaker. More on hidden costs.

Publishing

  1. On my plan, what exactly do you do for submission, and what do I do?
  2. Do you compute the data-safety and privacy answers, or do I?
  3. Do you check my store for launch blockers before submission?

Worrying answers: “we provide documentation” as the whole answer; publishing help only on a higher tier.

Changing the app afterwards

  1. Which visual changes can I publish without a new build and store review? Give me the exact list.
  2. How long after I publish does an already-installed app show the change?
  3. Which changes require a rebuild?

Worrying answers: “everything is instant” (nothing is; ask about already-installed apps) or a vague list. Our own answer: theme, colours, typography, home layout, banners, intro slides and feature toggles ship over the air; the app name, launcher icon and bundle id need a build. An installed app fetches the change in the background and shows it on the next open after that. The mechanics.

WooCommerce specifics

  1. Name my three most important plugins. What happens to each one in the app?

Then ask for the variable-product test in a recording: a product with three colours and four sizes, where one combination is out of stock. You are looking for swatches rather than dropdowns, a price that updates on selection, unavailable combinations disabled rather than erroring, and per-variation stock. The full list is here.

How to read the replies

Three signals matter more than the content of any single answer:

Specificity. A vendor who answers question 1 screen by screen is a vendor who knows their product. A vendor who answers with adjectives is selling.

Willingness to name limits. Every product has them. Ours: no ads, no fully native card form, no membership/LMS focus, and an unmaintained app degrades over OS releases. A vendor with no limits has not told you theirs yet.

Consistency with their own public pages. If a sales email contradicts their pricing page, believe the pricing page.

Then test it on your own store

Whichever vendor you shortlist, before you pay:

  1. Connect your real store, not a demo.
  2. Open your three weirdest products and try to buy each one.
  3. Check a variable product’s swatches, prices and stock.
  4. Time your own store’s API — a slow store makes any app feel slow. How to measure.
  5. Install it on a real Android phone via APK if that is offered, and give it to one real customer.

A 14-day free trial is enough to do all five. If a vendor cannot let you try it against your own catalog before paying, that is itself an answer to a question you did not have to ask.

Related reading