You Built the App. Now Where Do the Users Come From?

What vibe coders and indie game developers need to understand about acquisition, activation, retention, and scaling.

AI has made it easier than ever to build software.

Someone with an idea can now create a functioning SaaS product, website, utility, or game without first spending years becoming a professional software engineer. Indie developers can accomplish things that would have required an entire team only a few years ago.

That is a real revolution.

But building the product is only one part of the job.

Eventually, almost every developer reaches the same question:

How do I get users?

Building the app is a milestone. It is not the same thing as finding the users.

Publishing your product does not automatically create an audience. Putting a game on Steam, launching a website, or posting your SaaS application on social media might produce some initial traffic, but hope is not a growth strategy.

You need a repeatable way to acquire users, understand what they do, improve their experience, and determine whether bringing in more users makes business sense.

I have worked in the video game industry for more than 40 years. I was involved in building and scaling free-to-play games including FarmVille, Bubble Safari, and Cookie Jam, and I spent four years as the general manager of Cookie Jam, managing its growth from a small app that had just been launched into the billion-dollar, five-million-DAU powerhouse it became.

Free-to-play games taught hard lessons about acquisition, retention, monetization, and scale.

Those products operated at a scale most independent developers will never need. But the fundamental process we used applies just as well to a small SaaS product, an indie PC game, or an application built by one person.

We did not simply release a product and wait for millions of people to find it.

We acquired users. We measured what they did. We studied where they left. We calculated what they were worth. We improved the product and the advertising. Then we spent more money where the numbers worked and stopped spending where they did not.

The scale may change, but the basic system does not.

Users Rarely Appear by Accident

In free-to-play games, we often described the process bluntly:

You buy users.

User acquisition is not one announcement. It is a system of channels, messages, costs, and outcomes.

You create advertising, target people who might be interested, pay for impressions or clicks, and acquire installs. Then you track those users to see whether they play, return, and spend money.

For a SaaS product or indie PC game, the acquisition channels may be different.

Users might come from:

• Search engines
• Paid advertising
• YouTube videos
• TikTok
• Reddit
• Discord communities
• Newsletters
• Influencers and streamers
• Steam wishlists and festivals
• Product directories
• Partnerships
• Word of mouth
• Your own content and community

Paid platforms such as Meta, Google, and TikTok currently offer campaigns designed to optimize for actions such as website conversions, leads, sales, or application installs. Google’s Performance Max campaigns can distribute advertising across several Google properties, while Meta and TikTok increasingly automate targeting and campaign optimization.

PC game marketing often works differently. Steam does not sell developers paid advertising placements inside the store, so game developers commonly build awareness through wishlists, demos, festivals, creators, communities, external advertising, and Steam’s own visibility systems.

The exact channel is not the central point.

The central point is that you need to understand:

• Where the user came from.
• What it cost to acquire that user.
• Whether the user experienced the value of your product.
• Whether the user returned.
• Whether the user eventually produced revenue or some other meaningful result.

At scale, user acquisition has to become a system rather than a series of hopeful announcements.

The Ad Buys the First Visit. The Product Earns the Second.

Before you spend meaningful money acquiring users, your product needs to be ready to receive them.

This sounds obvious, but it is where many first-time developers get the sequence wrong.

They build a collection of features, get the basic application running, and decide that development is finished. Marketing is treated as the next, separate phase.

But there is an important stage between “the features work” and “we are ready to acquire users.”

That stage is making the product ready for real people.

Every advertisement, video, store page, social post, or recommendation makes a promise. When the user arrives, a clock starts running. Your product has a very limited amount of time to fulfill that promise.

If you just paid $3, $10, or $50 to acquire a user, you do not want that person to immediately encounter:

• A long registration process
• A confusing menu
• An empty dashboard
• A slow loading screen
• An unclear error
• A tutorial explaining twelve features
• A demand for payment before value has been demonstrated
• A product that gives no obvious indication of what to do next

The product needs to move the user quickly into its core loop of usefulness or enjoyment.

For a game, that may mean getting the player into meaningful interaction within seconds.

For an AI writing tool, it may mean helping the user generate and save a useful result.

For a project-management product, it may mean creating a real project and completing the first task.

For a creative tool, it may mean producing and exporting the first artifact.

