Jonathan Geiger Built the Foundation for the Next Business by Selling Small Products

What Remained Even Without Revenue from the First Product

Jonathan Geiger kept resources for his next business even from products that performed poorly. He put roughly 120 hours over about a year into his first product, LectureKit, but not one of its 190 signups became a paying customer. He reached the stage of finishing the product and getting people to sign up, but it did not turn into a business that kept charging money. He left the service untouched for a while, then sold it for $6,750 after receiving an acquisition offer.

Handing over LectureKit taught him how to put a product into a tradable shape. His handover write-up, published in February 2025, covers moving the code to the buyer's repository, transferring the database and domain, and copying content stored in AWS to a new account. Even for a service with weak sales, working software and a running environment were something to trade. Winding down his first business let Geiger recover part of his development costs and gain the practical experience he would use in later sales.

With WaitListKit he stopped at an earlier stage. He took one pre-order payment, but after judging whether it was a product he wanted to keep developing, he refunded the buyer and dropped the project. The reason for stopping here should be distinguished from a conclusion that there was no demand at all. Even after confirming buying intent, if the operator lacks the will to keep building it over the long term, he could settle the promise and move on to the next attempt.

An Experiment in Selling a Cheap Starter Kit

NextUpKit was an experiment in selling a cheap developer tool. Introduced in January 2025, it was a Next.js starter kit bundling the features he implemented over and over, such as login, payments, and database connections. The price at the time was a $20 lifetime license, aimed at individual and beginner developers who found competing products costing hundreds of dollars too much to bear. He tried to explain what the buyer would get and to set himself apart by lowering the initial cost.

The start was not bad. Geiger said he sold three in the 24 hours after launch, and two of them came from an advance waitlist. A NextUpKit notice placed at the bottom of LectureKit contributed to the waitlist traffic. The earlier service that had failed to land paying customers was also used as a channel to announce the next product.

A few early purchases did not make the problem with the product description go away, though. From the community came opinions that people could not tell exactly what was being sold, criticism that the technical documentation was thin, and responses that the reason for requiring a GitHub username during purchase was unclear. Geiger also admitted that if visitors did not understand what the product was for, then his explanation had not been enough. These responses show that the work of lowering the price and the work of making buyers comfortable enough to choose require separate effort.

NextUpKit later recorded about $400 in cumulative revenue, and Geiger switched it to free open source. Each earlier attempt was handled differently: a sale, a refund and shutdown, a free release. He did not choose to hold on to every product as a paid business.

Choosing Markets Where Customers Already Pay

Going through these experiences sharpened his criteria for picking the next idea. He looked for two or three competitors earning about $20,000 to $80,000 in monthly revenue in a field he understood. He used the competitors' revenue as evidence that customers were paying to solve that problem. On top of that he weighed whether he understood the customers and whether he could make a small but clear difference. Still, a competitor's results do not guarantee revenue for a new product, so the step of confirming payments from his own customers after launch was still necessary.

The product that fit those criteria well was CaptureKit, an API for taking screenshots and extracting web data. Building the minimum viable product took about three weeks, and over the first two months it gained more than 300 signups and seven paying customers. Monthly recurring revenue was $127, but the product was sold for $15,000 in about two and a half months. Even though the revenue was small for covering ongoing living costs, he could trade with a buyer who needed the finished technology.

What Geiger got from CaptureKit did not end with the sale proceeds. He said that while developing SocialKit he reused the patterns for authentication, payments, API key management, documentation structure, and the landing page. The next product could cut the work that went into common features already solved. The room to focus on a new customer problem came from the implementation experience of the previous product.

From Data Extraction to a Publishing API

SocialKit's role was to turn social media content into data that other programs could easily use. When a developer or marketer passed in a video URL, it returned transcripts, summaries, engagement metrics and the like so they could wire them into their own service or analysis work. It was a structure that reduced the burden on customers of assembling each platform's access method and video processing tools on their own. Applying web data extraction experience to a more specific use made the work the buyer hands over clearer too.

The work of gathering customers also started alongside development. Geiger said he prepared about 20 article topics early in SocialKit and set up landing pages for individual features and free tools. He also laid out plans to give early users a chance to use it and collect feedback, and to share content across several developer communities and social channels. While building the product he also built the routes people would arrive through and the touchpoints for getting their opinions after use.

The free tools and the paid API were connected so that the same problem was handled at different scales. For example, SocialKit offered a YouTube subtitle extractor and a video summarizer while also pointing to the API that performs that work from a program. Visitors could handle a small task themselves and see the results, and when they needed repeated runs or service integration they could consider using the API. This setup was a way to show the product's value through real results instead of relying only on the copy.

PostPeer took on the problem of publishing content to social media. According to the founders' account, an apparently simple feature took a lot of development time because each platform has different APIs, account connection procedures, and credential management. PostPeer bundled this work into a single API so content could be published to multiple platforms. The two products differed in function, one extracting data and the other publishing it, but the direction of the business carried on: taking on the work customers repeatedly implement and maintain.

A Third Sale and the Next Choice

PostPeer was built with Yoav Mendelson. Mendelson also had software and SaaS development experience, and in his official profile described his role as building an API that is fast, predictable, and easy to integrate. Geiger chose collaboration as he widened the product range. He kept the experience of building products alone, but did not fix the operating model of the new product in advance.

In the sales structure he separated the stage where customers try the product from the stage where they use it in earnest. The public pricing pages for both products offer subscription and usage-based purchase options, and PostPeer provides 20 free credits for testing. The setup lets customers who have checked the results at a small scale choose the payment method that matches how often they use it. It also opens a path into paid use for customers who find it hard to commit to a long subscription from the start.

The adoption burden buyers feel was also addressed on the sales pages. The pricing pages of SocialKit and PostPeer carry customer testimonials emphasizing an easy connection and fast support. PostPeer in particular includes a testimonial about connecting several platforms in a short time and one about receiving support until the problem was resolved. Beyond features and price, both products provided information that reduced customers' worry about whether they could actually use the product after buying.

The combined monthly revenue of SocialKit and PostPeer disclosed in a July 2026 interview was about $6,400. The breakdown was about $5,200 in monthly recurring revenue and about $1,200 in one-time purchases, and the two figures combined are not all recurring revenue. It was the point where the experience of building and winding down small products led to sustained sales from the two API products.

After that Geiger also announced the sale of SocialKit. The figures he disclosed at the time were $23,150 in cumulative revenue, $3,317 in monthly recurring revenue, 117 active subscriptions, and more than 21,300 signups. On X he explained the deal size as $85,000, combining $75,000 in sale proceeds and $10,000 in consulting fees. It was the third sale after LectureKit and CaptureKit, and this time he handed over a business that had already secured recurring revenue.

In the acquisition announcement he stated a plan to focus on PostPeer together with Mendelson. He did not fix even a grown product as something he had to keep holding, and judged it alongside the business he would focus on next. The sale experience he learned winding down his early products carried into the choice around a larger business.

What made the next attempt more favorable in Geiger's path was turning earlier results into concrete changes. He filled in explanations customers did not understand, reused recurring development work, and narrowed his choices to fields where paying customers existed. He wound down products he had no will to keep running, and for products he intended to grow he prepared customer acquisition and payment paths together. Even when the first product's results are small, the starting conditions for the next product can be improved, and when those improvements continue, repeated attempts accumulate into a single set of business capabilities.