Should You Really Vibe Code a TMS?

Two weeks ago, Dave Clark, the founder and CEO of Auger — and the former Amazon Worldwide Consumer CEO — posted on LinkedIn about a “wildly productive weekend” he had where he “built a custom CRM that actually fits how we sell.”

Here’s more from his post:

Three things that used to take months happened in 72 hours.

The CRM one surprised me most. We tried configuring an off-the-shelf tool for our cycle. Too many fields we don’t need, missing the ones we do, forces a pipeline flow that doesn’t match reality. Spent more time fighting the tool than using it.

So I just built what we needed. Took a night and a morning.

Then early last week, as this Wall Street Journal headline announced, “Threat of New AI Tools Wipes $300 Billion Off Software and Data Stocks.” As the authors reported, “Investors’ fears that new developments in artificial intelligence will supplant software reverberated through the stock market [on February 3], dragging down the shares of companies that develop, license and even invest in code and systems.”

The market bounced back by the end of the week, but concerns about AI’s impact on software companies linger.

This is the age-old “build vs. buy” question, updated for the AI age — where it’s undeniably easier, faster, and cheaper to develop custom apps via vibe coding.

I’m brought back to a blog post from more than a decade ago — “Is Every Company A Technology Company?” — that was also inspired by a LinkedIn post. In November 2015, Meg Whitman, who was the CEO of Hewlett Packard Enterprise at the time, wrote the following on LinkedIn:

Every Company is a Technology Company

As I’ve mentioned in earlier posts, we’re now living in an era of disruption, what we call the Idea Economy. Companies today can turn ideas into reality in a fraction of the time it took just five or 10 years ago. And it’s no secret that technology is fueling that speed.

Across every industry, IT strategy is now business strategy. Winners and losers are determined by how quickly they can adapt to take advantage of new opportunities or deal with competitive threats.

But does “every company is a technology company” mean that you have to design, build, and support your own technology products and solutions?

In the past 26+ years that I’ve been an industry analyst, I’ve come across some success stories of companies developing their own solutions, and I’ve come across many more horror stories. This has been particularly true in the third-party logistics (3PL) industry (see DHL-DP and its costly failure of developing a New Forwarding Environment system).

The decision for companies (especially 3PLs) to develop their own solutions has historically been driven by two factors that are inherently linked:

IT as a Competitive Differentiator: Having the ability to offer customers different and more targeted and enhanced functionality than their competitors, such as better visibility and business intelligence tools. Here is how one 3PL put it to me many years ago: If we and most of our competitors are using the same transportation management system (TMS), how do we truly differentiate when we’re all offering essentially the same capabilities?

Faster, More Responsive Innovation: Having full control of the innovation cycle versus being at the mercy of a software vendor’s release schedule. Simply put, when new functionality is required, either by a customer or an internal request, companies want to enable it as quickly as possible. In many cases, developing the functionality in-house is faster than submitting a new feature request to a third-party vendor and keeping your fingers crossed that it gets included in the next release, which could take six months or more.

Of course, we’re a long way from 2015 when I wrote that Meg Whitman inspired post, and a long way from 2018 too when I wrote a follow-up post titled, “Supply Chain Innovation Technology: No Longer Just A ‘Build Vs. Buy’ Decision,” where I wrote the following:

When it comes to acquiring technology to drive supply chain innovation, there is no single correct path to take, and in some cases, a hybrid of different approaches is the best path forward. Regardless of which path you take, however, the key is understanding upfront the critical factors for success — the pitfalls to avoid, the hurdles to overcome — and making the necessary investments in time and resources to make it work.

To put it more simply, just because you can vibe code a CRM or a TMS over a weekend, it doesn’t mean you should.

Retailers are learning a similar lesson about providing logistics services — just because they have the infrastructure and technology to do it, doesn’t mean they should become 3PLs (see American Eagle Outfitters and its $350 million bet).

All that said, it is also true that AI will transform the enterprise software market. The traditional model of users dependent on software vendors and external consultants to configure or extend solutions will eventually break down, as users — especially those with non-technical backgrounds — can code what they need just by typing or speaking their requirements to an AI tool.

(I know it takes more than that to develop, test, and roll out new functionality on an enterprise scale, but it’s an order of magnitude faster, easier, and less expensive than just a few years ago).

In short, two things can be true at once. If you’re a manufacturer, retailer, distributor, or even a 3PL, vibe coding an enterprise solution like a TMS is probably not the smartest use of your time and resources.

But if you’re a TMS — or any other enterprise software vendor — the stakes are very different. If you’re not empowering customers to drive more of their own innovation, and rethinking your pricing and business model accordingly, you’re going to run into rough waters. The value is shifting from who builds the most features to who enables the fastest, safest, and most scalable innovation.

AI doesn’t eliminate the build-vs-buy decision. It fundamentally changes who gets to build and how much friction stands in the way.

Source: Talking Logistics