Empty States With One CTA Convert 34% More First Deploys

Every developer who has shipped a first version to a real user has watched that user land on a screen with nothing on it. The blank dashboard. The empty repository. The "no projects yet" panel that the designer left as a placeholder and the engineer never quite got around to filling in. The question worth asking is not whether that screen looks acceptable, but what it actually does to the person staring at it — and whether the single button sitting on it is doing the work it could be doing. There is a growing body of evidence, drawn from behavioral research and from teams tracking activation metrics, that the design of that one moment carries more weight than almost any other screen in a young product.

The Empty State Is Not a Placeholder. It Is a Decision Point.

Most teams treat the empty state as a design afterthought: a grey illustration, a friendly line of copy, and a button that says "Get started." In practice, this is the first genuine decision point a new user faces inside your application. They have signed up, they have confirmed an email, and now they are looking at a screen that contains no data, no history, and no obvious path forward. The cognitive load of that moment is higher than it appears from the outside.

Behavioral research has a useful frame for this. Daniel Kahneman's work on decision-making under uncertainty describes how people facing an unfamiliar situation with no reference point tend to default to the most salient, lowest-effort option — or to defer the decision entirely. An empty state with no clear action asks the user to generate their own next step. That is expensive. An empty state with one obvious action asks them to evaluate a single option. That is cheap.

The difference between those two experiences is not cosmetic. It is the difference between a user who explores and a user who closes the tab and means to come back later. In practice, they usually do not come back later.

The claim that a single, well-placed call to action in an empty state lifts first deploys by roughly a third is not magic, and it is not a universal constant. It is the kind of number that shows up repeatedly when teams instrument this specific moment carefully. The mechanism is worth understanding, because the mechanism is what you can actually design against.

Why one button beats three

When you offer a new user three equally valid paths — "Create a project," "Import from GitHub," "Browse templates" — you have not given them choice. You have given them a decision they are not yet equipped to make. They do not know which path suits them because they do not yet understand your product well enough to predict the outcome of each.

There is a well-documented effect here that predates modern software: choice overload. The classic jam study, run by Sheena Iyengar and Mark Lepper in 2000, found that a display of 24 jams attracted more browsing attention than a display of 6, but shoppers who saw the smaller selection were dramatically more likely to actually buy. The larger assortment attracted interest and suppressed action.

Your empty state is that jam table. The user is interested. They are standing in front of your product. What they need is not more options. They need one path that works.

The first deploy is a commitment device

There is a second mechanism at work, and it is subtler. The moment a user completes their first meaningful action inside your product — their first deploy, their first published page, their first committed file — something changes in how they relate to it. The product stops being a thing they are evaluating and becomes a thing they have done something with.

This is closely related to the sunk cost effect, which is usually discussed as a bias to be avoided in financial decisions but functions quite differently in product onboarding. A user who has invested five minutes and one successful action has a small stake. That stake makes them more likely to return, because returning now has a coherent narrative: I started something here.

An empty state with one clear CTA is, functionally, a machine for producing that first small stake as quickly as possible. Every additional option dilutes the probability that any single action gets completed.

What the Research on Reward and Reinforcement Actually Tells Us

It is worth being precise about which behavioral concepts apply here and which are often misapplied.

Variable-ratio reinforcement — the schedule famously studied by B.F. Skinner, in which a reward arrives after an unpredictable number of actions — is frequently invoked to explain compulsive engagement with products. It is a real phenomenon and it does drive certain kinds of repeated behavior. But it is the wrong model for a first deploy. You do not want the user's first meaningful action to be uncertain in its outcome. You want it to succeed, reliably, on the first attempt. Variable reinforcement is a tool for sustaining engagement after the habit exists, not for creating it.

What actually applies at the empty-state moment is closer to what Kahneman and Tversky described as loss aversion, applied prospectively. A user who has not yet acted has nothing to lose and therefore nothing to protect. A user who has acted has a small position they are now motivated to defend and grow. The design goal is to move the user across that line as cheaply as possible.

There is also a straightforward principle from the study of goal gradient behavior: people accelerate their effort as they approach a visible goal. An empty state with a single CTA and a clear sense of what happens after you click it converts the abstract into the proximate. The user can see the finish line of the first step. That visibility is what produces the acceleration.

The concrete case: a deploy pipeline that stopped losing users at step zero

A useful illustration comes from a pattern that shows up repeatedly in developer tooling. A small team building a deployment platform noticed that a large share of signups never reached a first successful deploy. The funnel looked fine at the top — signups were healthy, email confirmation rates were high — and then fell off a cliff at the first screen inside the product.

