Landing a First Customer with a Customer-Finding Tool: Leadverse

The Customer Problem Found on the Fifth Attempt

Jakub Mužík described Leadverse as roughly his fifth project and the first one that started to make money. It was a service for developers who build products but cannot find customers, pointing them to posts by people who are already looking for a related solution. He used his own tool to find potential customers while developing and selling the product.

Mužík worked as a Salesforce developer for eight years. His start in building his own products was a mobile app for listing nearby events, made for his bachelor's thesis. When people downloaded the app and responded well, he began making other products in his spare time, but most earned $0 in revenue.

The idea for Leadverse came from a Reddit post. The author asked developers what they were building and offered to find posts from people who needed that product. Seeing hundreds respond, Mužík judged that there was demand in customer discovery itself. It was a chance to connect developers who needed someone to explain their product to with users looking for a product that solved their problem.

While keeping his day job and freelance work, he built alone at night and on weekends, and the first version took about a month. The early product pulled posts from Reddit and X and picked out the ones relevant to the user's product. When a user entered a product description and the kind of customer they wanted, the AI assessed relevance and also suggested replies suited to each post's context. It also let users export search results to a CSV file or check for new posts periodically.

Showing Search Results as Sales

Improving search quality started with distinguishing what the user wanted. The same post had different value for someone seeking a job and someone seeking customers. Mužík split the input fields into "the product or service you offer" and "the kind of conversation you want to find", and adjusted the prompts so they could apply to a range of purposes. He explained that this change let him reduce irrelevant results.

In selling, too, he showed search results first. He would post on Reddit asking to introduce a product in one line, then use his tool to find related posts and send them back. To one person who introduced a landing-page conversion improvement service, he reported finding 35 relevant posts and shared links to five of them. The other person could see what kind of results Leadverse delivered before going through a signup.

When approaching potential customers directly, he set the order of the conversation. First he left a public comment that helped with the problem the other person had, then in a private message he mentioned that problem and asked whether they would be willing to look at the tool. If they showed interest, he sent a link; if not, he ended the contact. The method Mužík shared tied finding relevant posts and keeping the conversation going while reading the other person's reaction into a single process.

These activities did not produce large revenue right away. About five months after launch, the figures he shared were $530 in monthly recurring revenue (MRR) and $1,696 in cumulative payments. New subscribers began arriving each week, but there was much to fix in the journey from signing up to trying the product and paying. Explaining the growth of that period, he also shared the changes he made to the trial method, the walkthrough video, feedback collection, and the checkout screen.

Fixing the Free Trial and the Pricing

Because the product used AI, even free usage incurred cost. Mužík said LLM API call costs accounted for about 90% of total costs. Keeping search result quality while adjusting prompts and models was therefore a key operational task. Alongside how fast users grew, he also had to watch the cost structure for supporting that usage.

He started with a freemium model that gave away a set number of search results for free. But many users tried it once and left, and the cost of serving them results kept accruing. Mužík switched to a three-day free trial that required card details up front. According to his account, fewer people started the trial, but the paid conversion rate rose, which helped reduce the cost burden.

Next he extended the trial from three days to seven. Some users could not fully see the product's value in a short period. He explained that conversion metrics improved after the extension. It amounted to combining a gate that confirmed intent to try through card registration with enough time to examine the results.

He changed prices several times as well. He began with plans at 9 and 14 euros per month, and said conversion improved about a month later when he switched to pricing in dollars. He later ran experiments lowering and raising prices, but recounted that in his service a price cut did not lead to better conversion. Rather than keeping a low price on the assumption that it worked, he adjusted the amount based on actual signup and payment behavior.

He also created an option matched to usage. He added a custom plan whose usage limit and price could be adjusted, and at the time he looked back, about 30 people had chosen it. The pricing structure changed further after that: on the official homepage checked on September 27, 2026, a single $49 per month plan and a seven-day free trial are presented. This shows that he did not treat the early low price and limited options as a finished policy.

Refining from the Landing Page to Checkout

On the landing page he reinforced the information needed to understand the product. He placed a video showing how it works below the first screen and put his photo in the contact section. He also changed the wording from "we" to "I", making clear that the product is run by one person. Real user testimonials were placed just before the pricing table and on the checkout screen, so they could be seen at the moment of deciding to buy.

He also replaced the checkout screen from a self-built form with a page provided by Stripe. That brought the step of completing payment into the scope of improvement. Mužík listed this change as one of the measures that helped improve a low conversion rate. Work on adding search features went on alongside work to help visitors who had already shown interest finish paying.

User responses also showed what the screens were failing to communicate. One person said it was a shame that the tool required a website address, and that it would be good if people still only planning a product could use it too. In fact the address field was optional, and Mužík replied that he should mark that more clearly. It was a case showing that even a feature that already exists can look to users like it does not, if the screen does not communicate it properly.

Mužík began sending an email requesting feedback seven days after signup and collecting a reason when someone canceled a subscription. In a later write-up of his operating experience, he also stressed the importance of a short onboarding that guides users through the first setup and how to check results. The point was that a developer knows their own tool well, but someone arriving for the first time may not know what to enter or which result to look at. Reviewing post-signup behavior and cancellation reasons became part of product improvement too.

Growing While Choosing Which Features to Keep

There were also attempts he stopped while adding features. According to FounderBase, which compiled interviews, Mužík tested a feature to browse Bluesky posts but dropped it after failing to find enough demand for discovering tools worth using there. This decision shows that what matters is not how many platforms are supported but how many valid potential customers can be found on each. Even inside a product that had begun generating revenue, not every expansion had to be kept.

In a post reviewing operations in his eighth month, he disclosed $2,653 in monthly recurring revenue, 107 paying customers, and $10,203 in cumulative payments. At that point too he was running it alone, with no cofounder, employees, or outside investors. He wrote that there had been times when growth stalled for weeks and he had doubts. What he emphasized in that period's retrospective was the daily work of promoting the product, writing, and reaching out to potential customers.

In an interview published on August 11, 2026, he cited about $3,300 in monthly recurring revenue, more than 130 paying customers, and over $20,000 in cumulative revenue. These figures are business revenue and do not mean the founder's net profit or the size of his assets. At that point his next goal was still to grow recurring revenue further and quit his day job.

What stands out in Mužík's case is the judgment to move on to a new product and the judgment to keep fixing a product that has started to get a response. After confirming paid demand in Leadverse following several attempts, he fixed the remaining problems in the trial terms, the pricing, and the first-use journey. Repeated launches were a process of finding an opportunity, and the improvements after payment began were a process of growing that opportunity into a lasting revenue source.