DEV Community: Pierre

How I Went From Burning €100 on Google Ads to $175 MRR in 5 Months

Pierre — Tue, 15 Sep 2026 15:56:16 +0000

Five months ago, my MRR was $0.

Today it's $175.

That number won't impress anyone on Twitter. No "we went from 0 to $10k ARR" energy here. But it's real, it's recurring, and it came from a process I can repeat — which matters more to me than the number itself.

This is the honest story of what didn't work, what did, and what I'm doing next.

Month 1: The Google Ads Graveyard

Like most first-time founders, I started with the obvious move: paid ads.

I set up a Google Ads campaign, pointed it at my landing page, and waited for the signups to roll in. €100 later, I had exactly zero paying customers. Not even a meaningful spike in free signups.

The worst part wasn't the €100. It was that I learned almost nothing. With a tiny budget, the algorithm never had enough data to optimize. My keywords were too broad, my ad copy was generic, and my landing page wasn't proven yet. I wasn't running a test — I was donating money to Google.

The lesson: paid ads amplify a funnel that already converts. They don't fix a funnel that doesn't. I had it backwards.

The Pivot: Treating SEO as a Compounding Asset

Instead of pouring more money into a channel I didn't understand, I made a deliberate bet: SEO is slow, but it compounds. Ads stop the moment you stop paying. Rankings don't.

So I committed to a simple rule: every single week, I improve my site's SEO. No exceptions.

That's it. Not a 30-day sprint. A weekly habit.

The Weekly SEO Loop That Actually Worked

Here's what I did every week, in order:

1. Run a technical audit. I used open-source repos to audit my own site — checking for broken links, missing metadata, slow pages, crawl issues, schema problems. You don't need an expensive tool for this. There are solid public repos that do the same job if you're willing to run them yourself.

2. Pull my Search Console data — with an MCP. Connecting an MCP to Google Search Console was a game changer. Instead of clicking around dashboards, I could ask questions directly: Which queries are getting impressions but no clicks? Which pages are stuck on page 2? What's my average position trending toward?

3. Fix one thing. Whatever the data pointed at, I fixed it that week. A weak title tag. A page that deserved internal links. A query where I ranked #11 and just needed a push.

4. Repeat. Week after week after week.

The compounding is real. Small gains stack. A page moving from position #12 to #6 isn't a win on its own — but do that across fifty pages, and your traffic curve starts bending.

Long-Tail Keywords: The Only Game Worth Playing as a Solo Founder

Early on I wasted time dreaming about ranking for big, juicy keywords. That's a trap. You will not outrank a funded competitor with a content team on a head term.

So I did the opposite. I deliberately targeted the easiest long-tail keywords I could find — the ones with low difficulty, clear intent, and almost no serious competition. Queries with 50 searches a month, not 50,000.

Here's why this works:

You actually rank. Momentum matters more than volume when you're starting.
The intent is specific. Someone searching a long-tail query usually wants exactly what you built.
You build authority. Enough small wins and the bigger keywords start becoming realistic.

Don't ask "where's the volume?" Ask "where can I realistically win?"

Directories and Backlinks: The DR Boost Nobody Talks About

While the content was cooking, I did something parallel: I listed my product in as many SaaS directories as possible.

Product Hunt. Alternative-to sites. Niche tool directories. Startup lists. Anything legitimate where a new product could get a listing.

Two things happened:

My Domain Rating climbed fast. Directory backlinks aren't glamorous, but they're real. Enough of them and your domain authority moves — which makes all your SEO work land harder.
I got actual traffic. Not massive, but real visitors with real intent, from people browsing directories specifically looking for new tools.

Plus, a Product Hunt launch brings that initial spike of visibility — and more importantly, feedback from people who actually tried the product.

Then the First Subscriptions Came

Here's the part that surprised me: it wasn't instant.

I didn't get a customer the week I started SEO. I didn't get one after the first audit. It took a few weeks of consistent weekly work before the first subscription landed. Then another. Then another.

The early subscribers came from search. People finding a specific page that answered a specific question, trying the product, and deciding it was worth paying for.

At $175 MRR, I'm not popping champagne. But here's what I do have:

A channel that keeps working while I sleep
Organic signups arriving without me spending a cent
Proof that someone, somewhere, wants what I built enough to pay for it

