Rebuilding the Rehearsals Website

We replaced runrehearsals.com this week. Not a refresh, a rebuild: new structure, new writing, new arguments, and a few claims that did not survive the process. This is the note about why we did it and how we decided what went on the page.

The old site sold a category

When we started, the hard part was explaining what an AI twin even was. The old site did that job. It was built to make an unfamiliar idea legible, and for a while that was the only job worth doing.

That is no longer the hard part. People understand the idea in about a minute now. What they want to know next is whether it works, who the twins are actually built from, and what happens when the answer comes back wrong. The old site did not really answer any of those.

One rule for the whole build

Every claim had to arrive with the thing that backs it. If we said 92% accuracy, the page had to say what that measures and how it is tested. If we said the twins are built from real people, we had to show the panel: how participants are recruited, what they consent to, and how often they are re-interviewed. If we said a Rehearsal runs in under an hour, that had to be the honest number rather than the best one we have ever recorded.

If we are asking teams to make real decisions on our output, the site should be checkable.

That rule did most of the design work for us. It is why accuracy is a full page instead of a badge, why pricing is a page instead of a form, and why the team page has faces and names on it. Anyone serious about simulating people should be willing to show you theirs.

What came off the page

• Numbers with no method behind them. If we could not point at how a figure was produced, it did not make the cut.
• The category’s vocabulary. Synthetic respondents and agentic personas describe a different product than ours, and borrowing the words made us sound like everyone else selling one.
• The single scrolling pitch. Accuracy, the panel, and price are three separate objections, so they became three real pages you can send to somebody on their own.

How it is built

We built it ourselves: Next.js, no CMS, every line of copy in version control beside the component that renders it. That sounds like an engineering decision and it is really an editorial one. Copy in a repository gets reviewed like code, and nobody can quietly soften a claim at eleven at night.

The design language comes from print rather than from software marketing: ink on paper, hairline rules, one accent colour, and typography doing the work that gradients usually get asked to do. This section is the clearest example of it. A company that publishes its own results should look like it publishes.

Why this section exists

Updates is the part of the site I care most about. Simulation is a young field and most of what gets published about it is marketing. We would rather write about the tests that came back weaker than we hoped, the methods we are still arguing about internally, and the things we got wrong in front of customers.

Which means this section starts thin. There is one story in it today and you are reading it. The grey blocks on the section front are exactly what they look like: space held for work that is not written yet. We would rather print an honest edition of one than pad it out.

If something on the new site is unclear, overstated, or simply wrong, I want to hear about it. That is the entire reason for building it this way.