Time to access: why fast products win

There’s an unspoken rule in product design that nobody writes down but every user enforces: the moment you came for needs to happen fast. Not eventually. Not after a sidebar loads and a workspace initializes. Fast.

That gap has a name in my head: time to access. It’s the distance between intention and action. And it’s the thing most products quietly lose on.

Most products don’t lose because they’re worse. They lose because they’re slower to get to. Slower to open. Slower to find. Slower to do the one thing the user came to do.

I think about this every single time I build something.

The Notion problem

I love Notion. I’ve used it for years. I still pay for it.

But I don’t take notes in Notion anymore. I take notes in Apple Notes.

Why? I open my phone, swipe down, tap Notes, the thought is on the screen. Maybe two seconds. Notion takes the workspace, the sidebar, the page tree, the loading state, the cursor placement. By the time I’m ready to type, the thought is gone.

Notion is great at being a second brain you organize on a Sunday. It’s terrible at catching a sentence that just popped into your head on a Tuesday.

That’s not a feature gap. It’s a time to access gap. And it’s the reason a 2007 stock iOS app keeps eating into a $10B product’s most natural use case.

What time to access actually is

Most product teams measure things like load time, time to first byte, time to interactive. Those are useful. They’re also not what users feel.

What users feel is the full distance from the moment they decide to do something to the moment they’ve done it.

That includes:

• Finding the app. Is it on the home screen? Is it pinned? Do they have to search?
• Opening the app. How long does the splash screen sit there?
• Auth. Are they logged in? Did the session expire?
• Navigation. How many taps before they get to the screen they wanted?
• The action itself. Is it one tap, one paste, one click, or a small form?
• Confirmation. Did the thing they wanted actually happen?

Add it all up. That’s the number that matters. Not your Lighthouse score.

The bookmark example

If you’re building a bookmark manager and your user flow is “open a new tab, type the URL, log in, paste the link, hit save”, you’ve already lost.

The user doesn’t want to use your product. They want a bookmark saved. Those are different goals.

The product that wins is the one where they tap an extension, the thing is saved, they keep doing what they were doing. Zero context switch.

This is why every successful “save it for later” product is a browser extension, a share sheet, a keyboard shortcut, a hotkey. The product that requires you to leave your current task to use it dies. Quietly. Slowly. Through silent disengagement.

Where this shows up in real building

I’ve been building lst.so for a few months. It’s a task manager. The hardest decision wasn’t the schema or the pricing. It was: how does a task get into the system in under three seconds?

The answer ended up being a global hotkey, a tiny popover, one input field. Type the task, hit enter, gone. No tagging, no project picker, no due date, those can come later, in context.

If you make people do the “right” thing every time they capture, they stop capturing.

The same logic shaped tini.bio. The whole product is about how fast you can have a working personal page. Sign up, see a page, edit a block, done. We measure the time between signup and first published page. Every friction we removed lifted activation.

It’s not exciting work. Most of building a fast product is removing things, not adding them. Removing a modal. Removing a confirmation. Removing a step that “felt necessary” but wasn’t. Removing the requirement to be logged in for the first action.

The AI era is collapsing this to zero

Here’s where it gets wild. The whole concept of time to access is being rewritten in front of us.

For years, the unit of access was a click. Then a tap. Now it’s a sentence to an agent.

Mercury just shipped a CLI for your bank. Their whole product. From a terminal. You type a command and your balance is there. You want a statement, you type one line and it’s in your downloads folder. The thing that used to be “open mercury.com, log in, wait for 2FA, find the account, click statements, pick the month, pick the format, download” is now one command. Two seconds.

That’s not a feature update. That’s a different category of access.

And it’s not just Mercury. Linear has an MCP server. Notion has one. Slack has one. Stripe ships APIs that are basically agent-ready. The companies that get it are turning their entire product surface into something an agent can talk to directly. The UI becomes optional. The interface becomes the conversation.

Think about what that does to time to access. The intention used to be “I need to do X”, find the app, open the app, navigate, do X. Now it’s “I need to do X”, type the sentence, done. The agent handled the navigation. The agent handled the form. The agent handled the API call.

If your product still requires a user to open a screen and click through five steps to do the thing they want, you’re competing with products where the same thing happens by talking to Claude or Cursor or a terminal. That gap is going to feel embarrassing fast.

The builders winning this next chapter are the ones who treat their MCP server, their CLI, their API like first-class surfaces. Not afterthoughts. Not “we’ll get to it.” The interface is now plural, and the agent-facing one might be the one that matters most.

The frame that makes this useful

Next time you’re staring at a feature spec, do this. Map the path. Literally write it down.

User has a thought → user opens phone → user finds app →
user opens app → user navigates to screen → user does action

Now count the steps. Now count the seconds. Now ask which steps could disappear.

Most product teams don’t do this because it feels too basic. That’s the moat. The companies that obsess over time to access at every release are the ones that compound user engagement quietly while their competitors keep shipping features nobody can reach in under a minute.

Speed isn’t a feature. It’s a precondition.

Make the first action one tap. Make the next session zero friction. Make the moment of value happen before the user has time to ask “why did I open this again?”

That’s the work. Most of it isn’t glamorous. But it’s where the winners are made.