DEV Community: Martin Schenk

I auto-published 2,300 AI articles. Google buried 90% of my traffic.

Martin Schenk — Thu, 16 Jul 2026 15:01:07 +0000

This is the first post on this blog, and it exists because of a failure. So let me start there instead of with a mission statement.

For sixteen months I ran a content machine on a side project called Startups Españolas. It published on its own, twice a day, no human in the loop. By the time I looked hard at the numbers it had put out around 2,300 articles. I was quietly proud of the pipeline. It was a real piece of software: a Laravel backend, prompts stored in the database, several LLM providers wired in with fallback, automatic publishing straight to the live site. It felt like leverage.

Then I pulled the Search Console data for the full run and sat with it for a while.

The numbers

Here is the monthly click trend, straight from the GSC API, nothing rounded in my favor:

Month	Clicks	Impressions	Avg. position
2025-07	638	76,194	33.2
2025-09	695	56,458	19.8
2025-10	634	33,378	13.5
2025-12	428	31,475	16.8
2026-02	166	15,838	23.2
2026-04	115	14,969	22.1
2026-06	69	9,236	32.1

Peak was September 2025 at 695 clicks in a month. The last full month, June 2026, did 69. That is a 90% drop. Average position over the same stretch went from roughly 13 back down to around 32, which in plain terms means Google moved my pages from the bottom of page one to the bottom of page three.

The part that actually stung was the long tail. Over a 90 day window, 1,567 of the pages picked up impressions, so Google had indexed most of the machine's output. But only 147 pages, about 6%, got a single click. I had built two thousand articles to feed a hundred and fifty that did anything, and even those were fading.

What I told myself vs. what was true

The story I had been telling myself was "more articles, more surface area, more chances to rank." That is intuitive and it is wrong. More thin pages did not add up to more traffic. They competed with each other for the same weak queries, diluted whatever topical signal the domain had, and gave Google a large pile of near-duplicate, machine-written content to judge the whole site by. That is exactly the kind of thing the helpful-content updates are built to push down.

The traffic that did exist was not coming from the volume at all. It came from a small handful of genuinely useful startup profiles that happened to rank. The machine was not the asset. Those few real pages were. I had spent the effort on the wrong half.

The part where it got embarrassing

If the slow decline was the lesson, the fast one was the wake-up call. The brand was Spanish, es-ES only, on purpose. One day a channel without a language guard generated a batch of posts in English and pushed them live, automatically, onto a Spanish-only site. No human saw them before they were public.

Nothing catastrophic happened. But that is the whole point of automation without a human gate: the day something does go wrong, it is already live before you know it exists. A pipeline that can publish a good post on its own can publish a bad one on its own, and it will, eventually, at the worst possible moment.

What I actually took away

I am not anti-automation. I let AI write most of my code and I am not going to pretend otherwise on a blog about building with it. The lesson is narrower and more useful than "AI content bad":

Volume is not a strategy. A new site does not earn authority by producing more. Google rewards depth and trust, not word count. One real article beats five thin ones, and it is not close.
Thin content is not neutral, it is a tax. Those pages did not just fail to rank. They dragged on everything else on the domain.
Nothing publishes without a human reading it. Ever. This is the hard rule now. The English leak is the proof of why. Auto-publish is the single root cause under both failures.
Measure from day one. I ran that machine for sixteen months before I really read the data. If I had looked in month three, I would have killed it in month four.
The value is in the content, not the pipeline. I built an impressive machine and the reach came from a few good pages. For this blog I deleted the machine idea entirely.

So what is this blog

This is the opposite bet. It is static, hand-written, and English. There is a small script that gathers what I actually did across my projects each week, git history and working notes, and hands me the raw material. Then I choose one thing worth writing about and write it myself. I read every post before it goes live. There is no CMS, no queue, no provider zoo. When you are reading this, a human decided it was worth your time first.

I build around a dozen real projects mostly solo, with AI doing a lot of the heavy lifting, and I am going to write honestly about how that actually goes. Some of it works. Some of it is this post. Both are worth showing.

If that sounds useful, the RSS feed is in the footer. No newsletter popup, no cookie wall. Just the work.

My weekend project for Christmas time: https://youtube.com/shorts/DKbQkU-Jq4o?si=rVPOI2ykWYDPROk2

