Should You Build Your Own Inventory System? (2026)

In one week this month I talked to four e-commerce operators about building your own inventory system. Two were part way through doing it, one had deliberately stopped half way, and one wanted no part of it. Neither of the two who were building had set out to. Both started by wrapping a system they had already bought, to fix one workflow it would not bend to, and then noticed the wrapper had become the product. I did the same thing in 2008 and ran the result for eleven years before I gave up and started over. So this page is not a build-versus-buy framework. It is what the build actually costs after the part that AI made cheap.

The quotes below come from recorded calls in September 2026, lightly cleaned of transcription artifacts and attributed by role with names withheld. I sell inventory software, which means I have an obvious interest in your answer. The part of this you should weigh most is the part where I tell you I built my own and do not regret it.

What does building your own actually look like now?

It looks like a wrapper that grew.

The head of operations at a DTC brand described the sequence to me on September 4. They had started on Cin7, found it would not hold their packaging rules, and he built an interface on top of it. He has a software background, so this was not reckless. Then:

“After building that for a bit, I was like, okay, well, what’s even the point of this? I might as well try to build my own.”

That is the fork, and notice where it sits. It is not at the start. Nobody sensible wakes up and decides to write an ERP. You decide to fix one thing, the fix works, and the question of why you are paying for the thing underneath answers itself. Then:

“I’m on like the third time of completely tearing everything down and starting over again.”

A third teardown, on his own count. Hours and hours in the two weeks before we spoke, which is his description, not mine. He was clear-eyed about what bothered him, and it was not the building:

“I don’t want my time to be spent fixing bugs in the future. I want my time to be spent doing operational stuff.”

A second operator on a different call had stopped one step earlier and on purpose. He runs Finale, built his own portal against their API for the parts he needed, and deliberately kept Finale underneath so that, in his framing, he would not become a software company. He is still an e-commerce business that owns a UI. That is a real and underrated answer, and it only works if the system underneath keeps getting developed. He is looking at moving next year, and the reason is the foundation rather than his own code. Descartes acquired Finale in August 2025, which is the sort of event worth watching after it happens; what changed for Finale users has the dated facts.

What did AI actually change?

The build got cheap. The ownership did not.

Writing the first version is the part that collapsed in cost, and it collapsed hard enough that the old advice is genuinely out of date. Most of the build-versus-buy advice you will find still prices the build in developer-months, and treats that cost as most of the argument. It is not most of the argument now.

What did not change is everything after the first version. Somebody has to hold the schema in their head when a new channel needs a different fulfillment rule. Somebody has to decide what happens when a marketplace settles a fee three weeks after the order. Somebody gets paged when a sync fails at 2am during a promotion. That work does not shrink when the code gets easier to write, because it was never mostly about writing code.

Here is the version I would argue with someone about: the third teardown is not a sign that he is doing it wrong. It is a sign that he is doing it normally, and that the feedback loop which usually tells you to stop has been removed. Rebuilding used to be expensive enough to force a decision. Now you can rebuild on a Sunday, which means you can keep not deciding for a very long time.

What happened when I built one?

I built our internal ERP in 2008. We ran our e-commerce business on it for about eleven years.

It was good. It fit us exactly, because I wrote it while running the operation it was for, which is the single real advantage of building and I am not going to talk you out of it. The problem showed up slowly and it was not a technical problem:

“Eventually I’m like, man, I’m spending so much time and energy towards the software instead of the e-comm. I need to make a change.”

That was 2019, before any of this was AI-assisted. I took the question to my EO forum, asked what direction to take the company, and the answer I landed on was to become a software company on purpose rather than by accident. That is where SKU.io came from.

Two things about that I would want you to take seriously, because they cut in opposite directions.

The first is that eleven years is a long time. The build was not a mistake. If your operation is unusual and you are capable, you can get a decade of real advantage out of a system that fits you perfectly, and most of the people warning you off building have never had that.

The second is that I only escaped by changing what business I was in. That is the exit nobody plans for. I did not sell the ERP, retire it, or migrate off it cleanly. I reorganized my entire company around the fact that I had built it. If that is not an outcome you want, the honest question is not whether you can build it. It is who maintains it in year six, when the person who wrote it has been promoted, or has left, or wants their evenings back.

And building software for one company is the easy version. Building something modular enough to fit many businesses is a different and much harder job, which I learned by doing it second.

Who should build, and who should not?

The founder of another operation told me on the same day, plainly:

“I’ve never had aspirations of building like an ERP system. It’s just not really something that I’m interested in doing.”

He is not less technical than the operator above. He runs an unusually AI-forward organization. He had simply decided where he wanted his own attention, which is the actual question underneath all of this.

Build if your process is genuinely strange, you have someone whose job can include owning it in three years, and the fit is worth more to you than the option to stop thinking about it. Do not build because a prototype came together in a weekend. The weekend is the part that got cheap.

The middle path is the one I would push most people toward, and it is what the second operator is doing. Buy the system that holds the boring, dangerous parts, which means the inventory ledger, the cost layers, the marketplace fee reconciliation, the order state machine. Then build exactly the thing that is yours on top of it, against the vendor’s API. You get the fit without owning the foundation. It only works if two things are true of the vendor: the API can actually reach everything, and the vendor is still developing the product.

Both are checkable before you sign. Our API documentation is public at developer.sku.io with no login, and the six checks worth running against any vendor on your list take about an hour. Run them on us too.

What would make me stop trying to talk you out of it?

If the reason you are building is that nothing you evaluated could express your process, that is a legitimate reason, and it is the one I hear most often from people who were right to build.

It is also the reason I most often find to be fixable. Some of what gets rebuilt from scratch is a vendor saying no for eight months to something that takes two days. We typically fix bugs the same day or the next, and features are usually days rather than months, and for genuinely custom work we charge a development fee, which I would rather be honest about than pretend everything is free. The fee exists so the queue has an order, not because the work is exotic.

The arrangement I am most interested in right now came out of these same conversations. If you are agentically capable, you write the prompt and own the QA, and we build the thing natively into the platform instead of you maintaining middleware on top of it. That is a lower cost for both of us, and you end up with the customization inside the system rather than lashed to the outside of it. We are doing it on a case-by-case basis rather than as a published program, so if that shape appeals to you, say so directly.

The other half of that is our agent skills, which are open source. They sit between our API and the business logic so an agent does not have to read our docs to do a real task. They exist precisely because the people asking to build their own were right about wanting control, and were wrong about needing to own a database to get it.

The question I would actually ask

Not “can I build this.” In 2026 you probably can.

Ask who is on the hook for it in year six, and whether that person has agreed. When I answered that question honestly in 2019, after eleven good years, the answer turned out to be that I would have to change careers to get out from under it. That was a fine outcome for me. It is worth knowing in advance that it is one of the outcomes.

If you want to run the middle path against your own catalog, bring the workflow your current system will not bend to and I will show you whether ours does, or tell you it does not. Book a demo.