Building rapidly with live prototypes
At strideUX, our design cycles are happening in live builds, then feedback is collected directly in the browser. All of these discussions, ideas and bugs are fed right to our coding agent to fix or build. We move fast with everyone involved and end up with something far more substantial in the end.
Show a client a Figma frame and they'll tell you it looks great. Put the same idea in a browser with a list that actually filters and a drawer that actually opens, and they start finding problems before you've finished the walkthrough. That second reaction is what we want, and we want it in week one.
Most of our product work now starts as a prototype running in a live browser, redeployed on every push, with feedback pinned straight onto it and an agent working the threads. Here's how we build those prototypes and what we hand engineering when it's time to make the real thing.
A prototype you can actually use
Our prototypes are ordinary web applications or front-end websites. We start with a simple stack of tools, frameworks and light dependencies, and the goal is a solid foundation that gets us up and running quickly. Our playbook usually looks like this:
Framework | A React-based framework like Next.js. |
|---|---|
Design language | Tailwind and Base UI, which set up our component library and tokens. |
Database and authentication | Added as needed. They pay off when we're working through schema design or account workflows. |
Git | The standard process of branching, commits and pull requests. |
Deployment | An easy place to host build previews and share them with clients or customers. |
Agent harness | The glue that keeps our agents in sync with our rules, shared skills and project management tooling. |
The whole setup takes very little time. Once it's wired up, we can start molding the clay. From there, the browser becomes our canvas. We can open any door, explore any flow or tackle any UX problem.
Design tools still have a seat
We didn't throw out tools like Figma. They still have a place at the table, especially for exploring design challenges internally. The difference is that stakeholder discussion no longer happens in a Figma file or across canvas frames. We have a lot to say on this topic and will post about it here soon.
Feedback that lives on the right surface
The browser window. The one place everyone ends up day to day. But a live URL to a prototype still has its challenges. Feedback scatters fast, and we learned that early. Between Slack DMs, Google Docs and email, things get out of hand. So we use Skyelight (we wrote up how we built it), which lets people pin comments directly onto elements of the running page. That gives our team and our coding agents clear classification and organization.
This has been a game changer for collaboration and fits right into our coding agent workflow. Bugs, ideas and feedback get addressed, and Skyelight keeps the threads updated.
When a client can click through the real thing, confirm, discuss or educate, the hard questions show up while they're still cheap to answer. By the time engineering picks it up, most of the debate is already settled and written down.
The handoff is a skill
The old handoff was weeks of back and forth, then finally a design file and a long meeting. At strideUX, our handoffs have evolved. Now we deliver a design package an engineering team's agent can load. It carries detailed documentation of the UX, not just the pixels.
Here's what goes into the package:
README.md and ground rules | What's in the package, where to start, and the non-negotiables. |
|---|---|
Behavior first | Always spec what things do. When the look is part of the deliverable, include the visual spec too: tokens, type, spacing and states. When it isn't, say so and let the team use their own design system. |
Information architecture | Every region, drawer and dialog, and what each one does. |
User flows | Step by step: what the user does and how the app responds. |
Component and interaction rules | The detailed behavior for the trickier pieces. |
Data contract | The entities the UI assumes, what's derived, and which numbers must always agree. |
Decisions log | Why things are the way they are, plus what was tried and removed. |
Acceptance checklist | Testable checks for each phase. |
Prototype map | Where each piece lives in the prototype code, and what's fake or unfinished. |
Screenshots | Every key state, captured from the prototype. |
SKILL.md | So coding agents build to the same spec as the team. |
What changes when the prototype is the spec
The biggest shift isn't speed, though we are faster. It's that the arguments happen earlier.
That's why the decisions log might be the most important file in the package. A prototype shows what we landed on. The log shows what we tried, what the client pushed back on, and why it's gone. Without it, the same ideas come back in sprint three and everyone has the conversation again.
The handoff doesn't end the conversation either. The engineering team's agent reads the same rules ours did, so when something isn't covered, it asks instead of guessing. The whole point is that nobody should have to reverse engineer intent from a screenshot.
If your team is still handing off static files and hoping the build matches, we'd love to show you what this looks like on a real project.