Setter AI: $10K MRR in a Year and a Half — a Prototype Sold Two Weeks After the Idea

Josef Büttgen’s B2B SaaS “Setter AI,” co-founded with a partner, uses AI to automate lead qualification and follow-up and books sales meetings automatically. Current monthly revenue is $10,000 (about $120,000/year, roughly ¥18M). The number itself isn’t dramatic. What makes this case worth reading is that the same developer had, right before this, spent roughly a year on a product that went nowhere — and the order of operations was completely reversed between the two.

(Amounts are converted at an approximate rate of $1 = ¥150 throughout.)

The previous product next to this one

Büttgen taught himself to code at age 13, freelanced, and then went all-in on entrepreneurship. During two years traveling Southeast Asia he discovered the indie-hacker world, and his first product was a business tool built for a real-world shop his girlfriend at the time was running. But it never grew beyond that single shop. He then spent nearly a year on CourseStart, and usage still didn’t grow.

Why he backed himself into “12 startups in 12 months”

In this situation, Büttgen took on a self-imposed challenge: launch 12 startups in 12 months. The motivation wasn’t forward-looking ambition, in his own words, it was “mounting anxiety over a shrinking runway.” When the time before your money runs out is limited, betting a full year on a single shot isn’t a viable strategy. Increasing the number of attempts was, effectively, the only option left.

Büttgen says he learned from CourseStart both “from what I did, and from what I should have done but didn’t.” What’s implied here is a structure where the building side kept getting effort while the selling side got neglected. The truer reading is not that a year of work failed to confirm demand, but that a year passed while the act of confirming demand itself kept getting postponed.

The decisive move: it was already sold before it was built

The turning point in this case came not from Büttgen’s side but from the other party’s. In month three of the challenge, he got a message from someone he’d previously discussed an idea with. That person, with no product and no marketing yet in place, had already set up a landing page and booked demo meetings.

By the time the two of them teamed up, there was already proof that someone would pay for this problem to be solved. In the previous product, evidence of demand was something he’d searched for while building. This time, the evidence came first and the building came after. Büttgen’s advice, “always sell before you build”, points directly at this reversal of order.

As a result, the two of them shipped a prototype within two weeks of starting, and got it to a sale on top of that. What separated this from the previous product, which produced nothing over a full year, was neither skill nor technology but whether demand had already been established at the moment of starting.

The technical reason two weeks was possible

Sequence alone doesn’t get you to two weeks. There’s another mechanism at work. The AI voice-calling assistant they originally envisioned would have been difficult to build from scratch, and building it out themselves would have burned months. The two didn’t build it themselves. They used existing APIs and cut implementation work further by building on a boilerplate. The stack was SvelteKit, Supabase, DaisyUI, Clerk, and Netlify Functions, a combination that fills in both auth and delivery with off-the-shelf pieces.

“Having no proprietary technology” looks like a weakness, but at this stage it works in the opposite direction. What they needed to validate was “will people pay to have AI handle meeting-setting for them”, not “can we build our own speech synthesis.” Narrowing what needed to be differentiated early is the substance behind the two-week speed.

Büttgen’s advice on this phase is delivered fairly bluntly: “Don’t think. Literally. When you’re at zero, you have no material to think with. Make noise first, think later.” The point is that deliberation without any decision-making material is, in practice, indistinguishable from stalling. He also says “business isn’t like software”, developers need to accept both rejection and shipping something incomplete.

Revenue is built in two layers

Billing is subscription-based, tiered by the number of leads processed through the system, with a limited free tier. Separately from self-serve users, high-value customers are sold an initial setup as a flat one-time fee.

Acquisition is mainly SEO, churning out listicles, statistics pages, and comparison/alternative pages with clear search intent. Visibility for the term “AI Appointment Setter” is said to drive traffic. A free tool is also placed as a lead magnet to collect email addresses that feed into a newsletter.

Where this case is thin

To be honest, the disclosed numbers are coarse. Customer count, price distribution, churn rate, and the level of the setup fee are all undisclosed, and it’s not clear how the $10K/month breaks down between subscriptions and one-time fees. The “$10K after a year and a half” pace also isn’t fast compared to flashier cases in the space.

Another detail: it was the co-founder who brought in proof of demand, Büttgen didn’t unearth it himself. What this case demonstrates is “the effectiveness of pre-selling as a method,” not “how to pull off pre-selling entirely on your own.” The stated target of $1M ARR is more than 8x where they currently stand.

The phrase “$10K/month after a year and a half” also deserves careful reading. Because the prototype sold within two weeks of starting, time to first revenue was extremely short. The following year and a half was the buildup period from that first sale to $10K/month. What pre-selling shortened was the distance to “the first dollar”, not the distance to “a level that constitutes a viable business.” That’s the more faithful reading of the numbers.

What’s reproducible, and what isn’t

What’s reproducible: establishing proof of a sale before you start building, cutting implementation scope by filling in non-differentiating parts with off-the-shelf APIs, and building long-term traffic through content with clear search intent. None of these require capital.

What’s hard to reproduce: the urgency of a shrinking runway that forced a higher number of attempts, and the appearance of a co-founder carrying a validated deal. The former shouldn’t be emulated, and the latter is largely a matter of luck. More valuable to take away than the “build 12” framework itself is the constraint it forced: don’t spend a year on a single shot.

Related reading

• ScrapingBee — a small-team developer SaaS built and carried all the way to an exit
• Plausible — a bootstrapped, content-led SaaS that reached $1M ARR