Martin Schenk — Fri, 26 Dec 2025 12:22:43 +0000

youtube.com

How I Built a Production-Ready SaaS in a Weekend (and Open-Sourced It)

Martin Schenk — Tue, 02 Dec 2025 19:07:57 +0000

Every time I started a new SaaS project, I found myself rebuilding the same infrastructure:

Payment integration
Invoice generation
Multi-language support
Analytics
Admin dashboard

After the third time, I decided to extract this foundation into a reusable starter. Today, I'm open-sourcing it.

GitHub: martinschenk/saas-starter-stack
Live Demo: allgood.click

## What's Included

### 1. Stripe Payments

Complete Stripe Checkout integration with:

One-time payments and subscriptions
Mobile-optimized checkout (auto-detects device)
EU tax handling
Webhook processing with signature verification

### 2. Automatic Invoicing

Zoho Invoice API integration that:

Creates professional PDF invoices on payment
Sends them automatically to customers
Supports B2B with company name and VAT ID

### 3. Multi-Language Support (5 Languages)

English, German, Spanish, French, Portuguese
SEO-friendly URLs (/de/, /es/, /fr/, /pt/)
Browser language auto-detection

### 4. GDPR-Compliant Analytics (No Cookies!)

No cookie consent banners needed
IP anonymization (last octet removed)
Admin dashboard with charts
Auto-deletes after 90 days

## Tech Stack

Express.js - Simple, no magic
SQLite - Zero config, file-based backup
Vanilla JS - No build step, ~50KB frontend

## Getting Started

git clone https://github.com/martinschenk/saas-starter-stack.git
cd saas-starter-stack
npm install
cp .env.example .env
npm start

Visit http://localhost:3000 and you have a working SaaS.

## Links

GitHub: martinschenk/saas-starter-stack
Live Demo: allgood.click
License: MIT

If this helps you ship faster, that's a win. Star the repo if you find it useful!

Have questions? Drop them in the comments!

When Absurdity Meets Clean Code: allgood.click

Martin Schenk — Fri, 14 Nov 2025 09:59:58 +0000

Sometimes the best projects are the ones that solve absolutely nothing. I just built allgood.click – a web app that promises to make everything okay. With one click. Spoiler: it does nothing. But that’s exactly the point.

The Idea

The concept is simple: A button. “Make everything OK”. Click it, and… well, everything’s okay. Or not. Whatever, you clicked and felt better for a second. Digital placebo effect as a service.

Inspired by similar absurdist websites, I wanted to build something that comments on this culture of digital “solutions”. Every problem gets an app, every worry gets a button. But instead of giving it an ironic DIY look, my approach was: make it professional. The joke is in the serious execution of something completely pointless.

Tech Stack: Practical over fancy

Node.js + Express for the backend. Why? Because I needed Stripe integration and didn’t feel like dealing with framework overhead. Laravel would’ve worked too, but for a project like this? Overkill.

// Spoiler: The "make everything okay" algorithm
app.post('/api/make-ok', async (req, res) => {
  // Highly complex logic here
  res.json({ status: 'ok', message: 'Everything is OK now' });
});

The frontend is deliberately minimal. Full-height main screen, scrollable footer for the legal stuff. Responsive, because even absurd projects should work on mobile.

Monetization: Yes, seriously

Here’s where it gets interesting: First click is free. After that, €1 per click or monthly subscription via Stripe. Sounds stupid? That’s the whole point.

The Stripe integration was the technically educational part. Implemented both payment models:

One-time payments for the impulse clickers
Subscriptions for those who need everything okay regularly

// Simplified
const session = await stripe.checkout.sessions.create({
  payment_method_types: ['card'],
  line_items: [{
    price_data: {
      currency: 'eur',
      product_data: { name: 'Make Everything OK' },
      unit_amount: 100, // €1 in cents
    },
    quantity: 1,
  }],
  mode: 'payment',
  success_url: `${YOUR_DOMAIN}/success`,
  cancel_url: `${YOUR_DOMAIN}/cancel`,
});

What I learned

1. Understatement works
“Make everything OK” instead of “REVOLUTIONIZE YOUR LIFE”. The deliberate understatement makes it funnier than any grand gesture.

2. Professionalism amplifies absurdity
When something pointless is perfectly executed, it becomes more entertaining. Proper deployment pipeline, SSL via Cloudflare, clean error handling – all there.

