rubl has one performance rule and it isn't aspirational: interactions land in under 100 milliseconds or the feature doesn't ship. Not "we aim for fast." Not "performance is a priority." A number, a line, and a nightly test that fails the build when we cross it. Here's why we run it this way, and what it costs us.
Why 100 milliseconds
Somewhere around a tenth of a second, something interesting happens to perception: cause and effect fuse. Below the line, you don't experience "I clicked and then it responded" — you experience doing. The tool stops being an intermediary and disappears. Above the line, every action has a tiny gap in it, and your brain spends the gap checking whether the thing worked.
One gap is nothing. But a knowledge worker interacts with their tools thousands of times a day, and the gaps compound into something worse than lost seconds: broken thought. You had the next action loaded, the tool made you wait, and the action fell out of your head. A slow tool charges a tax on every thought. We think that tax — more than any missing feature — is why work software feels heavy.
Measured, not promised
Every software company says it's fast, which is exactly why saying it is worthless. So we made two rules for ourselves.
- Measure where the user is. Our own landing page times its demos in your browser — real interaction-to-painted-frame numbers, plotted on a ruler against the 100ms line, on your hardware, not ours. Go drag things on the speed section and watch where the dots land.
- Test at embarrassing scale, nightly. Fast on a demo workspace is a parlor trick. Our nightly suite runs interactions against a 100,000-row workspace — bigger than most companies will ever generate — and the 100ms line is a hard assertion. When it fails, someone's morning is ruined, on purpose.
What the rule costs
A hard performance budget is like a hard weight limit on an aircraft: it forces real decisions instead of deferring them. We've redesigned features late because they were 30ms over. We've turned down architecture that would've shipped a quarter faster but put a network round-trip inside a keystroke. The rule means saying no to things users asked for, until we find the version of the thing that's instant.
That sounds costly, and it is. But the alternative is the default fate of business software: each release a little heavier, each interaction a little later, until one day your product is the one people sigh before opening. Speed is much cheaper to keep than to recover.
Speed is a trust primitive
There's a deeper reason this matters to us than feel. rubl's whole premise is an AI teammate acting inside your company's work — filing the follow-ups, routing the leads, answering with sources. You will only delegate to a system you trust, and trust is built from hundreds of tiny proofs that the system does what you meant, instantly, every time.
A tool that's instant when you touch it earns the benefit of the doubt when it acts on its own. That's the real reason for the line: under 100ms isn't a performance spec — it's the down payment on "runs itself." The rest of the bet is built on top of it.
— Jabez, founder · rubl by Fludigo