A Salesforce prototyping tool for the people who write the requirements

Why prototype Salesforce before you build

A record page mocked up in a sandbox takes a developer days and still cannot be shared with a stakeholder who has no login. A design tool with a Lightning kit drifts from the real components, so the approved design and the delivered page never quite match. A slide deck cannot be clicked. Prototyping with the actual Lightning Design System closes those gaps: the stakeholder clicks through the page they will get, the analyst refines it in the meeting, and the developer receives the same page as a specification.

What you can prototype

• Lightning record pages, home pages and app pages: highlights panel, Sales Path with Guidance for Success, record details, related lists, activity timeline and Chatter
• Screen flows, modal dialogs, toasts, dynamic actions and custom components a reviewer can click through
• Experience Cloud (LWR) portals: help centres, partner portals and customer account sites with one brand across several pages
• The process flow around the screens — swimlanes, decisions and Salesforce shapes — with steps that open the prototype page they lead to
• Both Salesforce looks: SLDS 1 and SLDS 2

From user story to prototype in minutes

Describe the page as you would to a developer, paste the Jira story with its acceptance criteria, or drag SLDS components in by hand. The AI asks about anything the request leaves open — what a button does, when an action is visible — then builds the page, and each change is another sentence. Attach a wireframe, a Figma export or a screenshot and the page is built to match it.

Faithful to Lightning

Pages are rendered with the Salesforce Lightning Design System (SLDS 2.264), not an imitation of it: the same record layout, path chevrons, form fields, related-list tables and modals. Standard objects such as Opportunity, Case, Lead, Account, Contact and Quote come with realistic sample data; custom objects get their own icon. Nothing connects to a Salesforce org, so nothing you draw can touch real data.

Then hand it to the build team

• A user story and Gherkin acceptance criteria (Given / When / Then) for the Jira ticket
• A data dictionary: API names, field types and required flags
• Lightning page metadata and Lightning Web Component scaffolding (.html, .js, .js-meta.xml, .css)
• The page as JSON, and a share link or an embed for Confluence, Jira and Notion
• A Model Context Protocol (MCP) server, so Claude Desktop, Cursor and Windsurf can build, read and export pages

How it compares

• A sandbox or developer org: real components, but a developer builds it, it cannot be shared without a login, and every change is a ticket
• A design tool with an SLDS kit: quick to sketch, but nothing clicks, the kit drifts from the current release, and the spec is written twice
• A diagramming tool: good for the process, silent about the screens
• SFProto: the real components, clickable, shareable with a link, and the process flow and the portal in the same project