I can build the product with AI. Getting the first users is harder.

With Brainy and MoneyBrain, getting the first users and growing monthly recurring revenue has been harder than building the software.

At the beginning, I used my circles on LinkedIn. It gave me somewhere to start talking about the products. Expanding beyond that network has been difficult, especially without a large budget.

That is where I want to pick up from my previous post about building products with AI. In that post, I described how I move from a brainstorm to requirements, GitHub issues, implementation, and a reviewed pull request. I can give the implementation work a scope and check the result against it.

Finding users leaves me with questions I am still working through: where to reach people who need the product, and why they would try it, return, and eventually pay.

My network gave me a place to start

Talking about Brainy and MoneyBrain on LinkedIn was a reasonable first step. I already had people I could reach there, rather than starting with an empty account and hoping someone would find a product announcement.

But a professional network is a particular audience. Someone can be interested in how I build software without needing either product. A post about my AI workflow and a post explaining why someone should use an application ask for different kinds of attention.

More visibility for me would be useful, but I also need to understand which people have the problem the product addresses. Otherwise, I could spend more time promoting it and still learn very little about demand.

A screenshot of a SaaS advice post brought this back into focus. It covered familiar recommendations: promote the product, talk to users, keep the first version small, use it yourself, and pay attention to people who leave.

Reading those points alongside my experience, I kept returning to the difficulty of reaching the next group of people without a large budget.

The post puts most of the work after launch into marketing. I would not assign a fixed percentage to it, but I agree with the underlying reminder: launching leaves a substantial amount of work ahead. For my current goal of finding users, time spent explaining the product and following up with people deserves a place in the schedule alongside implementation. Another completed issue does not tell me whether anyone new understood the offer.

Reaching outside my LinkedIn circles

The encouragement to promote the product openly is useful. Staying entirely within my familiar LinkedIn circles would leave the same audience boundary in place. I need to be willing to explain what I have built somewhere people do not already know me, and to hear that it may not be relevant to them.

I could make a long list of places to post. Each one would take time to understand, participate in, and follow up on. I would also have to decide what to say there, because a product announcement that makes sense to my LinkedIn contacts may mean very little to a stranger.

For Brainy and MoneyBrain, I would rather make the next attempt narrow enough to learn from. Pick one product, one specific problem, and one place where people already discuss that problem. Then explain or demonstrate the part of the product that addresses it.

I also need to make that choice separately for each product. The fact that I built both does not mean the same people need both, or that the same explanation will persuade them. Putting their names into one announcement is convenient for me; a potential user needs a reason to care about the particular application in front of them.

I could examine the result: did people recognize the problem, ask how the product handles their situation, or try it?

If the only response is interest in the technology behind it, that would tell me something too. I might have reached other builders, or explained the implementation more clearly than the reason to use the product.

I feel the budget constraint, but I do not want to turn that into a conclusion that growth requires a large advertising spend. I have not established that. Before spending more, I want a clearer idea of whom I am trying to reach and what I can show them.

A useful next asset could be a short walkthrough of one task, using demonstration data and showing the result. I could use it in a relevant conversation, give the landing page something concrete to show, and learn which part needs more explanation. A tutorial answering a question prospective users already ask could also become something they can find or share later. These would give me more to work with than repeatedly announcing that the product exists.

A community, a search-focused article, or a collaboration needs to earn the time I put into it. A channel with no advertising bill still costs time. Participating well in a community means reading the discussions, respecting its rules, and contributing something useful before expecting attention for my application.

The alternative is often something people already do

Before writing that walkthrough, I need to understand what the person would replace. They might already have a tool, a document, or a routine that handles the task adequately. Moving to my product could mean learning another interface and spending time setting it up before they see a benefit.

My own move from Notion to Brainy is a useful example of an existing workflow being involved. It gives me a case to examine, but another person's reasons to change could be different. I need to ask which part of their current approach is frustrating enough to justify the effort of switching.

That should shape the product description. Explaining the task someone can complete gives them a way to judge the offer. Describing my AI-assisted development process tells them how I made it. I enjoy talking about that process, and it belongs in the previous post, but it may have little bearing on a person's decision to use Brainy or MoneyBrain.

Even the comparison with competitors needs this context. A competing subscription price tells me one thing about the market; a person's current workaround tells me what I would have to improve. If their approach is already good enough, I need to understand that answer instead of assuming another feature will persuade them.

The first visit needs somewhere useful to go

Someone outside my network needs to understand the product without knowing my background. That makes the advice about the landing page and sign-up process more relevant.