That's a foundation. And unlike an ad campaign, it doesn't disappear when the budget runs out.

The Honest Lessons

1. Don't buy growth before you've earned it. Google Ads on an unproven funnel is just expensive tuition. Organic traction first, then amplify.

2. Consistency beats intensity. One hour of SEO every week for five months beat every "growth hack" I tried. The boring thing, done repeatedly, is the thing that works.

3. Target what you can win, not what looks impressive. Long-tail keywords, easy directories, small wins. Momentum is a strategy.

4. Use the tools that exist. Open-source audit repos, an MCP connected to Search Console — I didn't need a big budget, I needed to actually look at the data and act on it.

5. If the number is small, say so. $175 MRR is $175 MRR. Pretending it's something else doesn't help anyone — least of all other founders in the same spot.

What's Next: Back to Ads (This Time, Smarter)

Now comes the part I've been avoiding.

Paid ads are my next step — and it's still the domain I know the least about. But this time the situation is different. I have a funnel that's been proven organically. I have pages that convert. I know which keywords actually bring buyers, not just visitors.

That's a completely different starting point than the €100 I blindly threw at Google five months ago. This time, ads are leverage on something that already works — not a substitute for product-market fit.

I'll write up what I learn, including the failures. There will be failures.

This is the story of building Podcastify — an AI tool that turns articles, PDFs, URLs, and videos into podcast-style audio conversations. If you're building something and grinding through the early days of SEO, hit subscribe — I write about what's actually working, with real numbers.

How I built an AI podcast generator that turns any content into audio conversations

Pierre — Wed, 06 May 2026 08:15:52 +0000

I read too much. PDFs, newsletters, long articles - my reading list is a graveyard of good intentions. At some point I stopped fighting it and just built a tool to listen to it all instead.

That's Podcastify: paste a URL, upload a PDF, drop some text, and get back a podcast-style audio conversation between two AI hosts discussing your content. Six weeks after launching, we have 3 paying subscribers. Not a hockey stick, but real people handing over real money for a thing I shipped. Here's how it works under the hood.

What it does

The core loop is simple:

You submit any content - a URL, a PDF, raw text, or an image
Gemini reads it and writes a Q&A-style conversation between two hosts
A TTS provider converts that transcript to audio, per speaker
The segments are merged into a single MP3, stored, and served back to you

The output feels like a podcast episode where two people actually discuss the content, not just read it aloud.

Architecture: why two phases

The pipeline is split into two distinct phases, and this wasn't just a design preference - it's a practical necessity.

Phase 1 - Transcript generation

Input → ContentParser → Gemini (LLM) → Transcript → Supabase

Phase 2 - Audio generation

Transcript → TTS (per speaker) → Audio segments → Merge → MP3 → Supabase Storage

Separating them means:

You can regenerate audio without re-running the LLM (cheaper)
You can inspect and even edit the transcript before rendering audio
Failures are isolated, so a TTS hiccup doesn't waste a Gemini call

Both phases run as Celery tasks behind a FastAPI backend, with Redis as the broker. Long-running jobs simply don't belong in an HTTP request/response cycle. A typical generation takes 30–90 seconds depending on content length and TTS provider.

The stack

Frontend:  Next.js 16 (App Router) + React 19 + TypeScript + Tailwind CSS 4
Backend:   FastAPI + Celery + Redis
Database:  Supabase (PostgreSQL + Auth + file storage)
LLM:       Google Gemini
TTS:       Factory pattern → ElevenLabs / OpenAI / Gemini TTS / Edge TTS

The frontend calls Next.js API routes, which proxy to the FastAPI backend. This keeps secrets server-side and gives us a clean separation between the Next.js layer (auth, UX, billing) and the Python layer (AI, heavy lifting).

For storage, a single Supabase bucket (audios_n_transcripts) holds both transcripts (JSON) and final audio (MP3). Row-level security keeps everything scoped to the generating user.

The hardest part: parsing anything

The promise, "submit any content", is easy to say and painful to implement.

The ContentParser service has to handle:

Web pages: rendered via Playwright (headless Chromium), because half the modern web is JavaScript-rendered and can't be scraped with a simple HTTP fetch
PDFs: text extraction, with layout awareness to avoid garbled column ordering
Images: sent directly to Gemini's multimodal endpoint
Raw text: trivial, but still needs cleaning and length normalization

