I Built a Salesforce Clone with Claude in 25 Minutes, Then Verified It End-to-End with Kane CLI in 15

The Experiment: Build Fast, Then Prove It Works

The premise was simple. A generalist coding agent can produce a lot of working software in a short window. The open question is what you actually have at the end: something that compiles, or something a user can use.

To find out, I split the run into two halves and timed each. The build half asked Claude to produce a full CRM. The verify half asked a verification agent to prove, in a real browser, that the CRM did what it claimed. Two numbers came out of it: 25 minutes to build, 15 minutes to verify. The interesting part is not the speed. It is what those 15 minutes surfaced.

Phase 1: Building CRMforce

I asked Claude to build a Salesforce mock clone, full-stack, using the Fable model for the implementation. Instead of diving straight into code, Claude switched into plan mode: it explored the existing repo (a Next.js 15 App Router project with React 19), asked a few clarifying questions, and wrote a plan I could approve before a single file changed.

The decisions that shaped the build:

• Persistence: a local, file-backed JSON store so the app runs instantly with a dev server, no external database required.
• Scope: the full CRM, not a toy. A dashboard plus Leads, Contacts, Accounts, Opportunities, and Tasks, all with full create, read, update, and delete, plus an auth gate, an activity timeline, and global search across objects.
• Isolation: everything lived under a scoped route with its own stylesheet, so it never touched the existing landing page.

Claude owned the architecture and the shared foundation (the data store, the REST API, the auth middleware, the design system), then delegated the six feature pages to parallel Fable subagents, each working from a precise shared contract. It reviewed and integrated their output, fixed two small inconsistencies, and ran a production build to catch compile errors.

What came out the other end:

• A REST API with GET, POST, PATCH, and DELETE across every collection, plus search and auth routes.
• A middleware auth gate protecting the app with a demo login.
• A Salesforce Lightning-inspired UI: a dark sidebar, KPI tiles, a pipeline-by-stage chart, an activity timeline, data tables with inline editing, and a drag-and-drop opportunity Kanban board.

Elapsed time: roughly 25 minutes. The build was fast and, on first inspection, genuinely good. The question was whether "looks done" survived contact with a real browser.

Phase 2: The First Verification Attempt

The plan's final task was end-to-end verification. Claude reached for its own in-browser tooling first (Claude-in-Chrome). To be fair, it worked: it logged in, clicked through the dashboard, and even performed a drag-and-drop on the Kanban board while I watched the column totals update.

But as a verification experience, it left me wanting:

• I could not easily see how the final UI looked without asking for screenshots one at a time.
• The output was long strings of prose describing what happened.
• Screenshots landed in some folder on my machine that I had to go find and open manually.

It was a capable pair of hands driving a browser. It was not a report. There was nothing I could scan, share, or trust at a glance. This is the exact gap a purpose-built verification agent is meant to close.

Note: An AI coding agent can click through a browser, but it cannot hand you a structured pass or fail. Kane CLI can. Try Kane CLI

Phase 3: Verifying with Kane CLI

So I pointed the agent at Kane CLI instead and ran verification as four distinct passes. Kane CLI is a deterministic browser agent: it drives real Chrome from natural-language objectives and emits one JSON object per line, so every step and every assertion becomes machine-readable evidence rather than prose.

kane-cli run "log in as the demo user, go to Leads, create a lead named 'Acme Corp', assert the leads table contains 'Acme Corp', store the new lead id as 'lead_id'" --agent --headless

Direct API Testing

Kane CLI made the HTTP calls itself and asserted on real status codes and response bodies:

• Auth: valid credentials returned 200, wrong password returned 401.
• Full CRUD lifecycle: POST returned 201, and the created record's id was chained straight into the follow-up GET, PATCH, and DELETE calls, each asserted (200, status updated to "Qualified," then deleted).
• Search: returned 200 with hits across accounts, contacts, opportunities, and tasks.
• Negative case: an unknown collection correctly returned 404.

This is a true API lifecycle test, not isolated pokes at endpoints. Chaining a real id from one response into the next is what separates a lifecycle assertion from a smoke check.

Note: Every Kane CLI run uploads to Test Manager and prints a 7-day ShareLink you can drop into a PR or bug report. See a pre-PR UI check in practice. Run a UI check before the PR

The Fix: Build, Verify, Fix, Re-Verify

The visual test found the Kanban overflow, so I fixed it. I switched the board from a fixed-width scrolling grid to six equal columns that shrink to fit the viewport, tightened the spacing, and let long account names truncate gracefully.

Then I re-verified in a real browser: all six stages (Prospecting through Closed Lost) now fit edge-to-edge with no horizontal scroll, and drag-and-drop still worked, with column totals updating live.

Build, verify, fix, re-verify. The loop worked exactly as it should, and verification is what closed it. Without the recorded visual failure, the overflow ships and a user finds it first. This is the same loop an AI coding agent can run on its own once it can call a verifier, a pattern I walked through in how Claude Code and Kane CLI close the loop together.

Kane CLI vs the In-Browser Agent

Both drove a real browser. The difference was what I got back.

One honest counterpoint: the in-browser agent did drag-and-drop better. Its click-drag actually moved a Kanban card and I watched the totals change, whereas Kane CLI cannot reliably automate native HTML5 drag-and-drop. So I used the right tool for that one interaction. Verification is not about a single winner; it is about structured evidence for the 95% of checks that are assertable.

Why I Now Want a Verification Specialist

Building agents are generalists, and that is the point. But verification has a different shape, and after this experiment I want a specialist for it:

• I walk away with evidence I can share, not screenshots buried on my disk.
• It decides pass or fail, so I am not left eyeballing every screen.
• One prompt runs the whole journey (login, CRUD, search) hands-off.
• UI, visual, console, and API checks all live in one place.
• Every run is reproducible and auditable whenever I want to re-check.

The same properties make Kane CLI a drop-in verification step for an AI coding agent or a CI pipeline. Install the skill once and Claude, Codex, or Gemini can call it, read the run_end line, and decide whether to ship or fix. In CI, standard exit codes fail the build on a broken flow, and when the suite is ready to scale it schedules on the KaneAI agentic testing platform across broader OS and geography coverage. Every run in this experiment also landed in TestMu AI Test Manager automatically, so the evidence is not just on screen, it is a growing, auditable test library.

If you want to see the same idea from the terminal side, the walkthrough in introducing Kane CLI covers the agent-mode setup end to end.

The Takeaway

Start here: the next time an AI agent hands you a "finished" app, do not eyeball it, point a verifier at it. Install Kane CLI, write one plain-English objective per critical flow, and let it return a pass or fail with a ShareLink before you review anything by hand. The Kane CLI documentation covers install, agent mode, and CI wiring in a few minutes.

The build in this experiment was fast and genuinely good, and the same loop applies any time you need to test an app Claude built. But the verification is what turned "it looks done" into "here is proof it works, and here is the one thing that did not." A generalist agent can click around a browser. A verification-first agent gives you a report you can act on and share.

Building is fast now. Verification is where you want a specialist. Point your agent at Kane CLI for agentic verification.