I Built VermietNavi, Got Zero Applications, and Shut It Down

My usual process is simple: understand the problem, shape the idea, build a first working version, and put it in front of real people. I only continue with products that receive a meaningful response.

I care about the journey as much as the outcome—the doubts, technical decisions, mistakes, and the moment when the evidence says it is time to stop.

With VermietNavi, I broke my own sequence. I moved too quickly from a plausible problem to product development and left serious demand validation until the end.

The idea came from an AI agent I was using to explore SaaS opportunities. It pointed to private rental hosts in Germany: Airbnb and Booking.com calendars, occupied-night tracking, documents, deadlines, and local accommodation taxes. On paper, the problem looked convincing.

I accepted the logic. The pain appeared real, the audience looked identifiable, and Germany seemed like a market with enough purchasing power. But I made a huge leap from “this inconvenience exists” to “people will pay for a dedicated product.”

VermietNavi was designed as a web application for private hosts managing one or several properties. It would bring together information normally scattered across Airbnb, Booking.com, spreadsheets, folders, and notes.

The planned product included:

• iCal calendar imports;

• combined occupied-period views;

• review of ambiguous entries;

• booked-night tracking;

• deadlines and tasks;

• document organisation;

• City Tax preparation;

• official rules and sources;

• separate records for multiple properties.

I did not want to build another huge property-management system. The proposition was deliberately narrower: less manual reconciliation, less administrative chaos, and one clear view per property.

I introduced two prices to test willingness to pay: Solo at €14.90 per month and Plus at €24.90. I did not connect payments. The conversion target was an application with a selected plan—enough to reveal an initial buying signal.

The AI agent handled a large part of the technical workload. It helped me:

• review the references and unify 12 product screens;

• build a responsive German landing page;

• implement plan selection and the application form;

• connect Supabase for lead storage;

• configure Vercel and the domain;

• set up email through ImprovMX;

• preserve UTM parameters and referrers;

• add Vercel Analytics and Google Ads conversion tracking;

• test form submission, deduplication, and production deployment.

Technically, this became much more than a basic smoke test. It was an almost complete product funnel: interface, backend, database, email, analytics, and paid acquisition.

That development speed created a dangerous illusion of progress. Every new screen felt like forward movement. In reality, I was becoming more attached to a hypothesis the market had never validated.

AI is excellent at accelerating execution. But it does not carry the financial risk, and it cannot feel the market on behalf of a founder. A confident explanation can sound like evidence while remaining only a plausible model of reality.

The final responsibility was still mine. I should have stopped earlier and demanded customer evidence rather than more arguments.

I allocated €100 to Google Ads. The campaign spent €71.06 before reaching its scheduled end date, leaving €28.94 in the account.

The domain cost approximately another €5. I also paid for Vercel and Supabase separately, as I use independent production infrastructure for each project. I am not inventing a combined infrastructure figure here, but the real experiment cost was clearly higher than €76.

That still excludes my time: analysing the market, revising the interface, checking mobile layouts, configuring email, managing ads, and making dozens of smaller decisions.

The most expensive resource in an experiment like this is not the domain or even the advertising budget. It is the time and attention that could have gone into a different hypothesis.

I chose Google Search for the first paid test. The reasoning was straightforward: if private hosts were already looking for software to manage calendars and properties, search ads should reach people with the strongest existing intent.

The campaign ran across Germany from 4 to 10 September 2026. Display traffic, AI Max, and broad match were disabled. I used exact and phrase match, a €28 daily budget, and Maximise Clicks.

The primary conversion was a genuinely stored application. Page views, button clicks, and direct visits to the thank-you page did not count.

That measurement design was correct. The keyword strategy around it was not.

The final campaign results were:

• 174 impressions;

• 15 clicks;

• 8.62% CTR;

• €4.74 average CPC;

• €71.06 spent;

• zero applications;

• zero customers;

• zero revenue.

The CTR could have looked encouraging. People noticed the ads and visited the site. But I did not need clicks. I needed potential customers willing to select a plan and leave an email address.

Not one person did that.

The analytics made the situation even clearer. Among tracked Google visitors, nobody selected a plan and nobody started the form. Supabase contained no real application.

