You searched something like website ecommerce development because you need a store built and you’re working out who should build it. What came back was a wall of vendor pages that all look the same: each one leads with the platforms it holds certifications on, Shopify and Magento and WooCommerce and BigCommerce, then adds a headcount, a founding year, and a row of industry logos. Almost none of them help with the question that comes first, which is whether your store needs a platform at all or needs custom development, and what changes about the engineering once you cross that line.

Two of the pages ranking for this search show how the genre works. ScienceSoft opens on credentials, a Financial Times ranking and 750-plus experts and a founding date in 2003, then lays out a menu: consulting, custom development, platform-based solutions, mobile apps, headless and microservices, with AR, VR, AI, blockchain, and IoT hanging off the side. Custom development sits in that list as one option among a dozen and never gets explained, and the page has nothing to say about infrastructure decisions, testing, or how any of it gets deployed. Unified Infotech’s page runs six solution types, a Discovery-through-Maintenance process diagram, a technology showcase naming Magento, WooCommerce, Shopify, Adobe, Oracle, and Salesforce Commerce, and then a cost range wide enough to span most of a six-figure budget without anything explaining what moves a project from one end of it to the other. Neither page says a word about who owns the source code after launch.

Widen out to the “top ecommerce development company” roundups and directories and the pattern holds: which platforms the shop is certified on, how many people work there, how many years it’s been around, which industries it has served. So this is the piece we’d have wanted if we were the ones buying: what a platform genuinely covers, where its ceiling shows up, what custom development involves once you’re past it, and one store of ours that lives on the other side of that line.

It’s worth being fair to the platforms first, because for a lot of the businesses typing this search they’re the right answer, and a custom build would be overbuilding.

Shopify, WooCommerce, and Magento get you live fast, and what you get is more than a storefront. The catalog, the cart, the checkout, payment processing, tax calculation, shipping rates, and the basic order lifecycle all exist on day one, hardened by every other store running the same code. Somebody else carries the PCI scope and patches the platform, and a theme gives you a competent design without anyone writing front-end code. The app ecosystems around them cover most of what a store needs after that: subscriptions, product reviews, upsells and cross-sells, abandoned-cart email, loyalty points, reorder reminders.

If your catalog is products with variants, your pricing is a number attached to a product with the occasional discount code, and your fulfillment is pick, pack, and ship, then a platform covers you. The money a custom build would cost buys very little you couldn’t get by installing something, and you’d be taking on a codebase to maintain in exchange.

The ceiling is business logic, and it’s the part every page on this search result skips.

A platform models a store in a fixed shape. There are products, variants, collections, a cart, an order, and a customer, and only a small number of ways those objects are allowed to relate to each other. Apps extend the edges of that shape, but everything an app does still has to be expressible in those same objects, so when the way your business sells doesn’t fit them, no amount of app-shopping gets you there.

In practice it shows up in a handful of recognizable places. The most common is pricing, once the rules depend on who is buying, through which channel, at what commitment level, with margin math that has to hold across all of it. Inventory allocation is close behind, especially when the reason people buy from you at all is that you release limited stock to a subset of customers on rules you invented. Checkout hits the same wall whenever an order carries more than one kind of fulfillment, or a future ship date, or a compliance check tied to where the customer lives, because a platform’s cart object was never built to hold any of that. Then there’s the operational side, the inventory, fulfillment, and warehouse workflow that has to match how your building actually runs instead of how a template assumes it does.

You can usually tell you’re there without an audit. The answer to a normal business question has become “the app doesn’t support that,” or someone on the operations team spends every morning doing by hand the thing the store was supposed to do. The monthly app bill is a decent second signal, particularly once half of those apps break every time the platform ships a major version.

Every agency page prints a phase diagram, so this is ours with the content left in.

Discovery and architecture comes first, and for a store that means getting specific about the catalog’s real shape, the full order lifecycle from cart to delivered to returned, the rules that govern pricing and allocation, and every system the store has to talk to: the ERP or inventory system, the 3PL, the payment processor, tax, email, and whatever analytics the business already runs on. It’s also where you decide what stays bought, because nobody should be hand-rolling payment processing or a tax engine inside a custom storefront.

Then we build in short cycles with weekly updates, so you’re looking at working software every week and judging the product instead of a status report. Launch gets planned around your business rather than a date somebody picked, everything goes through staging and QA, and we monitor from day one. After launch we stay on as the retained team that owns it, which is where most of the relationship happens.