3. Less text is more
Originally wanted to include philosophical texts. Scrapped it. “Still not okay? Click again.” is enough.

4. i18n pays off even for jokes
Detect browser language, auto-switch to German/English/Spanish/French. Placebo effect is international.

Infrastructure

Server: Own Plesk setup
Domain: DonDominio
DNS + SSL: Cloudflare
Git: Private repo (because .env files and stuff)
Deployment: Straight to server, no CI/CD circus needed

Legal Stuff (the unfunny part)

Payment processing means: Imprint, Privacy Policy, Terms. Recycled content from my main site martin-schenk.es and adapted it. Stripe needs everything proper, even for joke projects.

Bottom line

Budget: One workday. Learning effect: Practical Stripe integration without tutorial nonsense. Fun factor: High, especially because it’s technically clean.

Will anyone get rich with this? No. Is it a useful project? Absolutely not. But sometimes that’s exactly the point. Writing code that solves nothing but is well-made – there’s something to that.

Try it out: allgood.click

First click is on the house. 😉

PS: The project is live. Payments work. Will anyone use it? We’ll see. It’s just an experiment anyway.

What do you think about such absurdist tech projects? Have you ever built something just because you wanted to build it?

Building an AI Chat Terminal That Routes Private Data to Local AI

Martin Schenk — Thu, 16 Oct 2025 18:56:08 +0000

I was tired of accidentally pasting API keys into ChatGPT, so I built a terminal that intelligently routes conversations.

The Problem

Every time you chat with ChatGPT, Claude, or any cloud AI:

Everything goes to their servers - passwords, API keys, emails, everything
It's all logged - no way to delete it
You can't verify what they do with your data

I kept cringing every time I accidentally pasted something sensitive.

The Solution

AI Chat Terminal - keyword detection that runs BEFORE anything touches the network:

You: "save my password SecretPass123"
→ Routes to LOCAL Qwen AI ✅
→ Encrypted SQLite (AES-256) ✅
→ NEVER sent to cloud ✅

You: "What's the capital of Spain?"
→ Routes to OpenAI ✅

You: "best food there?"
→ OpenAI understands context (Spain) ✅

How It Works

1. Keyword Detection (<1ms)

Pattern matching for save, show, delete and 30+ synonyms:

if matches_keywords(input, ['save', 'note', 'record']):
    route_to_local()
else:
    route_to_cloud()

Works in English, German, Spanish:

"save my email" → Local
"guarda mi contraseña" → Local
"speichere meine Telefonnummer" → Local

2. Local AI Processing

Uses Qwen 2.5 Coder (7B) via Ollama:

User: "save my email test@example.com"
→ Qwen generates SQL:
  INSERT INTO mydata (content, meta)
  VALUES ('test@example.com', 'email')
→ Encrypted with SQLCipher (AES-256)

3. Cloud for Everything Else

OpenAI GPT-4o with full context:

You: "capital of France?"
AI: "Paris"

You: "best food there?"
AI: "Croissants..." (knows "there" = Paris)

Tech Stack

Python 3.9+
Ollama - Local AI runtime
Qwen 2.5 Coder (7B) - SQL generation
SQLCipher - AES-256 encryption
OpenAI API - Cloud queries
~5GB disk space for model

Installation (macOS)

One-line install:

curl -fsSL https://raw.githubusercontent.com/martinschenk/ai-chat-terminal/main/install.sh | zsh

This automatically:

Installs Ollama if needed
Pulls Qwen 2.5 Coder model
Sets up encrypted database
Adds shell integration

Takes ~5 minutes (mostly downloading the 4.5GB model).

Usage Examples

Save Private Data

$ chat
👤 You ▶ save my email test@example.com
🤖 AI    🗄️ Stored 🔒

👤 You ▶ save password SecretPass123
🤖 AI    🗄️ Stored 🔒

👤 You ▶ guarda mi dirección Calle Mayor 1
🤖 AI    🗄️ Guardado 🔒

Retrieve Anywhere

👤 You ▶ show my email
🤖 AI    🗄️🔍 test@example.com

👤 You ▶ list all
🤖 AI    🗄️🔍 Found 3 items:
           1. test@example.com (email)
           2. SecretPass123 (password)
           3. Calle Mayor 1 (dirección)

