Building our landing page in the open: real components, zero slop
Most product sites fake the product with stock screenshots. We rebuilt ours to show the real app in motion — live agent cards driven by a reuse harness. Here is how, and why.
There's a familiar dishonesty to most software landing pages. They show a glossy screenshot of a dashboard that doesn't quite exist, a mockup with invented numbers, a hero image bought from a stock library. The page sells a product that's a little nicer than the real one.
We decided our landing page would do the opposite: show the real app, actually running. Not a picture of agents — real agent cards, ticking through real work. This is a note on how we're building it, and the rule that kept it honest.
The rule: no slop
We set one non-negotiable before writing a line of code. Every visual on the page renders our shipping UI, fed real-shaped data. No fabricated dashboards, no stock photography, no invented metrics, no "coming soon." If a surface isn't real yet, it doesn't appear on the page.
The bar
Everything on the page is a real component of the product, or it isn't on the page. A site that fakes its product is worse than a plain one — especially to anyone deciding whether to trust it.
That sounds obvious. It's surprisingly hard, and the reason is technical.
The hard part
Our real product components — the agent live-cards, the chat messages, the workspace tiles — expect a live backend and an authenticated session. They read from queries, sit inside providers, assume a signed-in user.
A marketing page is the opposite of that. It's public, unauthenticated, statically served, and needs to be fast. You can't just drop a component that expects a database connection onto a page a stranger loads in 200 milliseconds.
The tempting shortcut is to rebuild the components — a "marketing version" of the agent card that looks like the real one. That's how sites drift into slop: the marketing copy of a component always lags the real one, and soon you're showing something that no longer matches the product.
The reuse harness
So we built the other way. Instead of reimplementing the UI, we extracted the presentational core of each real component — the part that's just props in, pixels out — and fed it seeded, real-shaped fixtures.
- The agent cards render from the same components the app uses, given static props in the exact shape the live queries return.
- A small scripted timeline advances a simulated session through its turns, so the progress rail fills and the pull-request stage chip moves from open to checks to merged — the way it does in a real run.
- The whole thing is deterministic. No backend, no auth, no live data — but the pixels are the product's pixels.
We call it the reuse harness, and it's the load-bearing idea. When a real component improves, the landing page inherits the improvement for free, because it is the real component. The simulation can't drift from the product, because there's only one source of truth.
Why this beats a screenshot
A screenshot is dead the moment you take it. It's stale by the next release, it can't move, and it quietly tempts you to touch it up. A living component driven by fixtures stays current, plays in motion, and can't be prettied up beyond what the product actually does. Honesty falls out of the architecture instead of relying on discipline.
What shipped first
We sequenced the work so the highest-leverage, most-honest section shipped first: the hero and a live active-agents simulation — a small fleet of real agent cards playing through a build, on the real components, through the reuse harness. It's the one thing on the page that no static image could ever fake, and it happens to be the thing that's most true about the product.
Sequencing
Ship the section that's both the hardest to fake and the most representative first. It sets the bar for everything after it — and it's the part a visitor remembers.
What we're carrying forward
A few principles are outliving this one page:
- Extract presentational cores. Components that are pure props-in-pixels-out are reusable everywhere — the app, the marketing site, tests, docs. Coupling UI to a backend is a cost you pay later.
- Fixtures are a feature. Real-shaped seed data is worth maintaining. It powers simulations, catches visual regressions, and documents the exact contract a component expects.
- Motion earns its place. The agent feed moves because the real one moves. Nothing on the page animates for decoration.
We're building the rest of the page the same way — chat, the memory fabric, the spatial workspace — each one the real thing, running. When you visit, what you see is what you get. That was the whole point.