SAP Build Apps is no more
SAP Build Apps is deprecated, or better: is no more. From the kiss of death blog post 🔗: “As of 23rd of March 2026, SAP Build Apps will be retired.” Followed by the usual corporate speak about roadmap, future, honoring contracts, and so on.
That SAP Build Apps is not going to survive should not be a big surprise. From the SAP Build product range, it was the one that struggeled the most in finding a use case. When SAP bought AppGyver I was already sceptical about the why (“My guess is that AppGuyver is going to vanish over time and that SAP is interested in their knowledge”) 🔗. Over the years, the positioning problem was never really solved. How to get the low-code/no-code tools work together with the existing customer landscape? Same precedure as last year 🔗, The SAP developer transformation 🔗,Sapphire 2023 AI proven keynote 🔗. The biggest problem of APIs 🔗 was never solved. AppGyver was never the go-to tool for developers, albeit this is needed to solve the API problem. It is not part of the SAP Development Tech Radar 🔗. The possibility of including it in the radar was even part of the announcement article 🔗. However, no one cared to add it. It was not even mentioned as a missing technology in one the many personal discussions I had regarding missing technologies.
MCP as the new low-code, no-code tool for end users
Is this now the end of LC/NC in general? No — definitely not. In fact, what these LC/NC tools promised is now being solved by MCPs. Agentic ERP is the new LC/NC tool of choice for end users. It’s just that this time, they don’t need to build everything from DB access to APIs to a working UI. The MCP server abstracts this away, and they can work directly with the data.
An MCP server does not need an API to connect to an SAP ERP system. It does not care whether the system is S/4HANA, ECC, or R/3, or whether it’s in the (private) cloud or on-premises. If the system can be reached, the data and information can be reached. If the connection is done via RFC, maybe even better — because then, suddenly, all those features are available. Reading a database table? Calling a function module? BAPI? Report? Possible. As long as the returned data can be processed, the end user is happy — an ERP system reduced to serving the information needed.
It should not be a big surprise if the end of AppGyver, or SAP Build Apps, is driven by SAP’s desire to focus more on Joule and on how end users can get the same access to information. The problem, though, is that for Joule you need to be a cloud customer. And while you needed some cloud account to work with SAP Build Apps, the backend could still have been an on-premises system. For MCP server offerings from partners — or MCP servers developed in-house by customers — this is not a requirement.
A surprising Kiss of Death
Seeing the deprecation announcement should not have been a huge shock for everyone. Maybe when you build your career around it, it is. But then: who did? I admit that I came across SAP Build Apps a few times, yet only for POCs or high-level evaluations—never for a real-world app. And personally, I don’t know anyone who went all-in on SAP Build Apps.
The biggest surprise of the announcement is its timing. The blog post was published on Monday, 23 March 2026. The retirement of SAP Build Apps is effective as of 23 March 2026. That’s the very same day. I have seen quite a lot of things from SAP in my life as a consultant over the last decades, but this short notice is something I never, ever imagined I’d see from SAP. From Google? OK, that’s standard over there, where people struggle to understand how companies work. But from SAP? Normally, this is announced months — if not even years — before the retirement takes effect.
Maybe last week someone was still trying to get a business case for buying an SAP Build Apps license? Well, talk about a ruined Monday — or career. That SAP is retiring solutions, optimizing its portfolio, and doing things that go beyond rebranding: fine, if not perfect. But give us time. Even when nothing changes for customers and support is offered for months to come, announcing the end of a product takes time to process. It takes time to adopt a product, and it takes even longer to replace it. Even when the current contract is honored, people now have to look into the contract to find out when it ends. What about the ones who find out that their contract ends in a few months? Sure, that might be an edge case. But just give customers and partners time.
Why not announce: in six months, SAP Build Apps will be retired. From today on, you can’t license SAP Build Apps (exceptions might be granted), and for the next six months, your contract will be honored. It might have the same effect, but it gives enough time to adjust to the change.
Trust is an asset
A lot of the premium pricing customers are willing to pay comes from the trust they have in SAP not to abandon them. Currently, a significant share of customers is being left behind by SAP’s strategic decision to offer AI only to cloud customers. SAP is willingly eating up a good portion of trust that was built over decades.
Regarding product roadmaps and planning, this is an area SAP still excels in. SAP announced the sunset of Neo 🔗 for December 31, 2028, in 2023. HANA XS is classic and has been superseded by XSA for over 10 (or so) years. The end of Web IDE 🔗 was announced with the Neo sunset. In these cases, it was possible to give customers not only a heads-up, but also more than enough time to adjust their solutions and landscape.
Why not for SAP Build Apps? Why the hurry? Are the teams leaving SAP? Is there a knowledge drain? Is everyone eager to join some cool, fancy AI team? Or is the number of SAP Build Apps customers so low that only a handful of people are affected?
Citizen developer
With the end of SAP Build Apps, the term “citizen developer” might be dead, too. The idea behind it, however, will live on. Agentic ERP, MCPs, AI, LLMs—all of this is filling the space of the citizen developer. Congrats to everyone involved in the AppGyver deal. I guess those are the only ones who got a good cut from the product. Everyone else—be it consultants who bet on the product or customers—take care, and keep in mind: try not to follow the latest SAP marketing. Stay curious, but also cautious.