- Case Study
- Design Process
- AI Workflow
- Prototyping
- Product Design
From sprints to sandbox: an AI-native design workflow
How the vergleich.ch team went from two weeks to three days per validated solution.
- Company
- Pixelplan
- Product
- vergleich.ch network: 55 Swiss comparison platforms
- Focus
- Design workflow, AI tooling, prototyping, handoff
- Tools
- Claude, Figma, automated regression tests
- Year
- 2026
TL;DR
I replaced a sprint-based design and handoff process with a working prototype that I build and run with Claude. Every new feature lives in a sandbox layer on top of the approved product and moves through Draft, In review, Approved, and Live inside the prototype itself. The client tests real behaviour and approves in the session. Time from brief to a validated solution went from two weeks to three days.
Context
The vergleich.ch network is a family of 55 comparison platforms, from lawyers and dentists to garages, caterers, and driving instructors. Each one serves two audiences: people looking for a provider, and the businesses that manage their own entry.
The platforms share one product, but not one shape. Dentists show a team and a warranty, driving instructors list courses and vehicle categories, and many trades have no services filter at all. A single change can play out 55 different ways.
This case is not about a feature. It is about how the work gets done.
The problem
A two-week loop for every decision
Design ran on sprints: research, flows in Figma, a clickable prototype, a review with the client, then handoff with specs. It worked, but it no longer matched the speed of the product or the tools available. In practice:
- Prototypes showed one path on one platform. Edge cases across 55 tenants only appeared once development started.
- The client reviewed pictures of the product, not its behaviour, data, or states.
- Handoff could not document every state, so developers came back with questions about things that were never specified.
- Every round of feedback restarted the cycle, at roughly two weeks per validated solution.
The constraint was the process and its tools, not the team. So I changed the process.
My role
I defined the new way of working and own it end to end, with Claude as my production partner:
- Designed the workflow and its rules: what is approved, what is being explored, who moves it forward
- Built and maintain the prototype with Claude, from Figma, the live sites, and the staging environment
- Designed the Live / Sandbox model and the status tool that lives inside the product
- Run client validation directly in the sandbox and approve features in the session
- Hand off from the working prototype, with decisions and open questions recorded per feature
Process & key contributions
01Same brief, a different loop
- Rationale
- Speed comes from removing hand-overs between steps, not from rushing them.
- Action
- Collapsed flows, prototype, and specification into one artefact: a working prototype
- Moved client review from scheduled sprint reviews to the moment a change is ready
- Kept Figma as the source for visual decisions, and the prototype as the source for behaviour
- Outcome
- Each solution now goes through build, test, and approval in days instead of a full sprint.
02A prototype that behaves like the product
- Rationale
- Validation is only as good as what people are able to test.
- Action
- Built a high-fidelity HTML prototype with Claude, rebuilt page by page from Figma and the live platforms
- Read each tenant’s real profile from staging, so all 55 platforms show their own filters and sections
- Covered both personas (end user and business), on desktop and mobile
- Outcome
- The client tests real behaviour, data, and edge cases, not mockups. Problems surface in review, not in development.
03Live and Sandbox
- Rationale
- Explore freely without putting what is already approved at risk.
- Action
- Live is the approved baseline: what the client has signed off
- A sandbox feature is a layer on top of Live, not a copy of pages. It patches a component slot, so every page that uses it changes together
- Fixes made in Live keep flowing into every sandbox feature
- Each feature applies to all tenants or only to selected ones, and “Show changes” outlines exactly what it alters
- Outcome
- Several features are explored in parallel on the same link, without branches, duplicated files, or drift from the approved product.
04Status inside the product
- Rationale
- Approval should be part of the work, not a separate email thread.
- Action
- Every feature moves through Draft, In review, Approved, and Live inside the prototype
- “Promote to Live” turns the sandbox patch into the new baseline, and it can be undone
- Each feature has its own link that opens the prototype straight on it
- Outcome
- The client opens the link, tests the feature in sandbox, sees each iteration, and approves on the spot.
05Quality gates on every version
- Rationale
- Moving fast only works if nothing breaks behind you.
- Action
- Automated regression tests across all 55 tenants and both personas before every publish
- Visual checks on desktop and mobile after every change
- One stable link across around sixty versions, so the client is always on the latest
- Outcome
- No broken platform reaches a review, and nobody works from an outdated file.
06Handoff from the working thing
- Rationale
- Developers need behaviour and states, not a description of them.
- Action
- Each feature is documented as decisions and open questions next to its sandbox version
- Developers inspect the real flows, states, and empty states instead of reading specs
- Assumptions are flagged as assumptions until confirmed against the source
- Outcome
- A shorter handoff with fewer gaps, and far fewer back-and-forths about undocumented details.
Outcomes & impact
- 14 → 3
- days per validated solution
- From brief to a solution the client has approved
- 55
- platforms checked per change
- Every tenant and both personas, before each publish
- 4
- states, inside the product
- Draft, In review, Approved, Live
- 1
- link for every version
- Client and developers always see the latest
What changed in day-to-day work:
- Iteration happens directly in the product, not in a design file that has to be translated later
- Validation has no prototype limits: real data, real states, every tenant
- Decisions close in the session, because the client approves what they just tested
- Handoff is shorter and leaves fewer gaps, with far less back-and-forth with developers
The deliverable is no longer a picture of the product. It is the product’s behaviour, with a status.
Why this matters
AI did not replace the design decisions. It removed the distance between a decision and the evidence for it. What stayed with me:
- Framing the problem and setting the rules of the workflow
- Judging the details: spacing, hierarchy, wording, what a state should say
- Rejecting invented behaviour, and confirming every assumption against Figma, the live sites, or the client
Claude builds, tests, and documents at a speed no sprint can match. I decide what is right.
Final reflection
The biggest change was not speed. It was where the conversation with the client happens: on top of something that works, at the moment it is ready, with a clear status.
This workflow is now how I approach product design: design in the product, validate in a sandbox, promote what is approved.