For a multiplayer game, it may mean completing the first match and understanding why the player would want to play another one.

The important event is not necessarily the install or account creation. It is the moment when the user experiences the product’s actual value.

Product teams often call this activation.

A person who creates an account but never reaches the useful part of the product is not meaningfully activated. They are simply a registered person who left.

The product earns the second visit by getting people to value quickly.

Study Successful Free-to-Play Games

Even when you are building a serious business tool, it is worth studying the first-time user experience of successful free-to-play games.

You may dislike some free-to-play monetization techniques. That is a separate question. Study the onboarding.

The successful games are often extremely good at:

• Starting quickly
• Focusing attention
• Providing an obvious next action
• Teaching through interaction
• Introducing complexity gradually
• Giving immediate feedback
• Creating an early sense of progress
• Recovering gracefully from interruptions
• Moving the user directly into the core loop

These experiences did not become slick by accident. They were observed, tested, measured, and refined.

A well-designed game does not begin by showing the player a document explaining every system. It gets the player doing something, shows the result, and teaches the next concept when it becomes relevant.

A SaaS application should be just as intentional.

Do not drop a new user into an empty control panel and expect them to invent their own reason to care.

Start them with a template. Provide useful example data. Guide them through one meaningful workflow. Ask only for information that is required for the next step. Let the product demonstrate its value rather than merely describing its features.

Bad onboarding tells users what a product can do.

Good onboarding helps them do one valuable thing.

Define the Core Loop

Before acquiring users, you should be able to explain your product’s core loop in a sentence.

A strong loop gives users a reason to take the next action, then come back and do it again.

For a game, the loop might be:

Enter the game, make decisions, overcome a challenge, receive progress, choose the next goal, and return.

For a SaaS application, it might be:

Provide an input, receive a useful result, save or share that result, begin the next task, and return when more work needs to be done.

For a marketplace, it might be:

Search, find a relevant match, communicate, complete a transaction, and return for another need.

A strong product does not necessarily need to be complicated. It needs to provide a clear reason for the user to perform the loop again.

Marketing cannot manufacture that reason.

It can bring people to the door. It cannot make them stay.

Instrument the Product Before You Promote It

Once real users start arriving, opinions become less useful than evidence.

Instrumentation turns vague launch anxiety into observable behavior.

You need analytics that show what users actually do.

At a minimum, you should be able to identify:

• Where the user came from
• Whether they signed up or installed
• Whether they completed onboarding
• Whether they reached the activation event
• Whether they returned
• Whether they paid
• Where they abandoned the experience
• Whether they encountered serious errors

The specific events depend on the product.

A SaaS application might track:

• Landing-page visit
• Signup started
• Signup completed
• First project created
• First result generated
• First export completed
• Subscription started
• Subscription canceled

A game might track:

• Store-page visit
• Install
• First launch
• Tutorial started
• Tutorial completed
• First match completed
• Level 5 reached
• First purchase
• D1 return
• D7 return
• D30 return

Do not track events simply because they are easy to count. Track events that represent real movement toward value.

A campaign can produce thousands of cheap signups and still be a complete failure if none of those users reach the product’s useful experience.

Understand the Funnel

The complete path usually looks something like this:

Impression → Click → Visit or install → Signup → Activation → Retention → Payment → Referral

The funnel helps separate traffic from real progress toward value.

At each step, some users leave.

That is normal.

Your job is to understand where they leave, why they leave, and whether the percentage continuing through the funnel is strong enough to support the business.

Suppose 10,000 people see an advertisement.

Perhaps 200 click.

Of those 200, maybe 80 create an account.

Of those 80, perhaps 30 complete the first useful action.

Ten return the following week.

Three become paying customers.

The campaign did not acquire 80 successful users. It acquired three customers, ten retained users, or 30 activated users, depending on what you are trying to optimize.

This is why cost per click or cost per signup can be misleading.

The cheapest traffic is not always the best traffic.

The Metrics That Matter

You do not need to begin with a dashboard containing 100 metrics.

You need enough information to answer a few basic questions.

What did it cost to acquire the user?

For a game or application, you may look at:

• Cost per install
• Cost per signup
• Customer acquisition cost
• Cost per activated user
• Cost per paying user

The most meaningful metric is usually the cost of acquiring a user who reaches an important business outcome, not merely the cost of generating a click.