That first screen offered three options: connect a Git repository, upload a folder, or start from a template. Each option was well designed in isolation. Together, they produced paralysis. Users clicked around, opened two of the three, and left without completing any.

The team replaced the three-option screen with a single primary action: connect a repository, with the other two paths demoted to a small text link below. Nothing else changed. The first-deploy rate rose substantially — in the range of a third — and the effect held across cohorts. The interesting detail is that users who had previously chosen "upload a folder" or "start from a template" were not lost by the change; they simply found those paths later, after they had already completed a deploy. The options had not been valuable at the decision point. They had been expensive.

This is the pattern worth internalizing: the options you remove from the empty state are not removed from the product. They are moved to a point in the user's journey where they can actually be evaluated.

Designing the Single CTA So It Actually Converts

Knowing that one CTA outperforms three is not the same as knowing how to write and place that one CTA. There are several specifics that matter, and they are easy to get wrong.

Make the action produce a visible result

The CTA should lead to something the user can see. "Connect your repository" is a good CTA because the result is immediate and legible: your code appears, a build runs, a URL goes live. "Set up your workspace" is a weak CTA because the result is abstract and delayed.

The principle here is that the first action should produce feedback within seconds. This is the same logic that makes a well-designed tutorial effective — early, visible success builds the confidence to continue. An empty state that leads to a five-minute configuration wizard before anything visible happens has wasted the moment.

Reduce the number of fields to the absolute minimum

If the CTA opens a form, that form should ask for the smallest possible number of things. Every additional field is a place where the user can hesitate, and hesitation at this stage is fatal. If you can authenticate through an existing provider and skip the form entirely, do that.

Write copy that names the outcome, not the mechanism

"Buttons that say 'Get started' are wasted opportunities," is a line worth taping to a monitor. "Get started" describes nothing. "Deploy your first app" describes the outcome. "Connect a repository" describes the action and implies the outcome. The copy on the button is the last thing the user reads before committing, and it should tell them what they will have after they click, not what they will be doing.

Do not hide the empty state behind a modal

A modal on top of an empty state is a common pattern and usually a mistake. It adds a layer of interface between the user and the action, and it signals that the action is optional or secondary. The empty state itself should be the invitation. Let the whole screen point at one thing.

Instrument it specifically

You cannot improve this moment if you are not measuring it in isolation. Track the rate at which users who land on the empty state complete the first meaningful action. Track the time between landing and completing. Track how many users who see the empty state never act at all. These are different numbers from your overall activation rate, and they are the numbers that tell you whether the empty state is doing its job.

Most analytics setups collapse this moment into a general "signup to activation" funnel, which hides the specific failure. Separate it out. The empty state is a screen with a job. Measure whether it does the job.

What This Means for Teams Building in Croatia and Beyond

There is a practical dimension to this that matters for smaller teams, which describes most of the development scene in Croatia. A team of three or four people building a product does not have the resources to run extensive onboarding experiments. They have to make a small number of high-leverage changes and get them right.

The empty state is one of the highest-leverage surfaces available, precisely because it is small. It is one screen. It has one job. Changing it costs a day of design and engineering time, not a sprint. And the effect compounds: every user who completes a first deploy is a user who is now in a position to experience the rest of your product, which means every downstream metric you care about is now being measured on a larger and better-qualified population.

There is also a competitive argument. Products in crowded categories tend to converge on similar feature sets. What differentiates them at the margin is often the quality of the first five minutes. A competitor with a more elaborate feature set but a confusing empty state will lose users to a simpler product that gets them to a first result faster. The empty state is where that contest is decided.

The forward-looking part

The next shift in this area is likely to be adaptive empty states — screens that change what they offer based on what the system can infer about the user. A developer arriving from a specific repository host, or with a particular language in their profile, might see a different single CTA than a user arriving cold. The principle stays the same: one action, clearly named, leading to a visible result. The personalization changes which single action, not how many.

This is worth building toward, but only after the basics are right. An adaptive empty state built on top of a confusing one just produces confusion faster. Get the single CTA working first. Measure it. Then consider whether the system knows enough about the user to choose a better single action.

The teams that will win the next few years of developer tooling are not necessarily the ones with the most features. They are the ones who understand that the first thirty seconds of a product are not a formality to be gotten through. They are the product. The empty state is where that understanding either shows up in the design or does not.

If you take one thing from this: open your own product in a fresh account tomorrow morning, and look at what a new user sees. Count the buttons. If there is more than one, you have a specific, cheap, high-leverage experiment waiting for you.