ma1or
Joined 1 year ago
Karma
2
Submissions
18
Member since
Aug 5
Recent submissions
Comment · 8 months ago
Comment · 10 months ago
Your tool might actually do more than you planned.
When I started building Replay, the mission was specific: Behavior-Driven UI Reconstruction. I wanted to solve the problem where static screenshots fail to capture the flow, animations, and logic of a complex SaaS or mobile app.
But I got curious: "What happens if I feed the engine a video of a physical product instead of a digital interface?"
I grabbed a pack of wipes, recorded a 5-second clip, and dropped it into the pipeline.
The result? Watch the video.
Even though this isn't Replay's core function, the engine "understood" the product. It extracted the color palette, the brand vibe, and the context-generating a fully responsive, sales-ready Landing Page in one shot.
It turns out that Video-to-Code isn't just about UI flow; it's about context.
I am still laser-focused on polishing the core engine and shipping new features, but seeing the tool handle edge cases like this is the best part of the founder journey.
If you are curious to see what Replay looks like right now: Link to the tool in the first comment.
Comment · 10 months ago
I'm the founder of Replay. We've been working on a "video-to-code" engine that uses Gemini 3 Pro to analyze UI flows (not just screenshots) and reconstruct them into React + Tailwind.
One big pain point with AI generators is that they produce "dumb components" with fake data structures. You always have to rewrite the props to match your backend.
We just shipped a feature documented here (https://replay.build/docs) that solves this:
The AI connects to your Supabase (read-only) to fetch the schema. When it sees a list of items in the video, it looks at your actual tables (e.g., products) and generates code that matches your column names (price_cents vs price).
The goal is to get "run-ready" code, not just a mock.
Would love to hear your feedback on the generated code quality and the schema mapping approach!
Comment · 10 months ago
True but there is the way try to tun in on phone there it works smooth
Comment · 10 months ago
I’ve been exploring a different approach to UI reconstruction: treating screen recordings as the source of truth, rather than screenshots, design files, or prompts.
Most tools that attempt to “generate UI” work from static inputs. A screenshot captures layout, but it misses what actually defines an interface: flow, state, and interaction over time.
A short screen recording, on the other hand, shows:
how navigation really works
which screens actually exist
what happens on hover, click, focus
which states are reachable vs. theoretical
I built a small prototype that watches UI video and reconstructs:
layout and component structure
navigation and page hierarchy
visible interaction states
a flow map of what was shown (and what wasn’t)
The key constraint is simple: if something wasn’t shown in the video, it isn’t generated. No guessing, no invented screens.
As a sanity check, I used a familiar public website as an example — not because it’s special, but because most people immediately recognize the structure and flow, which makes it easier to see what’s being reconstructed.
This isn’t about replacing design or development work. It’s more about reducing the “reverse-engineering” phase when all you have is a running product and no specs, no design files, and no original team.
I wrote a longer explanation here: https://www.replay.build/learn/behavior-driven-ui-reconstruc...
Curious if anyone here has tried similar approaches, or run into cases where static representations completely break down when you try to rebuild real interfaces.
Comment · 10 months ago
Hi HN,
For years I’ve been rebuilding UIs — legacy internal tools, SaaS dashboards, competitor clones — and I kept running into the same problem: screenshots lose states, transitions, and behavior design files exist only for new features prompts can guess layout but not actual interaction logic reverse-engineering takes weeks, not minutes
So I built something for myself: Replay.
The core idea is simple but (I think) new: treat a video of the UI as the source of truth. Not single frames, not mocks, but how a UI actually behaves over time — clicks, scrolling, navigation, state changes.
Replay analyzes a recording end-to-end and reconstructs: a responsive UI based on real behavior flow map of transitions and possible paths,componentized code (React + Tailwind), an editable design system
all states observed in the video
It doesn’t guess missing features — it faithfully rebuilds what it sees in style we want keeping the data.
I’ve used this to rebuild several real products and internal systems, and it’s saved days or weeks compared to manual reconstruction. The technology feels possible now because recent advances in AI make it feasible to infer state machines and interaction graphs, not just pixels.
We’re in early access beta (2 free reconstructions for new users), and I’m curious about a couple of things:
What are edge cases this might fail on? Do others have workflows that suffer from the same “screenshots aren’t enough” problem? How useful would a tool like this be for your team?
Beta: replay.build
Happy to answer questions. Bartosz
I've been working on a problem that frustrates me with current "Screenshot-to-Code" tools: they are static. They capture the layout, but they miss the behavior (animations, loading states, navigation flow).
So I built a pipeline that treats video as the source of truth.
Instead of analyzing a single frame, the engine parses the video timeline to extract a rudimentary state machine before writing any code. This allows it to reconstruct:
The initial state.
The trigger (click/scroll).
The resulting state (modal open, menu slide-in).
It outputs a clean React + Tailwind project that actually functions, rather than just looking like a picture.
The Update: High-fidelity video inference is expensive (GPU costs), so I had it gatekept. I just optimized the backend and opened up 2 free reconstructions for everyone because I need to stress-test the model with diverse, real-world edge cases.
You can try it here (no credit card): [LINK DO REPLAY]
I’m looking for feedback specifically on the generated component structure – does the code feel "human-written" to you, or does it still smell like AI spaghetti?
Bash away!