The cheapest click is not always the cheapest useful customer.

Did the user experience the product’s value?

Measure:

• Onboarding completion
• Activation rate
• Time to first useful result
• First-session completion
• Percentage reaching the core loop

Did the user return?

Games commonly use D1, D7, and D30 retention.

D1 asks whether the user returned the next day.

D7 asks whether they returned approximately one week later.

D30 asks whether they remained engaged about a month later.

For SaaS products, weekly or monthly retention may be more appropriate. A tax application, for example, should not be judged by daily use. The retention interval needs to match the natural rhythm of the product.

Did the user generate revenue?

Depending on the business model, this may include:

• Purchase conversion
• Trial-to-paid conversion
• Subscription revenue
• Monthly recurring revenue
• Average revenue per user
• Advertising revenue
• Churn
• Refunds

Was the user worth what it cost to acquire them?

Ultimately, you need to compare acquisition cost with lifetime value.

If acquiring a customer costs $50 and that customer generates $200 in contribution over time, you may have a scalable system.

If acquiring a customer costs $50 and the customer generates $20, spending more money will not solve the problem. It will simply lose money faster.

Lifetime value is not always immediately known. You often begin with an estimate based on early retention, conversion, and revenue behavior, then improve the estimate as more data arrives.

Analyze Users in Cohorts

Do not throw every user into one giant average.

Cohorts show whether different groups of users behave differently over time.

Group users based on when and how they were acquired.

A cohort might consist of:

• People acquired from one advertising campaign
• Users who installed during the same week
• People who came from a particular YouTube creator
• Steam players who downloaded a festival demo
• Visitors who arrived through a specific search term
• Users who saw a particular advertisement
• Customers from a particular country or platform

Then compare the behavior of those groups.

One campaign might produce users for $2 each, but almost none return.

Another might cost $5 per user, but those users stay longer and pay more.

The second campaign may be much more valuable despite its higher initial cost.

This is the purpose of attribution and cohort analysis. You are trying to connect outcomes back to their source so you can make better decisions about where to spend time and money.

Attribution will never be perfect. People may see a video, hear about the product from a friend, search for it later, and finally click an advertisement. Several touchpoints may have contributed.

You still need the best evidence available. Marketing decisions do not require perfect knowledge. They require better information than guessing.

Begin With a Controlled Cohort

Do not start by trying to acquire 100,000 users.

Bring in a small, measurable group.

That might mean:

• A limited paid campaign
• A closed beta
• A demo promoted through a small community
• A launch to an existing mailing list
• A few carefully selected creators
• A small Product Hunt or directory release
• A Steam festival demo

The purpose of the first cohort is not necessarily to make a large profit.

It is to learn.

Early cohorts are controlled experiments. The goal is to learn what to improve next.

Did people understand the pitch?

Did the right people respond?

Did they complete onboarding?

Did they reach the activation event?

Did they return?

Did they pay?

Did they tell anyone else?

Where did they get confused?

What broke?

A few hundred dollars of advertising or a few hundred carefully acquired users can reveal major problems. It may not produce statistically perfect answers, but it can provide enough directional evidence to decide what to investigate next.

Make Sure the Product Can Survive Success

There is another part of user acquisition that first-time developers often overlook.

The product has to continue working when the users arrive.

Do not use paid customers to discover scaling limits you already could have tested.

An application that works correctly for one person is much easier to build than an application that remains responsive while hundreds of people use it concurrently.

Five hundred users spread across an entire month might be easy to support.

Five hundred users arriving within ten minutes and all generating images, uploading files, querying the database, joining multiplayer sessions, or calling the same AI service is a completely different technical problem.

Before launching a serious acquisition campaign, ask:

• How many users could be active simultaneously?
• How many requests does each active user generate?
• Which operations are expensive?
• Can the database handle simultaneous reads and writes?
• Are external AI or payment services rate-limited?
• What happens when an external service slows down?
• Can expensive work be queued?
• Can a single user consume all available capacity?
• What happens when a request fails?
• Will you know when the system is failing?
• Can users recover without losing their work?

You do not need to build infrastructure for ten million users before you have ten customers.

Prematurely building for imaginary scale wastes time and money.

But you should test for the amount of traffic you are deliberately trying to acquire.