A useful check would be to ask someone unfamiliar with the project to look at the page and explain what they think it does. Then ask them to attempt its main task. I would want to see where they hesitate before adding another feature to the backlog.

That is how I read the advice to make a landing page clean, fast, and convincing. Keep the page focused, check how it loads on a phone, and show a concrete use of the product. A polished layout still needs to help that unfamiliar visitor decide whether to try it.

Google login might remove a step for some people. It cannot explain an unclear product promise, and I would not treat it as an automatic requirement for every audience. The question I want to investigate is where a prospective user gets stuck between understanding the offer and experiencing something useful.

Using my own product regularly gives me a way to notice friction in ordinary tasks. In my earlier post about moving to European digital services, I described replacing Notion with Brainy. That is a useful starting point for testing a real workflow. But I know the product's intended behavior and can navigate around something that another person would find confusing. My familiarity is a reason to get an outside view, especially when I am asking that person to trust a new product.

Keeping the minimum viable product small belongs in this discussion too. I want enough functionality to let someone complete the task that brought them there. Adding features before understanding that task could make both the explanation and the first visit more complicated.

The screenshot names MoSCoW as a way to keep that scope under control: Must Have, Should Have, Could Have, and Won't Have this time. The Agile Business Consortium explains those priorities. For a first release, I would ask whether leaving a feature out prevents the intended user from completing the core task. If it does not, I need a good reason to put it ahead of learning from users.

For the first users, I would also consider helping them through that task personally. Paul Graham's essay on doing things that don't scale argues for recruiting early users manually and paying close attention to their experience. I can see a practical application here: offer a short walkthrough, watch where the person needs help, and use that observation to improve the next attempt.

If I have to explain the same step to everyone, that gives me something specific to investigate in the interface or instructions. If each person wants a completely different outcome, I need to revisit the audience and scope. Automating the welcome messages before understanding those differences could leave me sending more people through a confusing experience.

Trust is part of the first useful experience

There is another reason someone might hesitate even after understanding the product: they have to decide whether to put their information into it. A demonstration with sample data can reduce the effort needed to evaluate the workflow, but using the application for real asks for more trust.

For any task involving personal or financial information, I would want the product to explain what it stores, what happens to that information, and how a person can leave. Those explanations need to match the actual implementation. I cannot make a privacy or security promise simply because it would look reassuring on the landing page.

Support belongs in that decision too. A person should be able to find a way to report a problem and understand what help they can reasonably expect. As an independent builder, I need to be honest about that commitment. Offering personal onboarding is useful only if I leave enough time to follow through.

This is part of what makes a small MVP a serious product decision. I can defer optional features while still needing a dependable core workflow. If the application loses the work someone just entered, a smaller backlog does not make their experience acceptable. The scope has to include the behavior people rely on, and I need to check it before asking them to move a real task into the application.

Growing MRR asks more than whether someone signed up

The screenshot recommends charging from day one instead of offering free trials. There is a useful question behind that advice: will someone pay for the outcome? A payment is more direct evidence of willingness to pay than an encouraging comment on LinkedIn.

I would still make the trial decision around the product. If someone needs to use it with their own information or across several days to judge the benefit, a trial could help them decide. If the value can be demonstrated clearly before purchase, charging immediately may make sense. I would not dismiss every free user as unserious; their experience can reveal a problem that also affects paying users.

Monthly recurring revenue is an objective I care about. To make progress toward it, I need to understand what would justify an ongoing payment from the people I am trying to reach. Choosing a price or removing a free trial does not answer that question on its own.

The advice to price based on value is more useful to me than copying another application's subscription page. I would want to ask about the task a person is doing now: how they handle it, what is frustrating, and what a useful improvement would look like. Time saved, a recurring task made easier, or a mistake avoided could give the discussion a concrete basis. Those are possibilities to investigate, not benefits I can assign a monetary value to without talking to people.

Those conversations could happen through a DM, an email, or a short call, depending on what the person prefers. A focused question about what they tried to do would give me more to work with than asking whether they like the product. I would also want to hear from someone who created an account and then stopped, rather than only from people willing to praise it.

This is where retention belongs alongside the work of finding new users. If people try the product and do not return, reaching a larger audience leaves that question unresolved. I would want to understand repeated use before scaling the same acquisition attempt. For a recurring subscription, whether people keep finding a reason to use the product matters to the revenue goal too.

If a person leaves, an optional conversation could help explain what happened. I would make unsubscribing or cancelling straightforward, and respect a person who does not want to explain. An email opt-out might mean they want fewer messages; a product cancellation asks a different question. Either can be feedback, but neither gives me a reason to argue with their decision.

