How we drive impact in platforms.
Most conversations about e-commerce platforms start in the wrong place. They start with the technology, which system is newest, which architecture is fashionable, which stack a competitor happens to be using, and then work backward to justify it. We think that order is reversed. The platform exists to serve a specific brand with specific economics, a specific stage of growth, and a specific set of customers. Until those things are clear, no platform decision can be a good one, because there is nothing to measure it against.
At eTail eCommerce, the platform is a means, never the end. The end is a store that converts the traffic you already pay for, an operation that does not break when orders climb, and a margin structure that survives contact with reality. When we evaluate where to build, we are really asking a simpler question: what setup gets this brand to profitable growth with the least friction and the least risk? That question has different answers for a first-year DTC brand and an established operation with warehouses and a catalog of thousands. Treating them the same is how money gets wasted.
This page lays out how we think about the e-commerce tech stack and where we build. It is a practical view shaped by the work, not a sales pitch for any one vendor. We have opinions, and we will share them plainly, but the opinions are in service of your outcomes, not a preference we are trying to talk you into. eTail is advisor-led by Jason Kumpf, supported by a wider network and AI-assisted workflows, and that structure keeps us close to the decisions that matter rather than abstracted away from them.
If you take one idea from this page, take this: a platform choice is a business decision wearing a technical costume. The cost, the speed, the flexibility, the maintenance burden, all of it eventually shows up in your P&L and in how your team spends its days. We treat it that way from the first conversation, and we would rather give you an honest read on what fits than impress you with a stack you do not need.
There is a strong pull in e-commerce toward whatever is new. New platforms, new frameworks, new architectures all arrive wrapped in the promise that they are the future and that anyone not adopting them is falling behind. Some of that is real progress. Much of it is noise dressed up as urgency. The job is to tell the difference, and the only reliable way to do that is to anchor every decision to where your brand actually is right now.
A brand that is still finding product-market fit needs to move quickly, test offers, and change its mind without paying a penalty for every change. A brand with steady demand and growing complexity needs reliability, clean data, and systems that hold up under load. A brand with unusual products, complex bundles, or a business model that does not fit standard retail patterns may genuinely need something custom. These are different problems, and the right platform for one can be the wrong platform for another. Stage and economics decide the answer far more than trend ever should.
We pay close attention to your unit economics when we make these calls. What does it cost to acquire a customer, and what is that customer worth over time? Where does margin leak, in fees, in fulfillment, in returns, in the quiet tax of tools nobody uses? A platform decision that ignores these numbers is a guess. A platform decision built around them is a strategy. We would rather spend time understanding your economics up front than rebuild a store later because the first version was chosen for the wrong reasons.
This is also why we resist the urge to over-build early. It is tempting to architect for the brand you hope to become, but premature complexity has a cost that compounds. Every system you add is something to maintain, integrate, and eventually migrate. Building for your current stage with a clear path to the next one is almost always wiser than building for a future that has not arrived and may not arrive in the shape you expect.
For most of the brands we work with, Shopify, and Shopify Plus as the catalog and order volume grow, is a sensible default. We say "default" deliberately. It is not the answer for everyone, and we will tell you when it is not. But for the majority of online and DTC brands, it is the platform that lets you spend your energy on growth rather than on keeping the lights on, and that is worth a great deal. This is a practical view earned from building on it, not a paid endorsement and not a badge we are claiming.
The first reason is speed. Standing up a capable store on Shopify is fast, and changing it is fast. When you want to test a new landing page, adjust checkout, or launch a promotion, you are not waiting weeks for an engineering cycle. For brands that live or die on their ability to iterate, that velocity directly affects how quickly you learn what works. Time spent fighting your own platform is time not spent improving conversion or acquisition.
The second reason is the ecosystem. Shopify sits at the center of a large network of apps, integrations, themes, and specialists. Almost any common need, email, reviews, subscriptions, fulfillment, analytics, has a well-supported, well-documented solution that connects without custom engineering. That breadth means you are rarely the first to solve a problem, and the solutions tend to be mature. It also means hiring and handoffs are easier, because the knowledge is widespread rather than locked inside one custom system only a few people understand.
The third reason, and the one founders underweight most, is total cost of ownership. The sticker price of a platform is the smallest part of what it costs you. The real cost is everything around it: developer time, maintenance, security, the risk of something breaking during your busiest week, and the opportunity cost of attention spent on infrastructure instead of customers. Shopify absorbs a large share of that burden, hosting, security, uptime, and platform updates are handled for you. For brands without a standing engineering team, that trade is usually favorable, and it is favorable in exactly the places that are easy to ignore until they hurt.
Custom and headless builds have a real place, and we build them when they are warranted. A headless setup, where the storefront is decoupled from the commerce backend, can deliver experiences and performance that a conventional theme cannot, and a fully custom build can model business logic that no off-the-shelf platform handles cleanly. When a brand genuinely needs these things, the investment pays for itself. The hard part is being honest about when that is actually true, because the honest answer is "less often than the industry suggests."
Custom tends to earn its cost when you have scale and complexity that standard tools cannot express: unusual catalog structures, intricate pricing or bundling logic, content needs that strain a normal storefront, integration with systems that have no ready-made connector, or a brand experience so central to your differentiation that the constraints of a theme become a real ceiling on growth. In those cases the added cost buys something specific and valuable, and you can point to exactly what it buys. The decision is grounded in a need, not a preference.
Custom becomes an expensive mistake when it is chosen for reasons that do not hold up. Wanting to feel sophisticated is not a reason. Assuming you will need the flexibility someday is not a reason, someday rarely arrives in the form you predicted, and you will have paid to maintain capability you never used. A custom build means you now own the maintenance, the security, the hosting decisions, the updates, and the cost of every future change. For a brand that has not yet hit the ceiling of what a standard platform offers, that is a heavy burden adopted for no present benefit, and it tends to slow you down precisely when speed matters most.
Our test is simple and we apply it before, not after. We ask what specific outcome the custom path delivers that a well-built standard setup cannot, and what that outcome is worth to your business. If we can name the benefit, quantify roughly what it is worth, and show that it clears the added cost and ongoing burden, custom is on the table. If the case rests on flexibility you might use, prestige, or the assumption that bigger means better, we will say so, even when it would be easier and more flattering to agree.
The platform is the foundation, but it is not where most of your results come from. A store that converts and an operation that holds together depend just as much on the surrounding stack, the systems for email and SMS, reviews and social proof, analytics, subscriptions, and fulfillment and operations. These are the tools that capture demand, retain customers, and turn one-time buyers into repeat ones. Chosen well, they compound your results. Chosen carelessly, they become a pile of overlapping subscriptions that nobody fully uses.
Email and SMS are usually the highest-leverage parts of the stack, because they reach customers you have already earned. Done properly, they recover abandoned carts, welcome new buyers, bring lapsed customers back, and carry the relationship between purchases. We treat these as core, not as an afterthought, because retention economics often determine whether a brand is actually profitable once acquisition costs are accounted for. The platform that hosts your store should make this layer easy to run, not something you fight to connect.
Reviews and social proof influence the decision at the moment it matters most, on the product page where intent is highest. Analytics determine whether you can see what is working, and a store you cannot measure is a store you cannot improve with any confidence. Subscriptions, where the product supports them, can transform the economics of a brand by converting sporadic purchases into predictable revenue. Fulfillment and operations decide whether the promise you made at checkout is actually kept, which is where many brands quietly lose the trust they spent so much to earn.
The thread connecting all of it is clean integration. Each tool has to talk to the others and share data without manual stitching or brittle workarounds. A stack where systems are disconnected creates blind spots, duplicate work, and errors that surface at the worst possible time. We choose tools that fit together and reinforce one another, so the whole is genuinely greater than the parts, and so the operation does not depend on someone remembering to copy numbers between two screens every morning.
One of the most common problems we see is a store weighed down by too many apps. It happens gradually and almost reasonably. A founder reads about a tool, installs it to solve a problem, and moves on. Repeat that over a couple of years and the store is carrying a long list of apps, many overlapping, several forgotten, each adding weight and cost. The instinct behind every install was sound. The accumulated result is a drag on the entire operation.
A bloated app stack hurts in ways that are easy to miss until you look for them. Every app you load adds to the work the store has to do, and that often shows up as a slower site, and slower stores convert worse, which means the bloat is quietly taxing your revenue. It adds subscription cost that drains margin month after month, frequently for tools delivering little or nothing. And it adds fragility: more moving parts mean more that can break, more that can conflict, and more that has to be checked when something goes wrong. Complexity has a running cost even when nothing is actively failing.
We approach the stack with deliberate restraint. The goal is the smallest set of tools that covers what the business actually needs, each chosen carefully and integrated cleanly. Fewer tools mean a faster store, lower recurring cost, fewer points of failure, and a system the team can actually understand and run. When we take on a store, part of the work is often subtraction, removing what is not earning its place so the essentials can do their job without interference. It is rarely glamorous, and it is frequently the highest-return work we do.
This discipline is not minimalism for its own sake. Every tool that remains is there because it earns its keep, and we are happy to add capability when capability is needed. The point is that each addition should be a deliberate choice with a clear reason, not an accumulation of good intentions. A lean, well-integrated stack is faster, cheaper to run, and far easier to grow on than a sprawling one, and it leaves your team with attention to spend on customers rather than on managing tools.
Sometimes the right move is to change platforms. A brand outgrows its current setup, gets locked into a system that no longer fits, or carries a store so encumbered that rebuilding is cleaner than repairing. Migration and replatforming are legitimate and sometimes necessary work. They are also among the riskiest projects in e-commerce, because the thing you are rebuilding is the thing that pays the bills. A migration handled carelessly can take down revenue, break operations, and damage trust in a single bad week. That risk deserves real respect.
The mistake we work hardest to avoid is treating a migration as a single dramatic switch, the kind where everything changes at once and you simply hope it holds. That approach turns a manageable project into a bet on the whole business. Our preference is to de-risk the work: understand the current setup in detail before touching it, plan the sequence carefully, preserve what is working, and protect the things that quietly matter, SEO, customer data, order history, and the operational habits your team depends on every day. The goal is continuity, not spectacle.
Practically, that means careful preparation and staged execution rather than a leap. We map what exists and why, identify what must carry over and what should be left behind, and find the points where something could go wrong before it does. We test before we commit and we keep a path back when one is warranted. The aim is a migration that customers barely notice, where the store keeps selling, the data stays intact, the team keeps shipping orders, and the brand moves onto better footing without a frightening interruption to revenue.
We are also honest about whether a migration is worth doing at all. Replatforming is expensive in money, time, and attention, and the disruption is real even when it goes well. Sometimes the better answer is to fix and optimize what you already have rather than rebuild it. We would rather talk you out of an unnecessary migration than lead you into one for its own sake, because the right outcome is a healthier business, and that is not always the same as a new platform.
Every decision on this page leads back to a single question: does this help the brand grow profitably? Platform choice, the surrounding stack, custom versus standard, the size of the app footprint, whether to migrate, none of these are technical exercises in isolation. They are levers on the economics of the business. The reason we are deliberate about them is that they ultimately determine how much of your revenue you keep, how fast you can move, and how much of your attention goes to growth instead of maintenance.
A platform that fits your stage lets you spend money on acquisition and retention rather than on infrastructure and rebuilds. A clean, lean stack converts better and costs less to run, which shows up directly in margin. Tools that integrate well give you the data to make good decisions and the retention mechanics to lift the value of every customer you acquire. Avoiding an unnecessary custom build or a premature migration keeps capital and attention pointed at the things that actually grow the business. These are not abstractions; they are the difference between a brand that compounds and one that stalls.
This is the lens we bring to platform work: not which technology is most impressive, but which arrangement of technology gives your brand the best path to durable, profitable growth. We are excited about that outcome, a store that converts, an operation that holds, margin that survives scale, far more than we are excited about any particular stack or any number on a dashboard. The technology is only ever interesting to us because of what it lets your business do.
Led by Jason Kumpf and supported by a wider network and AI-assisted workflows, eTail stays close to these decisions and accountable for them. We would rather give you a clear, honest recommendation grounded in your economics than push a platform that flatters a pitch deck. If you are weighing where to build, where to rebuild, or whether your current stack is helping or quietly holding you back, that is exactly the conversation we are built for, and exactly where we would like to start.
Before we recommend anything, we want to understand the business underneath it. That means your products and how customers actually buy them, your economics and where margin is made and lost, your current setup and where it helps or hurts, and where you are trying to take the brand next. A recommendation made without that context is a guess dressed up as expertise, and we would rather earn the call than gamble on it. The first work is almost always understanding, not building.
From there, the principles below guide how we work through the decision with you:
None of this is meant to be rigid. Every brand is different, and the right answer for one is not the right answer for another. What stays constant is the approach: honest, specific, grounded in your economics, and aimed squarely at profitable growth rather than at a stack we are trying to sell you. The decisions change; the discipline behind them does not.
A few questions come up often when founders are weighing where to build or whether to change what they have. Here are honest answers.
We will not claim a credential or badge we cannot prove to you here. What we can tell you honestly is that we have hands-on experience building and growing stores on Shopify, and we treat it as a sensible default for most of the brands we work with for the practical reasons laid out on this page. If a formal credential is important to your decision, ask us directly and we will give you a straight answer about exactly where we stand rather than dressing up a logo as a qualification. We would rather be trusted for what we actually do than for a badge.
No. Shopify and Shopify Plus are where we build most often because they fit most brands well, but the platform should serve your business, not the other way around. When a brand's stage, economics, or complexity genuinely calls for a custom or headless build, we will build it, and we will be just as clear about when that path is not justified. The goal is the right fit for your business, not loyalty to any single platform or to whatever is currently fashionable.
The honest test is whether you can name a specific outcome a custom build delivers that a well-built standard setup cannot, and whether that outcome is worth more than the added cost and the ongoing burden of owning the maintenance, hosting, and security. If the case rests on flexibility you might use someday, on prestige, or on the assumption that bigger is better, it is usually not the right call. We will walk through this with you honestly, and if standard tools cover your needs, we will say so rather than sell you something heavier than you need.
Yes, replatforming carries real risk, because you are rebuilding the thing that generates your revenue, and a careless migration can disrupt sales and operations in a single bad week. We handle it by de-risking the work: understanding the current setup in detail, planning the sequence carefully, protecting SEO, customer data, order history, and operational continuity, testing before we commit, and keeping a path back when one is warranted. We are also honest about whether a migration is worth doing at all, sometimes the better answer is to fix and optimize what you already have, and we will tell you when that is the case.