Last updated: August 21, 2026
An ecommerce tech stack that survives the jump from $50 million to $250 million needs one system of record for inventory and money, one order path every channel writes into, and integrations sized by transaction, not by unit. Everything past those three is preference. Most companies get the order backwards, buy the tools first, then spend the next two years building spreadsheets to referee the arguments between them.
Black Friday. A brand I know sold 1,900 units of an item that had roughly 1,100 units sitting in the building.
No pricing error. No fraud. Three systems each held a version of the inventory number, all three were arguably correct as of the last time they talked to each other, and not one of them had been named the referee. The storefront cached a number. The warehouse system knew a different one. Accounting reported a third at month end and nobody reconciled them because reconciling them was nobody’s job. Customer service learned about the gap from customers. Great look.
That is what $50 million in revenue looks like running on $10 million plumbing.
Quick disclosure before we keep going. I build these stacks for a living, so I profit the moment you decide yours is held together with tape and good intentions. You are reading this on a staffing firm’s website, and KORE1 profits when you decide you need humans to run the thing. Two commercial interests, both in plain sight. Adjust for them.
The call usually comes in about six weeks after a peak season goes sideways. Sometimes it’s a CFO who cannot explain a margin swing, sometimes it’s an ops lead who has quietly hired two people whose entire job is copying numbers between screens. KORE1’s ecommerce staffing desk fields the same call from the other side, usually phrased as “we need somebody who has done this at our size, starting soon.” If you have not picked a platform yet, go read how to choose an ERP for a mid-market business first and come back. This piece assumes you already own most of the pieces and they are not cooperating.
A Tech Stack Is Not a List of Tools
Every article you will find on this topic hands you a shopping list. Storefront, payments, CRM, email, analytics, a warehouse system, maybe a PIM. Fine. That list is real and it is also the least interesting thing about your stack.
Your stack is a set of ownership decisions.
Which system is allowed to change an inventory number. Which one is allowed to change a price. Which one gets to say an order exists. Which one holds the customer record that everything else copies from. Answer those four and the tool selection mostly writes itself, because you will have eliminated three quarters of the options on the grounds that they refuse to give the answer up.
Answer them badly, or fail to answer them at all, and you end up where that Black Friday brand ended up. Two systems both decrementing available inventory, each one confident, neither one wrong exactly, both of them lying to a customer. Nice.
Let’s graduate our tech stack from the ’90s to at least the 2000s. That mostly means picking a referee and making everything else defer to it.
What Actually Breaks, and Roughly When
Growth does not break your stack evenly. It has a sequence, and knowing the sequence is worth more than any vendor comparison chart.
| Revenue band | What breaks first | The tell |
|---|---|---|
| $10M to $50M | Manual handoffs between systems | Somebody’s job title has nothing to do with what they do all day |
| $50M to $100M | Inventory truth splits across channels | Oversells during promos, phantom stockouts the rest of the year |
| $100M to $180M | Financial consolidation and channel profitability | Nobody can say which channel makes money without a two-week project |
| $180M to $250M+ | Integration volume against platform limits | Nightly syncs stop finishing before the warehouse opens |
The last row surprises people. It shouldn’t.
Volume is not linear with revenue. Order count grows, SKU count grows, returns grow, and the number of API calls your integrations make grows as the product of all three. A design that was comfortable at $60 million can be over its licensed ceiling at $200 million without anybody having changed a line of code, and the first symptom is not an error message. It’s a report that used to be ready at 6am showing up at 10am, then at noon, then not at all.
Pick the System of Record Before You Pick Anything Else
One system owns inventory. One owns the money. Ideally the same one, which is why the ERP usually wins this argument for companies moving product.
Your storefront should own presentation and the shopping experience. It should own nothing durable. The moment your storefront becomes the place where somebody edits a cost or adjusts an on-hand quantity, you have two masters and you will spend the next three years arbitrating between them.
The customer record is the one people get wrong most often, because it feels like the CRM should own it. Sometimes. If your sales team works accounts and negotiates terms, the CRM probably owns the relationship while the ERP owns the billing entity, and you need a deliberate mapping between the two rather than a hopeful one. I wrote about that specific seam in more detail in the piece on connecting CRM and ERP.
Wholesale changes the math again. If you sell to distributors and direct to consumers out of the same building, you are running two businesses with different pricing logic, different lead times, different return behavior, and one pool of physical inventory. Companies routinely try to solve that with a second instance of something. It rarely works. One pool, with allocation rules a human can explain out loud, and a written answer for who gets the last case when both channels want it. More on that in real-time inventory and stockout prevention.
The Integration Layer Is Arithmetic, Not Architecture
Here is the part almost nobody checks before signing, and it is my favorite thing to point at because it takes about twenty minutes and it is not a matter of opinion.
Your platform has a licensed API call allowance. Your integration design has a call volume. Those two numbers either work or they don’t, and you can calculate them on a napkin before anybody writes a specification.
Real benchmark from a design review we ran not long ago. The proposed integration touched the API once per unit. At roughly 70,000 units a month entering inventory, that design consumed about 1,350,000 calls a year against a licensed allowance of 130,000. Over by a factor of ten. Not a little over. Not something you tune your way out of after go-live.
The same integration built at the transaction level, batching roughly 141 documents a month at four to six calls each, used under a quarter of the allowance with room to triple the business.
Same data. Same business. Same platform. Different unit of work.
Nobody in the room had done the arithmetic, and the unit-level design had already cleared two rounds of review by people with impressive titles. Not their fault, really. The failure is in how these reviews get run, where everybody argues about whether the architecture is elegant and nobody multiplies two numbers together.
One more from the same category, since it costs people weeks. A REST endpoint inside an ERP will generally not accept a plain API key. Signed requests only. Some platforms want OAuth 1.0 token-based auth, some want OAuth 2.0, and neither one is something a vendor bolts on over a lunch break. If the vendor on the other end only knows how to POST to a plain URL with a key in the header, you need an authenticated relay sitting in between. Small piece of work. Real piece of work. It is never in the original estimate, and I have watched it eat a schedule that had no slack in it. Two weeks. Gone. General integration best practices for unifying disparate systems cover more of this ground.
The Build Order That Actually Works
Roughly seven months, if the business cooperates and somebody with authority is available to make decisions when they are needed. The second condition is the one that slips.
| Phase | What you stand up | Typical duration |
|---|---|---|
| Discovery and decisions | System of record, ownership map, data tiering, the list of what is not coming | 3 to 5 weeks |
| Core financials and inventory | Chart of accounts, item master, costing method, subsidiary structure | 8 to 10 weeks |
| Channel integrations | Storefront, marketplaces, EDI for wholesale partners, payments and settlement | 6 to 8 weeks, overlapping |
| Warehouse and fulfillment | Scanning, bin logic, wave picking, 3PL message flows | 4 to 6 weeks |
| Cutover and hypercare | Rehearsal loads, parallel period, the phase everybody under-resources | 4 weeks |
Financials before channels. Always. If you connect the storefront before the chart of accounts is settled, every order that lands is a transaction posting to a structure you are about to change, and you get to migrate the same data twice.
Warehouse last is the one people fight me on, because the warehouse is where the pain is loudest and it feels wrong to make them wait. They lose. The warehouse cannot be right until the item master is right. Scanning against a bad item master just tells you faster that the item master is bad. There is more on that sequencing in the write-up on WMS integration for ecommerce and wholesale.
Seven Months, and What It Bought
The team at justingredients.com had grown through $150 million in sales on a set of systems that had quietly stopped talking to each other somewhere along the way. Not through neglect. Through growth, which is the more common cause and the harder one to see from the inside, because every individual decision that got them there was reasonable at the time it was made.
We rebuilt the stack in about seven months. It now runs a business north of $250 million with real visibility across both the ecommerce and the wholesale side, on the same inventory pool, with financial reporting that closes without anyone exporting anything to reconcile it by hand.
The interesting part is not the platform. It never is. What matters is what stopped happening.
Nobody argues about which inventory number is right, because there is one. Nobody builds a channel P&L by hand, because the segmentation is in the data model. And nobody has to hire a person whose entire function is being a human integration between two systems that will not speak to each other, which is the most expensive role in the mid-market and the one that never shows up as a line item anywhere. That job sucks. Nobody wants it.
Different flavor of the same problem at zamp.com, which needed a product built inside the platform rather than around it. Designed, built, and launched in about five months, and they can now sell through the marketplace. Different shape of work. Same principle, which is that you decide what owns what before you decide what to buy.
None of this is exotic. It is unglamorous and it is mostly discipline, and the reason it doesn’t happen more often has nothing to do with the software being complicated.
The Debt You Are Already Carrying
Second quarter of 2026, and the U.S. Census Bureau has retail ecommerce at $340.2 billion. That is 17.1 percent of everything sold at retail, up 12.2 percent on the year, while retail overall managed 6.7 percent. Your channel is compounding roughly twice as fast as the market it sits inside. Whatever your stack cannot handle today, it will be asked to handle about twice as much of within four years.
Meanwhile the cost of not dealing with it is already on your books, just not labeled. In the 2024 Stack Overflow Developer Survey, 62.4 percent of professional developers named technical debt as their top frustration at work, ranking it first regardless of whether they were an individual contributor or a manager, and roughly double the next item on the list. That is your engineering payroll telling you where the week goes.
Every business is underutilizing tech. Yours included. I say it constantly and I have not been wrong about it yet. The gap is almost never the platform. It’s that nobody has been given the authority to make the four ownership decisions at the top of this article and then hold the line when a department asks for an exception.
The Part Where This Becomes a Hiring Problem
A stack rebuild needs two very different kinds of people, and companies keep trying to make them one person. It never works.
There is the project window. Integration developers, a solution architect, somebody who has migrated an item master before and knows what a costing method change does to your P&L. Those are fixed-duration needs and contract is the honest structure for them, because pretending a nine-month need is a permanent role is how you end up with an expensive resignation in month eleven.
Then there is the person who owns the thing afterward. Permanent, hired early enough to sit through the build rather than inherit it from a slide deck, and empowered to say no. The Bureau of Labor Statistics projects 15 percent growth for computer and information systems managers through 2034, with about 55,600 openings a year. You are competing for that person against everybody else who just figured out they need one.
KORE1 splits those two desks deliberately. Their ecommerce and wholesale ERP staffing practice covers the operators, integration specialists cover the middle layer, and SuiteCommerce developers cover the storefront side when the build is native. Across 30-plus U.S. metros, their average search closes in 17 days, and better than nine in ten placements are still in the seat a year on. The retention number is the one I would push on in a first conversation. A stack is a set of decisions, and decisions live in somebody’s head until they are documented, which is roughly never.
What Operators Ask Me Somewhere Around $80 Million
How much should a stack like this actually cost us?
Budget services at two to four times your annual software spend for the first build. A mid-market integrated rebuild lands in the mid six figures for most companies moving physical product, and blended consulting rates around $215 an hour are a reasonable planning assumption. Cheap quotes are usually cheap by exclusion rather than by efficiency.
Can we do this without ripping out the storefront?
Usually yes, and usually you should. The storefront is the piece your customers touch and the piece your marketing team knows how to operate. Replacing it at the same time as your financial system doubles the risk for a benefit you can capture six months later at a fraction of the stress.
Our systems are connected already. Isn’t this solved?
Connected and integrated are different words. A nightly file drop is a connection. Integration means one system is authoritative, the others defer to it, and there is a defined behavior for what happens when a message fails at 2am. Ask what happens when a message fails at 2am. Watch the pause. The answer tells you which one you have.
Seven months feels long. What makes it go faster?
Decision availability, not developer count. Adding people to a build that is waiting on someone to rule on a costing method makes it slower. The fastest projects I have run had one executive who could be interrupted and would answer in a day.
Do we need a middleware platform or can the systems talk directly?
It depends on how many endpoints you expect in three years. Two systems, point to point is fine and cheaper. Five or more, you want something in the middle so that adding the sixth is a configuration exercise instead of a project, and so that the retry logic lives in one place.
We are mostly wholesale with a small DTC channel. Does any of this apply?
More than it does for pure DTC, honestly. Wholesale brings EDI, negotiated pricing, allocation across accounts, and chargebacks, and every one of those puts pressure on the same inventory pool your consumer channel is drawing from. The mixed model is the hard case, not the easy one.
Trace One Order End to End
Skip the vendor demos this week. Do this instead.
Pick one order from last month. A normal one, not an edge case. Follow it from the moment the customer clicked buy to the moment the revenue posted, and write down every system it touched and every place a human moved it along. Not what the process document says. What actually happened.
Most people find between four and seven systems and at least two human handoffs they did not know were there. Some find nine.
Then count how many of those systems could have told you, unprompted, that the order existed. If the answer is one, you’re in decent shape and this is a tuning problem. If the answer is four, you don’t have a stack. You have a group chat between applications, and somebody on your payroll is the moderator.
Run the trace, then hit me up on LinkedIn and tell me what the count came back as. I am genuinely curious how bad it gets out there. If the fix is architectural, that’s my side of the fence. If what you’re short is a person who has done this at your revenue and can start in weeks rather than quarters, that’s KORE1’s, and their team is worth a conversation before you try to cover it internally with somebody who already has a job.
