Build versus buy in AI gets discussed like it is a clean strategic framework. Build if you want control. Buy if you want speed. Compare the tradeoffs, make a decision, move on and that is not how I came to it. SiteTrax.io exists because we tried to buy first.
We did not set out to build a platform because we were looking for a grand theory about computer vision, or because we thought the world needed another software company. The original problem was much more practical than that. I wanted to point a camera at assets sitting outside a warehouse door, identify what they were, and know where they were. That was the whole idea. It felt like something the market should have been able to handle. A camera feed goes in, a useful answer comes out, and operations gets a little easier.
Instead, it turned into a lesson in how quickly a simple idea becomes hard once it leaves the slide deck and enters the yard.
Why We Built SiteTrax.io
On paper, the answer seemed obvious. OCR should read the markings. Object detection should identify the asset. Computer vision should do the rest. There were products, demos, and plenty of confident explanations about why this was already more or less solved – then the real world showed up.
Lighting changed. Cameras varied. Labels were worn out. IDs were inconsistent. Assets were dirty. Angles were bad. Weather had the usual lack of respect for software assumptions. The operation behaved like an operation, not like a controlled test environment. And very quickly it became clear that 70 percent accuracy was not good enough. Not when the output was supposed to support real decisions. Not when the missing 30 percent had actual consequences attached to it.
That is why we built SiteTrax.io. Not because I think every company should build. Not because I have some ideological loyalty to custom software. We built because buying failed for the use case we had. That distinction matters, because it shaped everything that came after.
What Building Taught Me About What Not to Build
One of the most useful lessons from that experience was not just that specialized operational problems are harder than they look. It was that building one thing does not obligate you to build everything around it.
Once we got deeper into logistics and supply chain operations, it became obvious that our customers already depended on systems that mattered. They were already running yard management systems, warehouse management systems, terminal operating systems, enterprise resource planning systems, and transportation management systems. YMS (Yard Management System), WMS (Warehouse Management System), TOS (Terminal Operating Systems), ERP (Enterprise Resource Planning), and TMS (Transportation Management System), if you prefer the acronym version the industry never seems to tire of.
Those platforms already ran the business. They held the workflows, the transactions, the history, and the habits the operation depended on. We did not need to reinvent them just because we had found a gap in vision and data capture. We needed to make them better. More accurate. More useful. More valuable to the customers already relying on them.
That is where the partnership mindset came from. We did not need to replace every system of record. We needed to improve the signal flowing into those systems. In many cases, that is the more strategic move anyway. If the market already has a strong solution, buying and integrating is almost always better than spending years rebuilding infrastructure so you can feel more proprietary than you really are.
The DIY Trap Has Returned, This Time Wrapped in AI
That is why the current AI conversation feels familiar to me. A lot of companies are falling into the same do-it-yourself trap, just with newer tooling and more dramatic claims attached to it. They see large language models producing code, completing tasks, reasoning through prompts, and helping assemble systems faster than ever before, and they start talking as though enterprise software can now be created with the snap of a finger. That is the part I do not buy.
The models, progress and leverage is real. But people keep confusing model capability with product capability, and those are not the same thing. A model can be impressive and the system built around it can still be fragile, expensive, incomplete, and difficult to trust in production.
That is where the build versus buy mistake gets expensive. Companies convince themselves they are building strategic AI when what they are often doing is rebuilding plumbing, recreating infrastructure, and delaying outcomes that the business could have started benefiting from much earlier by buying the right solution.
There is a place for building. I know that firsthand. But there is also a point where “we should build it ourselves” stops sounding strategic and starts sounding like a very expensive way to avoid making a harder decision.
The Part People Do Not Understand Until They Pay for It
I have been spending time building and testing agentic systems myself, partly because I want firsthand understanding of where the real boundaries are and partly because I do not trust secondhand enthusiasm very much.
I built a multi-agent, multi-tasking, multi-project, multi-model framework that is still barely into alpha. Getting there cost me more than $4,000 in Claude Sonnet and Opus usage, and I have the receipt to prove it. That does not mean the models are disappointing. It means the hard part is not where people think it is.
Getting a model to do something clever is not the same thing as building a dependable system. The real work starts after the demo. Orchestration. State. memory. Prioritization. Routing. Error recovery. Guard rails. Domain logic. Evaluation. Human review. Trust. The translation layer between an intelligent response and a business process that cannot afford to be casually wrong.
That is why you can get 50 to 70 percent of the way there fairly quickly and still be nowhere near something operationally mature. The next 10 percent is not a little harder. It is often 10 times harder. The next 5 percent after that can be even worse, because now you are trying to make the system hold up under interruptions, bad inputs, edge cases, conflicting goals, and the general chaos that shows up the moment software meets a real operation. We learned that lesson with OCR and object detection. AI is teaching the same lesson again.
Generalist Models Do Not Automatically Create Specialized Software
This is another place where people are getting themselves turned around. The general-purpose models are very good generalists. In the right context, they can behave like specialists. That part is real, and it is one of the reasons this moment is so interesting.
But a strong model response does not magically turn the surrounding software into a specialized, reliable system. That is the leap people keep making, and it is where a lot of the trouble begins.
At a supply chain conference in Long Beach this year, I heard time and time again about all of the “26 year-old tech bros” pitching their AI at an event that has 100 year old companies. Can you tell me that the “26 year-old tech bro” has the proper AI experience and domain expertise to have a direct impact on your business?
Specialized systems require much more than a capable model. They require domain constraints, workflow awareness, memory that matters, approvals, escalation paths, fallback logic, clean handoffs, observability, and integration with the systems where the business actually runs. In supply chain and logistics, they also have to survive field conditions, workarounds, and operational reality, which has a way of exposing weak assumptions very quickly.
That is why I am skeptical of the current tendency to overstate what agentic AI frameworks can already do. There are still critical features missing, including in frameworks like Openclaw, if your standard is not just an interesting demo but a system that can operate responsibly in a real business environment. I am going to save that for a future article when I lay out my five principles for agentic AI, because that deserves its own treatment.
For now, the more immediate point is simpler: just because a model can perform a task does not mean the software around it is ready to own a workflow.
Where I Actually Land on Build vs. Buy
So where does that leave the question? Not in an ideology.
I believe you build when the market truly cannot solve the operational problem in front of you. That is what happened with us. We tried to buy first. It failed. Building became necessary. I believe you buy when a capable solution already exists and your team is about to spend a year or two rediscovering why that category exists in the first place.
And I believe you partner when the customer already has a system of record and your real opportunity is to make that system smarter, more accurate, and more useful without pretending you need to replace it.
That is the lesson SiteTrax.io taught me, and it is the reason I push back on so much of the current AI build-everything narrative. Building is not the prize, owning the right layer is.
The Best Products Hide Complexity
There is one more point here that matters: The best AI companies are not trying to force customers into more complexity because they are doing the opposite. They are absorbing complexity in the background and delivering something simple on the surface. That is how good products usually work especially when the backend is brutal and the experience should not be. That has always mattered to me.
Customers should not have to admire your architecture in order to get value from your software. They should be able to use the output, trust the result, and move on with the rest of their day inside the systems they already need to run their business. That is a more demanding standard than a good demo and it is also a much better one.
Artificial Intelligence Still Needs Human Intelligence
The line I keep coming back to is simple because the mistake around it is so common. Artificial intelligence must be guided by human intelligence, not as a slogan and as an operating discipline.
The models are improving quickly and the market is moving quickly. However, the need for judgment has not gone away. It has become more important, not less, because people are now more likely to mistake motion for maturity. Build versus buy in AI is not really a philosophical debate. It is a judgment call about where the market stops, where your real operational problem begins, and whether the gap between the two is actually worth owning.
That is not the flashiest answer in the world and it is the one I trust.
FAQ: Build vs. Buy AI, SiteTrax.io, and the DIY Trap
What does build vs. buy mean in AI?
It is the decision between creating your own AI system or buying an existing solution from the market. In practice, the better question is usually which layer should be built, which should be bought, and which should be integrated with the systems you already depend on.
Why did SiteTrax.io choose to build instead of buy?
Because we tried to buy first and the market could not solve the operational problem well enough. Existing OCR and object detection systems could not reliably identify assets in real-world conditions across inconsistent cameras, weather, labels, and yard environments. Building became necessary because buying failed for the use case.
Does this mean companies should always build AI in-house?
No. In most cases, buying is the better decision if a capable solution already exists. The mistake many teams make is assuming that because AI tools are moving fast, they should now build systems from scratch that the market has already solved well enough to purchase and deploy.
What is the DIY trap in enterprise AI?
The DIY trap is when a company convinces itself it is building strategic differentiation, but is really spending time and money rebuilding infrastructure, solving already-solved problems, and delaying business outcomes. It often feels innovative while quietly becoming expensive overhead.
Why is the last 10 percent of AI development so hard?
Because getting a model to work is only part of the problem. The last stretch usually involves orchestration, routing, state, memory, exception handling, trust, guard rails, and real-world workflow integration. That is where many projects discover that a promising prototype is still far from a dependable production system.
What is the difference between a general-purpose LLM and specialized software?
A general-purpose LLM can perform a wide range of tasks and sometimes behave like a specialist. Specialized software, however, requires domain logic, workflow controls, integrations, accountability, and reliability inside a specific business environment. The model may be impressive, but the system around it still has to be built properly.
Why not replace YMS, WMS, TMS, ERP, or TOS platforms with new AI systems?
Because those systems often already own the core workflows and transaction history the business depends on. In many cases, the smarter move is to improve the quality of the signal flowing into those systems rather than rebuild the systems themselves. That is where partnership becomes more valuable than replacement.
What are the Four Pillars of AI, and why do they matter in supply chain?
I think about AI like a Roman-style structure. The foundation is good, clean, standardized data. The four pillars are:
- Large Language Models
- AI Agents
- Applied AI
- Analytics.
The roof is AI itself, and it only stands if the foundation and pillars are sound. In supply chain, that matters because people are often tempted to focus on the roof – the exciting AI promise – without doing the harder work underneath. If the data foundation is weak, the AI will wobble no matter how advanced the model looks. That is also why build versus buy is not just a technology question. It is a judgment call about whether your data, workflows, and operating environment are strong enough to support what you are trying to build.
What is missing from agentic AI frameworks today?
Many frameworks still lack the controls, structure, and operational maturity required for real business environments. They may be promising, but there are still important gaps between a compelling demo and a trustworthy system. I plan to cover that directly in a future article through my five principles for agentic AI.
