> Blog post by Lokesh Saini
> Canonical (HTML): https://www.lokeshsaini.com/blog/thirty-minutes-before-the-application

Before I write a word of an application, I spend about thirty minutes just understanding where I am going. Not the company's mission statement. The actual product: who uses it, what it does on a Tuesday afternoon, what they shipped in the last quarter. This habit started as a corrective for bad applications I had written. It became the practice I now think separates considered applications from generic ones.

## The Reader Has a Job to Do

A hiring manager reviewing applications is doing a triage task. They are trying to match a specific need with the closest available evidence. That is a user with a job to do. If you have spent any time in UX research, this framing should feel familiar. When you respect the user's context, you write for them. When you ignore it, you write for yourself.

An application written without research is written for yourself. It describes your experience in the abstract. It uses language that fits anywhere, which means it resonates nowhere. The first paragraph I read in most applications tells me whether the person spent twenty minutes on the company or twenty seconds.

Research changes what you write and, more importantly, what you decide to lead with. The story you open with is the one that sets the frame for everything after it.

## What I Actually Look For

I am not trying to flatter the company. Flattery is detectable and does nothing for the reader. I am trying to answer four questions.

What does this product actually do? Not the tagline: the product. What does a user open when they need it? What problem shows up in their day that this thing resolves? Sometimes the answer is in a recent announcement, a product changelog, or an App Store description that has not been polished into abstraction yet.

Who uses it, and what is their context? A tool used by a solo freelancer at midnight and a tool used by a team of five in an office meeting involve different design constraints, different failure modes, different definitions of done. The job description rarely says this directly. The product usually reveals it.

What did they ship recently? Shipping history tells you what the team is actually working on versus what the company says it values. A team that shipped three rounds of accessibility improvements values different things than a team that shipped three rounds of onboarding experiments. Both are valid. They are not the same.

What does this role exist to solve? Job descriptions describe requirements. Behind every requirement is a problem the team has not solved yet. Reading the description for the underlying problem, not the stated criteria, tells you which story to lead with.

## The Same Discipline, Different Direction

This is not a separate skill from user research. It is the same discipline pointed inward toward the application process. When I am designing a product, I spend time understanding the user before I open Figma. The instinct is to skip that step when you feel confident about the solution. The instinct is wrong in product design, and it is wrong here.

The parallel runs further. In research, the goal is not to confirm what you already think. It is to surface what you did not know to ask. Thirty minutes of genuine curiosity about a company will usually produce one thing you did not expect: a constraint the role carries, a product decision that reveals something about the team's priorities, a recent pivot that reframes what they need. That thing is usually the hook. It is the thing that only someone who looked would know to write about.

## Deciding Whether You Fit

There is a second outcome from this research that rarely gets named. Sometimes thirty minutes of honest looking tells you that the fit is weaker than the job description made it appear. The product is in a domain that does not interest you. The company is solving a problem you do not believe in. The role is described in a way that does not match how you actually work.

That is valuable information. An application written without research cannot make this distinction. It treats every opportunity as equivalent and produces interchangeable copy. An application written after honest research either gets sharper because the fit is real, or it does not get written because the fit is not.

The goal is not to flatter the company. The goal is to figure out whether and how you fit, and then to write something only you could have written for this specific role. That is the standard I hold the research to. If the draft I produce after thirty minutes of research could have been written by anyone who read the same job description, I have not done the work yet.

## The Thirty Minutes

The time itself is not precious. I have done this in twenty minutes on a slow news day and in an hour when the company was doing something genuinely unusual. The discipline is not the duration. It is the decision to look before you write. Everything that follows is better for it.