That was the point at which technical explanations stopped mattering. The funnel worked. People simply did not enter it.

The keyword consuming the most money was buchungskalender ferienwohnung. It generated eight clicks and spent €49.45 at an average of €6.18 per click.

When I inspected the actual search terms, I discovered that people were not looking for SaaS. They wanted:

• printable occupancy calendars;

• ready-made templates;

• booking schedules;

• specific competing services;

• information about fees on other platforms.

At least eight of the fifteen clicks were clearly irrelevant. They consumed €36.41—more than half of the total ad spend. Google placed another six clicks under Other search terms, making their quality impossible to inspect.

This was both an AI-agent mistake and a failure of my own review process. I should have validated keyword volume, commercial intent, and the live search results before launching. Instead, I treated semantically related phrases as evidence of buying intent.

When I previously sold baby strollers from a specific brand, the situation was entirely different. People knew the product, searched for its name, compared offers, and were already close to buying. Clicks were cheaper and conversion was exceptionally high.

With VermietNavi, I first had to explain the problem, introduce an unfamiliar product, prove its value, and only then ask for a plan selection. That creates very different economics.

At the observed average CPC of €4.74, the projected cost per application would be:

• €94.80 at a 5% landing-page conversion rate;

• €47.40 at 10%;

• €31.60 at 15%.

An application is not yet a customer. If only 20% of applications become paid subscriptions, even the 10% landing-page scenario produces an acquisition cost of approximately €237 per customer.

That is a weak foundation for a subscription priced at €14.90–€24.90 per month. Recovering the advertising cost alone would require months of retention before taxes, support, infrastructure, and churn.

TikTok, Telegram, or Meta might have generated cheaper impressions. But cheap traffic does not create willingness to pay. Google users were at least actively searching for something. On social platforms, I would first have had to manufacture awareness of the problem itself.

I did not want a channel that could produce an attractive click count. I needed a business signal.

I could have blamed Google Ads alone, rewritten the campaigns, added languages, moved to another platform, and spent several hundred euros more.

But that would no longer have been research. It would have been a defence of an idea I had already invested in.

When I looked at VermietNavi as if it belonged to someone else, I saw several fundamental weaknesses:

• the standalone product was too narrow;

• it promised organisation rather than obvious revenue growth;

• many users could solve the problem with a spreadsheet or their existing PMS;

• regulations and City Tax rules varied by city, increasing maintenance costs;

• high-intent search demand was difficult to identify;

• acquisition cost did not match the subscription price;

• not a single visitor took the first step toward applying.

I therefore decided to stop developing VermietNavi, avoid adding payments, buy no more traffic, and resist the temptation to “win back” the money already spent.

The code, design, and infrastructure patterns can remain useful experience. But the product itself is no longer an active business.

1. I will not confuse a logical problem with a validated market

A problem may exist without being painful enough to justify another subscription.

2. I will not build a complete product before testing willingness to pay

My next test should begin with interviews, a manual offer, a preorder, or a deposit. A polished frontend and production backend can come later.

3. I will not delegate market judgement to AI

AI is a powerful research and execution tool. Its confidence is not data. I will independently verify search volume, CPC, competitors, and user intent before launching.

4. I will calculate acquisition economics before buying traffic

Product price, acceptable CAC, paid conversion, and payback period should determine the maximum CPC—not the other way around.

5. I will look for existing financial behaviour

The strongest signal is not “this sounds useful.” It is evidence that people already spend money, time, or labour solving the problem.

6. I will limit the total cost of validation, not only the ad budget

The experiment cost includes the domain, Vercel, Supabase, email, and—most importantly—my time. A smoke test must be small in development scope as well as ad spend.

VermietNavi did not become a business, but it changed how I approach product experiments.

AI allowed me to move from idea to production extremely quickly. It also revealed the dangerous side of that speed: today, it is possible to build a convincing product faster than it is possible to understand whether the market wants it.

My original principle remains valid: idea → validation → product → growth. But “validation” no longer means analysing a problem or creating a polished first version. It means a real customer action—an application, a preorder, a deposit, or a payment.

Without that, the product has not truly begun.

Sometimes the best outcome is not to continue at any cost, but to admit that the hypothesis remains unproven, preserve the lesson, and move on to the next idea.