Underneath all of that, the concrete difference from a platform build is what the store is made of. The storefront and checkout become application code you can read and change, typically a Ruby on Rails backend with React handling the interactive parts of the front end. The data lives in your own PostgreSQL, with Redis behind the work that runs in the background, so any question you want to ask the database, you can ask. Releases go out through a continuous integration and delivery pipeline you control, running on Render or AWS, instead of arriving in a vendor’s release notes.

Wine Spies is an online wine retailer whose storefront, cart, and checkout we built, and we still run the platform today.

We inherited it from the founding engineer who’d built the original, and the first job was stabilization: an RSpec suite so changes could be made without guessing what would break, repairs to the fragile integrations, and enough work on the admin backend that it stopped falling over on the heaviest sales days. Once we could deploy with confidence we started building, overhauling the frontend with a reactive cart and checkout in React and then shipping a standalone iOS app in React Native. We added a separate API and data layer to give the platform clean boundaries, and we rebuilt the operational backend covering inventory, fulfillment, and logistics so the warehouse side could keep pace with order volume. The whole thing runs on Render with PostgreSQL and Redis, stays current through regular Rails upgrades, and ships through CI/CD backed by the test suite.

The part worth dwelling on is The Locker, a proprietary allocation and membership capability that became a major inflection point for the business. It was first in the industry when we shipped it, which is why no app marketplace had anything to install in its place. We built it because we understood the wine business well enough to see the opportunity before anyone wrote a spec, and because the store was application code we could change. The length of the partnership, the revenue growth that came with it, and the executive role our founder holds there are all on the Wine Spies case study.

Nobody in this search result takes this question on, and it’s worth asking out loud before you sign anything.

On a platform you own your data and your theme. The software your store runs on belongs to the vendor, and so does its roadmap, so when they change a checkout API, deprecate an app you depend on, or move a capability you use into a higher tier, you adjust on their schedule. That’s a reasonable trade for what the platform does for you, and it only becomes a problem when the store has grown into something the business can’t afford to have moved out from under it.

With a custom build, the codebase and the infrastructure are yours: the repository, the database, the deploy pipeline, and the accounts the whole thing runs in. You can bring it in-house or hand it to a different team whenever you want, which is worth confirming in writing with any shop you hire.

Ownership comes with an obligation, and that’s the honest part these pages leave out. Somebody has to keep the framework current, patch the dependencies, and watch the thing in production. For our clients that’s the fourth phase of the build instead of a separate conversation. We deliver major Rails and Ruby upgrades with zero downtime, we review every change before it ships, and we deploy through staging with an immediate rollback if something goes sideways, and projects are held to a stated automated test coverage standard with the figure written out on our existing products page.

One thing a custom store won’t solve by itself is reporting. Once you’re selling through a storefront, a marketplace, and possibly wholesale, no single system holds the whole picture, and assembling one is its own body of engineering work. We wrote that up separately in analytics engineering for e-commerce teams.

A platform is the right call when your catalog is ordinary, your pricing is a number attached to a product, nothing about how you sell requires logic the platform can’t already express, and getting live this quarter matters more than anything else on this page. Pick one, install what you need, and revisit the question in a year when you know more about your own business.

Custom development earns its cost when the thing that makes the business work is the thing the platform can’t represent: an allocation or membership mechanic customers come to you for, pricing that depends on who’s buying and through which channel, an order lifecycle carrying more than one kind of fulfillment, an operations layer that has to match a real warehouse. When one of those sits at the center of how you sell, you’ll spend years fighting the platform to approximate it.

There’s a third answer the vendor pages rarely offer, which is both: a platform storefront with a custom application beside it, owning the logic the platform can’t hold and syncing what it needs to. That’s a legitimate architecture and often the cheapest route to one specific capability, so it’s worth asking about before you commit to a full rebuild.

And if you’re already on a platform and recognized your own store in the ceiling section, the replatforming question deserves a real evaluation, because the cost of staying shows up in app subscriptions, manual operations work, and the workarounds your team has stopped noticing.

Before you talk to anybody, write down three things: what your catalog actually looks like, what has to happen between “add to cart” and “shipped,” and the one rule about how you sell that you would never give up. Those three notes settle most of this decision, and they’re what any competent shop will ask you for anyway.

Then take them to whoever you’re evaluating and ask directly whether a platform still covers you. A shop that only builds custom software has an obvious reason to tell you it doesn’t, so ask for the reasoning behind the answer and judge that instead of the verdict.

If you’re starting from nothing, new products covers how we run a build from architecture through the first year of real users. If you already have a store and you’re weighing whether to replatform or extend what you’ve got, existing products covers how we take over a codebase that’s already running a business. And if you’d rather talk it through, book an intro call and bring those three notes with you.