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 is an admin’s job in Lightning App Builder, but it needs an org, a licence and a login to share, and every change is a ticket for whoever owns that org. A design tool with a Lightning kit clicks well enough, but the kit drifts from the current release, so the approved design and the delivered page never quite match, and the spec is written twice. 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: the real components, and an admin can build a record page in Lightning App Builder in an afternoon; but it needs an org, a licence and a login to share, and every change is a ticket for whoever owns the org
• A design tool with an SLDS kit (Figma prototypes, the Justinmind SLDS kit): clickable and quick to sketch; but the kit drifts from the current SLDS release, so the design and the delivered page never quite match, and the spec is written twice: once in the design, once for the developer
• A general AI chatbot (ChatGPT, Claude, Gemini): good at drafting the story and the acceptance criteria; but it cannot draw the page in the real Lightning components, nothing it produces can be clicked, and there is no share link or export
• A process-mapping tool (Elements.cloud, Lucidchart): strong on the process, and Elements.cloud on org metadata; but silent about the screens the process leads to
• SFProto: the real SLDS components, clickable, shareable with a link and no login, the spec written once from the page, and the process flow and the portal in the same project