General Questions (Cloud)

👤 You ▶ capital of Spain?
🤖 AI    Madrid.

👤 You ▶ best food?
🤖 AI    Tapas. (remembers Spain!)

Privacy Architecture

┌─────────────────────────────────────────────┐
│ User Input                                  │
└────────────┬────────────────────────────────┘
             ↓
   ┌─────────────────────┐
   │ Keyword Detection   │  ← Fast (<1ms)
   │ save/show/delete    │
   └─────────┬───────────┘
             ↓
      ┌──────────────┐
      │  Detected?   │
      └──┬────────┬──┘
         │        │
    YES  │        │  NO
         ↓        ↓
  ┌──────────────┐  ┌──────────────┐
  │ Qwen 2.5     │  │   OpenAI     │
  │ Coder (7B)   │  │  GPT-4o      │
  │ SQL Direct   │  │  (Cloud)     │
  └─────┬────────┘  └──────┬───────┘
        ↓                   ↓
  ┌─────────────┐  ┌──────────────┐
  │ Encrypted   │  │  Response    │
  │ SQLite DB   │  │ with Context │
  │ (AES-256)   │  │              │
  └─────────────┘  └──────────────┘

Key Features

🔒 Privacy First

Keyword detection before any network call
Local Qwen AI for sensitive data
AES-256 encrypted SQLite
Zero cloud exposure for private data

🧠 Smart Context

OpenAI maintains conversation history
Understands references ("there", "it", "that")
Natural follow-up questions

🌍 Multilingual

English, German, Spanish
30+ action verbs per language
Flexible phrasing

⚡ Fast

Keyword matching: <1ms
Local operations: <1s
OpenAI queries: 5-7s
Always shows 🗄️ icon for local DB operations

System Requirements

macOS 12.0+ (Monterey or later)
Zsh shell
Python 3.9+
~5GB disk space (for Qwen model)
8GB RAM minimum (16GB recommended)
OpenAI API key

Why Qwen 2.5 Coder?

I tested several local models and Qwen 2.5 Coder was surprisingly good at:

Generating SQL from natural language
Understanding multilingual input
Pattern recognition for data extraction
Running efficiently on 7B parameters

Future Improvements

Looking for contributors! Especially for:

More languages (French, Italian, Portuguese)
Windows/Linux ports (currently macOS only)
Better error handling
Testing on different macOS versions

Open Source

GitHub: https://github.com/martinschenk/ai-chat-terminal
License: MIT
Contributions: Welcome!

Conclusion

This scratches an itch I had - wanting the power of GPT-4 without accidentally logging sensitive data. The keyword-based routing is simple but effective.

Would love feedback on the privacy model - I'm sure there are edge cases I haven't considered!

✅ Laravel Cookie Consent – Plug & play GDPR/DSGVO modal

Martin Schenk — Fri, 30 May 2025 07:38:32 +0000

Hey folks! 👋
I just released a lightweight, developer-friendly cookie consent plugin for Laravel 11+ projects. It’s focused on real GDPR/DSGVO compliance – with a configurable modal, full Alpine.js support, language preferences, and real-time cookie blocking.

🔹 Easy to install
🔹 No frontend lock-in (customizable view & JS logic)
🔹 Works with Tailwind or plain CSS
🔹 Built for modern Laravel stacks

Check it out here:
👉 https://github.com/martinschenk/laravel-cookie-consent

Feedback, stars ⭐️ and contributions are very welcome! 🙏

Laravel 11/12 Cookie consent Plugin GDPR compliant 🇪🇺

Martin Schenk — Fri, 30 May 2025 07:27:46 +0000

✅ Laravel Cookie Consent – Plug & play GDPR/DSGVO modal

Body:
Hey folks! 👋
I just released a lightweight, developer-friendly cookie consent plugin for Laravel 11+ projects. It’s focused on real GDPR/DSGVO compliance – with a configurable modal, full Alpine.js support, language preferences, and real-time cookie blocking.

🔹 Easy to install
🔹 No frontend lock-in (customizable view & JS logic)
🔹 Works with Tailwind or plain CSS
🔹 Built for modern Laravel stacks

Check it out here:
👉 https://github.com/martinschenk/laravel-cookie-consent

Feedback, stars ⭐️ and contributions are very welcome! 🙏