I also need to understand the expected frequency of the task. Someone may get value from a product every week or at a particular point in the month. Daily activity would be a poor way to judge that experience if daily use was never the goal. I would look for people returning when the need occurs and completing the task they came for.

Feedback from those conversations needs a decision attached to it. A request for another feature might reveal a missing step in the core workflow, or it might describe a different product. I would record what the person was trying to accomplish before putting the request into the backlog. That gives me a way to compare it with other needs instead of letting the most recent message determine the next epic.

I need to know where the attempt stops working

Once I start trying channels outside LinkedIn, a total sign-up count will leave too much unexplained. I want enough visibility to distinguish a message that people never saw from a product they tried and then abandoned.

A simple record could follow the path from first contact to continued use:

That main task needs a definition for each product before its completion becomes a useful signal. Opening a dashboard might only show that registration worked. The meaningful action should reflect what the person wanted to accomplish, and any measurement should collect only the information needed to understand that behavior.

With a small number of users, raw counts and conversations need to sit alongside any percentages. A few people leaving at one step would justify looking at it; it would not give me a reliable explanation of why everyone leaves. The channel context matters too. People arriving from my existing network may behave differently from people encountering the product for the first time.

This could make the next decision more specific. If people understand the offer but cannot finish the task, I have something to investigate in the product. If the people I reach do not recognize the problem, I need to examine the audience or message. Changing both at once would make it harder to understand what helped.

The costs behind the MRR goal

MRR also needs more detail than one rising total. Stripe's explanation of monthly recurring revenue separates growth from new subscriptions and existing customers increasing their subscriptions, and reductions from cancellations or downgrades. Those movements describe different situations that I would want to understand separately.

For example, new subscriptions could increase the total while existing subscribers leave. I would want to see both movements before deciding to repeat the acquisition effort. A larger total on its own would not explain whether the product is keeping the users it already reached.

Then I need to compare recurring revenue with the costs of providing the service. Hosting, payment processing, and support take resources. Where a product uses paid external services, their usage belongs in that calculation too. MRR measures recurring revenue; it does not show what remains after those costs.

The implementation workflow has costs as well, and the time spent helping users has to fit into the week. Even if AI makes an implementation task cheaper for me, I still need to maintain the behavior it introduces and answer questions about it. That is another reason to keep the scope of a growth experiment manageable.

A lifetime deal offered simply to produce early cash would deserve particular scrutiny. An ongoing service creates ongoing work, while a one-time payment has a different revenue shape from a recurring subscription. Before making that offer, I need to understand the support commitment it would create. This is a possible decision to examine; I am not reporting a pricing change to either product.

Ambition needs a reason to continue

The post also encourages builders to aim beyond their first revenue milestone. I like the challenge to think about what a product could become. At the same time, a larger MRR target needs some basis: who else could benefit, how I could reach them, and whether they would keep using it. Changing the number in a goal would leave my current acquisition problem untouched.

For Brainy and MoneyBrain, I want the next milestone to answer one of those questions while leaving room for a bigger ambition.

What I want to do with the next cycle of work

My next useful step would be to give one attempt at finding users the same attention I give an implementation task. Choose a specific audience and problem, make a small attempt to reach them, and leave time to follow up with anyone who tries the product.

A short note for each attempt could record the audience, the message, where I shared it, and what happened afterward. Including the effort spent, even if no money changed hands, would give me something to compare when deciding what to repeat.

For this purpose, focusing on one product at a time would make the follow-up easier to manage. Brainy and MoneyBrain can both remain part of my work, but trying a new audience and message for both simultaneously would divide that attention. AI gives me a way to move implementation forward; I still have to make room in the week to understand the people using the result.

I would set a review point before starting. With a limited budget, I need to consider the time spent as well as the money. Continuing an experiment should depend on what I learn from it; persistence alone would not tell me whether to repeat it, change it, or stop.

That connects two pieces of advice in the screenshot: stay in the game, and consider moving on when the product does not make money. If the goal is a business, revenue and costs need an honest review. Personal usefulness can be a separate reason to maintain it, but it does not establish commercial demand. I want to give a promising idea a fair test without treating every additional month of work as evidence that it will succeed.

I still value the workflow from the previous post. It helps me turn a product idea into software I can review. With Brainy and MoneyBrain, my immediate challenge is to take the next step beyond my LinkedIn circles and learn why someone unfamiliar with me would choose to use what I built.

AI assisted with drafting and editing this post and generating the cover image.