One pure decision function
decideFor() takes settings and a visitor and returns an answer, with no cookies or waiting inside. The real site, the previews and the crowd all call the same function, so they can never disagree.
How this site actually works.
I'm Ava. I run Simply Devign, where I build websites for brands and creatives on Shopify, Squarespace, Webflow and custom code. I built this site to show how I think about changing a live website safely: who sees what, how to roll out slowly, and how to undo a mistake in one click.
- Next.js 16
- React 19
- TypeScript
- Server Actions
- Route Handlers
- Proxy
- Suspense
- Hand-written CSS
- Netlify
What happens when you load a page
- 1
You arrive
proxy.tsruns before anything else. It gives you a visitor ID and works out whether you're new or returning, on a phone or a laptop. - 2
The page asks
Everything that can change, from the theme to the headline, asks one function what to show:
decideFor(). - 3
The answer runs a funnel
Is the switch on? Is the option valid? Are you in the audience? Are you inside the rollout? Fail any step and you get the default.
- 4
The page streams in
The default version shows instantly while your version is worked out, then swaps in. Most visitors never notice.
Decisions I made, and why
Previews run the real logic
The four previews and the 100 dots aren't animations. Each one is a pretend visitor run through the exact code that decides what real visitors see.
Stable buckets
Your visitor ID is hashed with each switch's name into a bucket from 0 to 99. Same visitor, same experience every time, and each switch rolls out independently.
Cookies, not a database
Every visitor gets a private sandbox, so anyone can play without breaking the site for someone else. The trade-off: your settings don't follow you to another device.
Forms that work without JavaScript
Every switch is a plain form powered by a Server Action. Less code shipped to the browser, and the Control Room works before the page finishes loading.
The URL remembers
The open switch lives in the address bar, like /lab?s=site_theme. No client state needed, the back button just works, and you can link straight to a switch.
Never trust a link
Shared setups are packed into the URL, so anyone could edit one by hand. Every value is checked when it's unpacked, and anything invalid falls back to a safe default.
Defaults as fallbacks
Each switchable section is wrapped in Suspense with the default version as its fallback. The page is fast for everyone, and nobody sees a blank space.
Where it breaks
- Switch settings live in one browser. Real tools store them on a server so a whole team shares them, with a log of who changed what.
- With a theme on, the page can flash the default colors for a split second before the theme streams in.
- Opening a shared link replaces your own settings. Real tools keep shared previews separate.
- The crowd is 100 pretend visitors, so it shows how rollouts work, not real traffic.
- "Returning" means first seen over 30 minutes ago. Good enough for a demo, rough for real targeting.
What I'd build next
- Apply themes before the page is sent, so there's no flash of default colors.
- Move settings into a database so they're shared, with a change history and undo.
- Roll back automatically when errors spike, instead of waiting for someone to click.
- Run a real A/B test on the site's buttons and show live results in the Control Room.