StripeWhat they did
Bruno Azevedo and Henrique Leite inherited three undocumented OutSystems applications for their Stripe integration and needed to add a monthly subscription with a free trial, billing portal and prorated refunds. They connected Claude to their ODC tenant through the OutSystems MCP server, which offers read tools, write tools for publishing and deploying, and access to Mentor, OutSystems' own AI developer. Claude first read the apps read-only, followed their references and asked Mentor to describe the logic flows it could not read directly. Then it wrote a spec, worked through open questions with the team, and drove Mentor turn by turn to build the feature. Every change to the tenant waited for a human to approve it. At the end they asked Claude to review Mentor's work.
How it went
Within an hour Claude produced an inventory, a reuse plan (three pieces worth keeping), three architecture options and a build plan, and flagged likely bugs nobody knew of, such as an action that deletes any saved card and a callback that logs card secrets. The build took 27 Mentor turns and about 81 minutes of Mentor time: a service app, a test store, an extended Stripe library and a C# webhook signature library with 19 tests. One turn ran 34 minutes, Mentor added a dependency it was told not to, and library releases had to be checked by hand. Claude's review found four bugs in the money path, including a refund prorated twice. Nothing has run end to end against Stripe test mode yet.
Worth knowing
The authors rate the mapping and planning as the real win and the building as needing close supervision. A finished Mentor turn is not proof: check the deployed revision, the version tag and the runtime logs. Clean validation did not catch the worst bugs. They kept a human yes on every tenant change and found it cheap. App names in the write-up were changed.