Playwright in particular adds real overhead, it's a full browser. We run it in the Celery worker rather than the API process, and cache aggressively to avoid re-fetching the same URL.

TTS: the factory pattern

Different TTS providers have very different tradeoffs - latency, voice quality, cost, language support. Rather than hardcoding one, we use a factory:

# tts/factory.py
def get_tts_provider(name: str) -> BaseTTSProvider:
    providers = {
        "gemini": GeminiTTSProvider,
        "openai": OpenAITTSProvider,
        "elevenlabs": ElevenLabsTTSProvider,
        "edge": EdgeTTSProvider,
    }
    return providers[name]()

Each provider implements the same interface: synthesize(text, voice, language) -> bytes. Swapping providers is a config change, not a code change. This matters because TTS pricing and quality move fast, and we've already switched defaults once.

Monetization: card-first reverse trial

The billing model went through a few iterations. Here's where we landed:

No free tier - new signups must enter a credit card to unlock generation
7-day Hobby trial managed by Stripe, with trial_period_days: 7 and payment_method_collection: "always"
After the trial: auto-charge unless cancelled
Quota is enforced in audio characters (TTS character count), not generation count, which is fairer for users with varying content lengths

The middleware (proxy.ts) enforces the paywall: any generation attempt without an active subscription returns a 401 with a redirect to the checkout page. No subscription row in the DB = no generation, full stop.

This "reverse trial" approach (card first, trial after) filters out people who were never going to pay, and converts the ones who get value quickly. Three paying users in six weeks from a technical product with zero marketing spend. Not viral, but validated.

Lessons learned

Ship the infra first. The async job pipeline (FastAPI + Celery + Redis) was the most painful part to set up, but getting it right early meant every feature after was just another task type.

Two-phase pipelines are worth it. The ability to inspect and replay individual phases saved hours of debugging and reduced AI API costs significantly during development.

TTS quality is a product differentiator. Users notice voice quality immediately. The factory abstraction let us tune this without touching business logic.

Quota in output units, not input actions. Charging per generation sounds simple but punishes users who feed short content. Characters generated is a much better proxy for actual resource consumption.

Card-first converts. Adding the reverse trial (vs. a freemium model) was uncomfortable to ship but immediately filtered signal from noise.

What's next

Multi-language support (the TTS layer is ready; the LLM prompts need work)
Transcript editing UI before audio render
Podcast RSS feeds so you can subscribe to your own generated shows in any app

If you're building something similar or want to try it out: podcastify.io

Stack questions, architecture feedback, roast my code, happy to discuss in the comments.

PS : I am Pierre Kasparian an AI & data engineer who loves to build products in his free time. Feel free to reach out

I Built SMSimple-API : A Pay-As-You-Go SMS API for 2FA, Marketing, and Reminders

Pierre — Sun, 27 Apr 2025 09:12:29 +0000

Hey everyone,

I'm a solo developer and recently launched SMSimple-API, a lightweight SMS API designed to make sending text messages as straightforward as possible.

🚀 What Is SMSimple-API?
SMSimple is an SMS API built with simplicity and reliability at its core. Whether you're implementing two-factor authentication (2FA), sending marketing messages, or setting up appointment reminders, SMSimple aims to streamline the process.

✅ Key Features

Pay-As-You-Go Pricing: No subscriptions or hidden fees. You only pay for what you use.
Developer-Friendly: Clean, intuitive API with straightforward documentation.
Free Trial: Sign up and receive 4 free credits to test the service.
Dashboard Monitoring: Keep track of your usage and manage your account with an easy-to-use dashboard.
Responsive Support: As a solopreneur, I'm directly available to address your suggestions and support requests promptly.

💡 Use Cases

Two-Factor Authentication (2FA): Enhance security by sending one-time codes via SMS.
Marketing Campaigns: Reach out to customers with promotional messages.
Appointment Reminders: Send timely reminders to reduce no-shows.
Transactional Notifications: Keep users informed about their account activities.

🛠️ How It Works

Sign Up: Create an account at SMSimple-API and get 4 free credits.
Integrate: Use the provided API key to send SMS messages from your application.
Monitor: Use the dashboard to track your usage and manage your credits.

I'm continuously working to improve SMSimple and would love to hear your feedback. If you have any suggestions or need assistance, feel free to reach out.

Looking forward to your thoughts!