Just Send the Link

I had to show a customer a prototype last week. Our shared gallery layout wasn't working for them—too few photos visible at once, especially with mixed portrait and landscape shots. They needed proof we were listening.

The safe move would've been a staging environment, a feature flag, a deployment pipeline gated from every other customer. That's what the engineering blogs would tell you to do.

Instead, I added /experimental to the end of a shared gallery URL. One path segment. No feature flags, no migrations, no ceremony.

Feature flags are a whole industry now: SaaS services, Laravel packages, targeting specific users, percentage rollouts. But if you're a solo dev or a small team, that stuff is overkill. I didn't install a package or target a specific user. I just shared a URL.

The solution was stupidly simple: register a new /experimental route pointing to a copy of the Laravel Livewire page component. I copied the existing page, made the layout changes, and that was it. No conditionals, no feature flags. Just a new route.

And because the path was isolated, I wasn't afraid of breaking anything. It lived alongside the real thing like a sketch taped next to the canvas.

Before sending the link, I told the customer: "I've been thinking about improving the gallery layout. This isn't polished, it's an experiment. Be honest. Better to discard it now than spend weeks going nowhere."

I sent the link that Thursday morning. Then I waited.

By that afternoon I had my answer.

The customer didn't love the new layout.

And that was a good thing. It was easy to discard because I'd only spent an afternoon on it. If I had spent a week making it pixel-perfect, getting the spacing just right, I'd have been too invested to see straight. Let alone throw it away.

I used to build something polished, ask for feedback, and get directions I didn't want to go. By then I was defending the work instead of improving it. Every change felt like demolition, not iteration. Now I present early prototypes to test if I'm heading in the right direction, before I burn energy on something the customer doesn't want.

That little disclaimer was doing double duty. It gave the customer permission to be honest. They didn't have to sugarcoat. I already told them it might die.

It also showed them I was listening. Instead of "we're working on it" in an email, I showed them something real within days.

"Better" is hard to define in an email. But with a prototype in front of them, the customer could point at exactly what they wanted changed. And I could test other directions too.

We've made shipping prototypes far too terrifying. We treat rough prototypes like they're broken software. They're not the same thing, and the difference comes down to one word: honesty.

This works best for presentation prototypes: layouts, UI changes, things the customer can see and react to. Prototypes that write to a database need more caution.

You don't need their tooling. A simple if statement is a feature flag. A copied route is a staging environment. For small teams, that's enough.

Tell your customer it's a prototype, it might not survive the week, you might throw it away tomorrow. Then watch how much faster you learn.

Next time you need to show a customer something early, don't reach for a feature flag service. Don't spin up a staging environment. Don't build a deployment pipeline.

Copy your page. Change the route. Send the link. Tell them it's an experiment.

See what you learn by Tuesday.