The comparison names what it compares, not whom: four routes to a UI5 app on SAP, row by row

src/pages/faq.astro

@@ -29,6 +29,13 @@ const faq = [
     ["Can we port our heavy SAP GUI transactions?", `One screen at a time, yes; the logic behind it is called as it is. Where abap2UI5 is weakest is a transaction that needs the server to hold its state for minutes: a long multi-step dialog with locks held from one click to the next. Every click is one request, and the app instance is rebuilt from a server-side draft each time, so nothing is held in between. A stateful session mode exists for the few cases that need it, at a cost: it pins one work process per user and is not available on S/4HANA Cloud Public Edition (<a href="${DOCS}cookbook/expert_more/statefulness">Statefulness</a>, <a href="${DOCS}cookbook/expert_more/lock">Locks</a>). The usual path is one screen per task, each click a short request.`],
     ["Our clean-core guideline names RAP. Where does this leave us?", "Side by side. abap2UI5 passes the ABAP Cloud checks and modifies nothing in the standard, so it is clean core in the technical sense, but it is not SAP's programming model. The usual outcome is a scope: standard transactional screens in RAP, the tools around them in abap2UI5, both in one launchpad."],
   ]],
+  ["Compared with the market", [
+    ["What are the commercial tools for building UI5 apps on SAP, and how does abap2UI5 compare?", `Two kinds. A <b>low-code builder installed in your SAP system</b>: a vendor's designer, delivered as an add-on or a transport, where the ABAP team clicks screens together, binds them to ABAP classes, and the vendor's runtime builds and deploys a UI5 app per screen. And a <b>low-code platform beside SAP</b>: a server or cloud tenant of its own that reaches SAP over connectors, built for citizen developers. What they offer that abap2UI5 does not: a drag-and-drop designer for people who do not write code, templates, a vendor with a contract and an SLA, often an SAP certification, and sometimes a client of their own with offline. What they cost: a subscription per user, device or developer, monthly or yearly, usually with a minimum term and a setup fee, and the screens live in the vendor's tables and run only on its runtime. abap2UI5 differs on four points: an app is one ABAP class, not configuration; there is no license and no runtime fee; the same source runs from NetWeaver 7.02 to ABAP Cloud, where the builders start at S/4HANA or depend on the vendor; and every line is open. The table under <a href="${base}#when-to-use-it-and-when-not">Compared with the market</a> holds it row by row.`],
+    ["Why is no vendor named on this page?", "Because offers, prices and release coverage change faster than this page would, and a comparison that is wrong about one vendor discredits the rest. The columns describe what you would buy; the vendor's own page is where to check a figure, and the claims about abap2UI5 link to the place that proves them."],
+    ["A department wants to build its own screens, without a developer. Is this the tool?", `No. abap2UI5 is a tool for the ABAP team: an app is code, reviewed and transported as code, and that is what keeps it inside your development process. Where the business is to click screens together itself, a low-code designer is the tool, with the governance it brings along. What abap2UI5 offers that department is the <a href="${DOCS}get_started/ai">AI App Builder</a>, which writes a first class from a description; a developer reviews and transports it.`],
+    ["SAP generates Fiori apps with AI now. Why would we still need this?", "SAP's generators produce the standard app: a RAP service and a Fiori Elements project from a description or a mockup, with a BTP subscription and a deployment attached, and where the standard list report or object page is what you want, that is the shorter path. abap2UI5 is for the screen the standard does not cover: an AI writes one ABAP class into the system you have, and a developer reviews it as code. Both end as tiles in the same launchpad."],
+    ["What if a commercial platform is discontinued?", `It happens to paid products too: SAP withdrew its own no-code app builder as a standalone product in March 2026 (<a href="https://help.sap.com/docs/build-apps/service-guide/sap-build-apps-path-forward">SAP's notice</a>), and the apps built with it needed a migration path. With a builder that stores screens as configuration, the screens stop with its runtime. With abap2UI5 the source is in your system and the apps are plain ABAP classes; what happens if this project stops is answered under <a href="#risk-and-support">Risk and support</a>.`],
+  ]],
   ["Team and skills", [
     ["Our ABAP team is small and getting older. Can we take on a new UI technology?", "You are not taking one on. The UI is one more ABAP class, written by the people who write the rest, in the tools they use today, with UI5's controls learned from running examples in hours, not weeks. No JavaScript developer to hire, no full-stack profile to find, no training project before the real project. One honest clause: a control that needs JavaScript of its own, a chart library or a custom control, needs one person who reads JavaScript; everything else is ABAP. And an AI assistant writes a first version of such a class whole, which is exactly where a small team gains the most."],
     ["How do our developers learn it, and how long does it take?", "From running examples, not from tutorials that aged. The catalogue holds hundreds of samples, each one opens in the browser and each one is maintained with the framework, so none goes stale. The quickstart takes minutes: pull, one endpoint, the first screen is up. Within hours a developer builds a first real app, and within a week the screen your team needs this quarter, with the people who will maintain it. What a developer learns is UI5's controls and their properties, in ABAP, not a new language or a new toolchain."],