October 28, 2026

    AI Can Build Your Inventory App. Can It Run It?

    AI can build an inventory app fast. Running one — POs, warehouses, recalls, accounting — is the real job. What SAP's CTO gets right for distributors.

    AI Can Build Your Inventory App. Can It Run It?

    Every few weeks someone announces that SaaS is dead. The argument goes like this: AI can now write software, so why pay a monthly fee for an app you could generate in an afternoon?

    I build an inventory platform, so I have an obvious stake in the answer. I'll say that upfront. What made me sit down and write this was an interview The Rundown ran with Philipp Herzig, the CTO of SAP. SAP has an even bigger stake than I do, and the newsletter pointed that out. But his core argument is one I agree with, and I think it matters more for a 30-person distributor than it does for SAP's customers.

    Building an app is not running one

    Herzig's point is that the narrative mixes up two different things: generating an application, and being responsible for running it. His example was an expense app. Building one is easy now. Running it across 40 countries, with tax rules that change and reimbursements that have to reconcile, is not.

    Inventory works the same way. Ask an AI to build you a stock tracker today and it will. It will have products, quantities, maybe locations, and it will look fine on day one.

    What it won't have is everything that happens after day one:

    • A purchase order that arrives half complete, with the rest due next month
    • A transfer between two warehouses that is in a truck when someone counts stock
    • Two people adjusting the same item at the same time
    • A recall where you need every unit that shipped from one batch, today
    • A warehouse team working in Bulgarian while head office reads the same numbers in English
    • An accountant who needs the stock value to match what's in QuickBooks or Xero

    Each of those is a rule someone has to design, test, and keep working when the business changes. That is the actual job. The screens are the easy part.

    To be fair to the other side: we use AI coding tools heavily to build AssetBlaze. It's a big part of how a small team ships what we ship. So I'm not arguing that AI doesn't change software. It changes who can build it. It doesn't change who is responsible when the stock number is wrong.

    The real risk is an answer that sounds right

    Herzig calls the riskiest kind of AI output "fluent-but-wrong". The answer is confident, well phrased, and blind to how the business actually works.

    Here's the inventory version. You ask an AI whether you have enough of a part to fill an order. If it's reading a spreadsheet, it adds up the column and says yes. It doesn't know that 40 of those units are reserved for another customer, 20 are on hold for a quality check, and the column still includes a location you closed last year. The answer sounds right and is wrong. You find out when the customer calls.

    His fix has two parts. Give the AI a map of what the data means, so it stops guessing. And make sure it acts with the user's permissions, with a person approving anything that matters.

    That's how we approached AI in AssetBlaze. The AI works against a structured system with defined fields, statuses and rules, not a loose pile of files. It never writes to your data directly. When it prepares something like a purchase order, it comes back as a draft, and a person decides whether it goes.

    He also suggests a simple test, and I'd recommend it whatever tool you're looking at. Feed the AI inputs your real system should reject, like an invoice with no currency. For inventory, try a purchase order with no supplier, or a negative quantity. See what it accepts. I believe that tells you more about a tool than any sales call will.

    From clicking screens to just asking

    SAP's newest product, Joule Work, flips how people use business software. Instead of learning which screen to open and which button to click, you say what you want and the system pulls it together. I think Herzig is right about the direction. For decades, software made people learn its menus. That is ending.

    The catch for most businesses is that Joule lives inside SAP. Most of the companies we talk to are never going to run SAP, and they shouldn't. But many of them already use ChatGPT, Claude or Copilot every day.

    So for them the question isn't which vendor's assistant to buy. It's whether the assistant they already use can talk to their inventory safely.

    That's why we built an MCP server. MCP (Model Context Protocol) is an open standard for connecting AI assistants to business tools. You connect the assistant you already have, and you can ask it what's running low, which stock hasn't moved in six months, or what's available to promise for a big order. It can draft the purchase orders too. They wait for your approval.

    Where AI actually pays off for distributors and manufacturers

    This was the part of the interview I found most useful. Herzig points out that in businesses where people are the main cost, faster writing and research turn straight into margin. But in businesses that carry assets and stock, better forecasts matter far more than faster emails.

    That describes every distributor and manufacturer I know. An AI that drafts nicer customer emails is fine. An AI that stops you tying up cash in stock that sits on a shelf for nine months is worth a lot more.

    He also made a point about trust that I agree with completely. SAP's forecasting models show which inputs drove a prediction and which past records it was based on, so a finance person can check the reasoning. A forecast you can't check is a forecast nobody follows. A purchasing manager will act on "reorder 400 units" when they can see why the number is 400. That's the bar we're building toward with our own forecasting.

    So should you just build it yourself?

    Honestly, sometimes yes. If you have 50 products, one location, one person updating stock, and someone technical on the team, an AI-built tracker might do the job. The same way a spreadsheet does the job at that size.

    It stops doing the job when a few things show up together:

    • More than one location, or stock in transit between them
    • More than a few people touching the numbers
    • Suppliers on purchase orders and customers on sales orders
    • Batch or serial numbers you need to trace
    • Stock value that has to match your accounting

    At that point you aren't building an app anymore. You're signing up to maintain a system. A useful question: who fixes it at 6pm on a Friday when the counts don't match?

    One last point from the interview applies whatever you choose. Herzig said the hardest part of AI at SAP wasn't the technology, it was adoption. People trusted new tools when a colleague they already respected used them first. A warehouse is no different. Pick one real problem to solve first, and put the person your team already listens to in charge of it.

    SaaS isn't dead. Typing is getting cheap.

    The part of software that was mostly typing is getting cheap, fast. The part that is responsibility, keeping the numbers right while the business changes underneath them, isn't. That's the part we sell, and I think it's the part that's worth paying for.

    If your spreadsheet (or the tracker someone built over a weekend) is starting to cost more than it saves, try AssetBlaze free.

    Sources