Do not discover your known scaling limits using customers you paid to bring in.

Scaling Problems Are Also a Sign of Success

Even with good preparation, you will not predict every problem.

Every successful application eventually discovers issues that only appear at scale.

A database query that seems instantaneous with 100 records may become painfully slow with 10 million.

A race condition may occur only when several users perform the same action simultaneously.

A third-party API may behave differently when it receives hundreds of requests.

A background job might gradually fall behind.

A multiplayer service may perform well with ten matches but collapse with hundreds.

These are normal scaling problems.

If users love your product and demand is exposing technical limits, that is ultimately a good problem to have. It means you built something people want.

But it is still a problem, and you need to fix it quickly.

Users will not remain grateful that your product is popular while it loses their work, fails to load, or becomes unusably slow.

Scaling is not a one-time architectural achievement. It is an ongoing process:

Observe the system, find the current bottleneck, fix it, increase capacity, and repeat.

You should expect growth to reveal weaknesses that could not be reproduced at smaller scale. The goal is not to guarantee that no scaling problem will ever occur.

The goal is to detect problems quickly, understand them, communicate clearly, and fix them before they destroy user trust.

Acquisition, Product, and Engineering Are One System

Marketing is often treated as something that happens outside the product.

That is a mistake.

An advertisement may generate the click, but the landing page determines whether the user continues.

The onboarding experience determines whether the user understands the product.

The core loop determines whether they return.

The monetization determines whether the business earns revenue.

The engineering determines whether the experience remains fast and reliable.

The analytics determine whether you understand any of it.

These are not independent functions. They are parts of one connected growth system.

Acquisition, product experience, measurement, and reliability all have to connect.

The complete loop is:

Acquire → Activate → Retain → Monetize → Measure → Improve → Scale

Then repeat it.

Sometimes the advertising needs improvement.

Sometimes the landing page makes the wrong promise.

Sometimes the onboarding creates too much friction.

Sometimes the product is attracting the wrong audience.

Sometimes the technical performance is driving users away.

Sometimes the product simply is not valuable enough yet.

Advertising does not fix a weak product.

It exposes the weakness faster.

That can feel brutal, but it is useful. Controlled acquisition gives you evidence. It shows whether strangers, rather than friends and fellow developers, understand and value what you built.

Scale What Works, Stop What Does Not

Once you have acquired a cohort, measured its behavior, and estimated its value, you can make a decision.

• Stop the campaigns and channels that attract the wrong users.
• Improve the product where people encounter friction.
• Create new advertising based on the messages that resonate.
• Test different landing pages, store pages, videos, and calls to action.
• Improve onboarding.
• Improve performance.
• Improve retention.
• Improve monetization.

Then acquire another cohort and measure again.

When you find a combination of acquisition, activation, retention, and revenue that works, begin increasing the budget carefully.

Do not assume that a campaign that works at $50 per day will behave identically at $5,000 per day. Larger campaigns often reach broader audiences and introduce new operational problems.

Scaling should be deliberate.

Increase traffic, observe the results, and verify that the economics and infrastructure continue to hold.

Some products spend 10 months or more in a “soft launch” phase, working out problems before applying marketing dollars at scale. Sometimes the team cannot solve those problems, decides the product is not worth scaling, and starts building the next product with those lessons in mind.

You Do Not Need a Giant Budget

The systems I learned while working on games with millions of players were built for enormous scale.

You probably do not need that scale.

You do not need a dedicated user-acquisition department, a data science team, and millions of dollars in advertising to apply the same discipline.

You need:

• A clear promise
• A product that delivers that promise quickly
• A defined activation event
• Basic analytics
• A controlled source of users
• A way to measure retention and revenue
• Enough technical capacity for the traffic you are creating
• The willingness to change the product when the evidence tells you to

AI has reduced the cost of turning an idea into working software.

It has not eliminated the economics of attention.

It has not eliminated the need for good product design.

It has not eliminated the need for reliable engineering.

And it has not eliminated the need to give users a reason to return.

The goal is not simply to get users.

The goal is to build a repeatable system that acquires the right users, demonstrates value quickly, retains them, earns enough to support continued growth, and remains reliable as the audience expands.

The ad buys the first visit.

The product has to earn everything after that.