Ecommerce Web Development Judged on Checkout Completion

Which platform should we build on — Shopify, WooCommerce or custom?

Shopify when selling is the main event and you want hosting, security, PCI compliance and a well-optimized checkout handled for you. WooCommerce when the business is content-led and commerce is an addition, or when you need customization Shopify will not permit. Custom only when neither fits, which is rarer than agencies suggest.

The honest trade is between control and ownership of problems. Shopify constrains checkout customization by plan and charges transaction fees unless you use its payments, but you never think about server security. WooCommerce gives full control and no platform fee, and hands you hosting, updates and performance as a permanent job.

Custom builds make sense for unusual pricing logic, complex B2B requirements or deep integration with systems that already run the business. They also cost more forever, because you own every dependency.

Why do people abandon checkout?

Mostly for reasons decided before they got there. Unexpected shipping cost is the single most cited cause, and it is a pricing and disclosure decision rather than a checkout design one.

The others are consistent: forced account creation, too many steps, payment methods the customer does not use, a slow or broken mobile experience, and no visible reassurance about returns or security at the moment payment is requested.

What this means practically is that most abandonment is fixed upstream. Show shipping cost early. Allow guest checkout. Support the payment methods your customers actually use. Make the mobile path fast. The checkout page itself is usually the last place worth optimizing, not the first.

How should a large catalog be structured?

So the same product data serves customers, search engines and ad feeds without being rewritten for each. Getting this right at build time avoids an expensive cleanup once the catalog is live.

That means product titles in the words buyers search rather than internal SKU language, variants as real options rather than separate products, and attributes captured as structured fields instead of buried in description text.

Faceted navigation needs particular care at scale. Filter combinations can generate an enormous number of URLs, most of which nobody searches for and all of which consume crawl budget. Deciding early which filtered views should be indexable prevents a large SEO problem forming quietly.

Does store speed actually affect sales?

Yes, and on mobile it is one of the larger levers available. A slow store loses people before they see anything you spent money designing.

The usual causes are predictable: images uploaded at full resolution and served without responsive sizing, apps or plugins injecting scripts on every page whether used or not, and hosting that is slow before any of your code runs.

We will not quote a conversion figure for a speed improvement, because the honest answer depends on your traffic mix, device split and price point. What we will do is measure your field data before and after, so the effect on your store is a number you can see rather than one we assert.

How should product data be structured?

Once, properly, in a place everything else reads from. The most common expensive mistake in ecommerce is product information maintained separately for the storefront, the ad feed and the marketplace listings, drifting apart from the day it is created.

Structured product data means attributes are fields rather than sentences buried in a description. Material, dimensions, compatibility and identifiers each have their own place, which is what lets the same source populate a filter, a comparison table, a structured-data block and a shopping feed.

Identifiers deserve particular attention. GTINs, MPNs and brand fields are what shopping platforms use to match your listing to a known product, and incomplete identifiers are one of the more common reasons a feed underperforms without any obvious error.

The practical test: can you add a product attribute and have it appear in navigation, on the product page and in your feed without anyone editing three systems? If not, the data is stored as presentation rather than as data.

Why do people abandon at checkout?

Usually for reasons that were decided long before checkout. Unexpected costs appearing late, a required account, a form asking for more than it needs, or a page that is simply slow on the phone the customer is holding.

Cost surprise is the one worth designing around first. Shipping and tax revealed only at the final step is a reliable way to lose a sale that was otherwise complete. Showing them earlier costs some visitors at the cart stage and keeps more of the ones who reach payment.

Forced account creation is the next. An account is useful to you and an obstacle to a first-time buyer. Guest checkout with an optional account offer afterwards gets both, and the offer converts better once the person has already bought something.

Then there is the mundane part: field count, input types that summon the wrong keyboard on mobile, validation that clears what someone typed, and error messages that do not say what to fix. None of it is clever work and all of it is measurable in your own funnel.

How do integrations get handled?

By deciding, for every piece of data, which system owns the truth. Most integration problems are not technical failures — they are two systems both believing they are authoritative about stock.

Once ownership is settled, the direction of each sync follows from it, and so does what happens during a conflict. Writing that down before any code exists prevents the class of bug where an order is accepted for something that sold out three minutes earlier.

The second decision is timing. Real-time syncing sounds obviously better and costs more, in complexity and in rate limits. Some data genuinely needs it — stock on a fast-moving catalog. Much of it does not, and a scheduled job is more reliable and easier to reason about.

Third-party APIs change without asking. We build against them defensively, log what comes back rather than assuming, and make failures visible instead of silent. An integration that quietly stops working is worse than one that breaks loudly, because nobody finds it until the numbers stop making sense.

What happens after launch?

The store starts producing evidence, which is the first time anyone has real information about it. Launch day is the beginning of the useful part, not the end of the project.

The first weeks are about watching the funnel for the things testing cannot reveal: which step loses people, which products get searched for and not found, which filter combinations return nothing, and which errors are being hit in the wild.

Product data keeps growing, and it degrades unless someone owns it. New items arrive with missing attributes, images at the wrong dimensions, or descriptions pasted from a supplier. A short set of rules and an owner prevents a catalog that slowly becomes unusable.

Then there is the ordinary maintenance any commercial system needs — dependency updates, payment provider changes, seasonal load. Where you would rather that were handled than staffed, maintenance and support covers it.

How should a large catalog be structured?

So that any product is reachable in a small number of steps, and so that no path leads somewhere empty. Both are harder than they sound past a few thousand items.

Faceted navigation is the usual answer and the usual source of problems. Filters generate URL combinations, most of which are near-identical or return nothing, and left unmanaged a crawler will find every one of them. Deciding which combinations are real pages and which should be blocked from indexing is a decision to make deliberately.

Internal search does more work than navigation on large catalogs, and is more often neglected. Reviewing what people search for and what returns nothing is one of the cheapest sources of genuine merchandising insight available, and it needs no external tooling.

Category depth is the other lever. Deep hierarchies feel organized and bury products; flat ones surface everything and overwhelm. The workable answer is usually a shallow browse structure supported by strong filtering, rather than a taxonomy that mirrors your internal org chart.

What does selling internationally change?

More than currency. Price display, tax treatment, shipping restrictions, returns obligations and which products may legally be sold at all can differ by destination.

Tax is the part most often underestimated. Whether prices include tax, how it is calculated at checkout and what has to appear on an invoice vary by market, and getting it wrong creates a compliance problem rather than a display bug.

Then there is the question of what a customer in another market should even see. Showing products you cannot ship there produces a failure at checkout, which is the most expensive place to discover it. Filtering the catalog by destination is a build decision, not a setting.

Language is the visible part and often the last to matter. A market where buyers read English but expect local pricing, local delivery estimates and local returns terms is common. Translation without those changes tends to disappoint everyone.