RapidEye v2

We rebuilt the RapidEye dashboard from scratch. Not restyled, rebuilt. Two of us each designed a competing version in parallel, argued about them for an hour with the whole team, and merged the winners: the sidebar from one design, the content system from the other. What shipped is the screen above, and this post is the reasoning behind it.

One screen, five doors

The dashboard is deliberately an overview page, not a destination. Every module on it is a door into a deeper part of the product: the inspection count opens Inspections, the findings feed opens Findings, the charts open Analytics, and the properties needing attention open the property itself. Nothing on the dashboard is the end of a workflow.

That sounds obvious, but it changed real decisions. The page follows what we call the one-pager rule: on a desktop screen the layout sizes itself so the whole dashboard fills the viewport exactly, with nothing hanging below the fold. We stopped worrying about fitting everything in, because the screen's only job is to answer "where should I look next" and get you there in one click. It also means multiple ways to reach the same place is a feature, not redundancy. You can get to a property through the sidebar, through a finding, or through a video card, and they should all work.

The severity argument

Every finding RapidEye pulls out of a walkthrough video carries a severity: critical, major, or minor, drawn as compact colored bars you can scan down a whole list of findings without reading a word. Getting there involved a real fight about numbers. One of us wanted a 0 to 100 severity score next to every finding, on the theory that a label buckets information away and a number keeps it.

The counterargument won: a severity model is honestly precise to maybe plus or minus 15 points, and printing "74/100" next to a finding claims a precision the model does not have. If you would round the number into buckets anyway, the buckets are the honest interface. The bars are the number, at the resolution we can actually stand behind.

One distinction we hold onto either way: severity is not confidence. A dark mark on a carpet might be a shadow or might be a bad stain. Whether it is real is a confidence question. How bad it is if it is real is the severity question. Keeping those separate is what stops the indicator from turning into mush.

Four videos, not one

The recently recorded section shows the last four walkthrough videos, not just the latest. This was a genuine argument too. The case for one: less UI, and the newest turnover is what matters. The case for four: a property manager's day does not have one turnover in it. They are thinking about every property that turned today, and when four familiar doors and living rooms are staring back at them, the one they were already worried about is right there to tap.

Four also happens to be the number where the section stays contained without becoming a wall. Above four it is too much interface, at one it hides information an operator actually wants. And each video card carries an issue count, so "which of these needs me" is answered before you click.

Rows you can feel

Every finding row has a thumbnail of the actual frame the issue was found in. Here is the honest version of why: at thumbnail size you often cannot make out the stain or the missing remote. The picture is not there to inform, it is there because a row with an image feels like there is something behind it, and a row of bare text feels like a spreadsheet. People click through rows that feel alive. It also makes the findings list scannable in a way plain text never is.

Same logic behind the type sizes. Our typical user is a property operations manager around fifty years old, often reading this on a phone between property visits, sometimes through reading glasses. Big bold finding text is not a style choice, it is who the product is for.

Review is its own room

The one part of the app that is genuinely work rather than viewing is Review, where a team confirms or dismisses what the AI flagged. In v2 it is visually separated from everything else in the sidebar, because in practice it is used by different people. Operators like Rove run a back-of-house team that lives in Review all day, while property managers live in the overview tabs. Two audiences, two spaces, one app.

The small things that survived the argument

Surfaces went flat: hairline borders instead of card shadows, and only true overlays like the command palette are allowed to cast one. One accent color, everything else grayscale. Search became a command palette, so cmd-K from anywhere jumps you to any property, inspection, or cleaner. And the Copy inspection link button lives in the top bar on every page, because inspectors in the field need a reliable way to pull up their recording link on whatever device they are holding, and one click beats a support message.

And yes, we optimized for demos. We want somebody seeing RapidEye for the first time to have the reaction you have the first time you see a genuinely modern web app, where the interface itself makes you trust the intelligence underneath. That is not a shallow goal. If the dashboard looks like it was built in 2015, nobody believes the AI behind it was built in 2026.

What's next

The overview page is done; the rooms behind the doors are being built out now. A full Analytics page with property and cleaner trends over time, deeper per-property pages, and role-based access so a back-of-house reviewer and an owner each see the app they need. If you run turnovers and want to see v2 on your own properties, that is exactly the stage we are at.