DEV Community: slawekluzny

The Night I Built Sentinel: A Story of Bots, Breakdowns, and Breaking Through

slawekluzny — Sat, 13 Jun 2026 20:54:40 +0000

The Night I Built Sentinel: A Story of Bots, Breakdowns, and Breaking Through

It was 3am when I woke up to the alert. My server was under attack.

I opened my laptop, stared at the screen, and felt that familiar sinking feeling in my gut. SSH was timing out. The CPU usage graph looked like a heart attack—flatlining at 100%. Something was wrong.

This wasn’t the first time my server had been hit by bots. But this wasn’t a casual scan or a low-level probing. This was a full-on assault.

By the time I got into the hosting panel, the damage was already done. My contact form had been hammered. Emails had been sent out in a matter of hours. My IPs were blacklisted. My server was toast.

I spent the next week in a fog of exhaustion—days on the construction site, nights trying to salvage what was left. Rate limiting, CAPTCHA, SPF records, DKIM—all the things I should have done before the attack, not after.

But in that mess, something clicked. I started making a list of everything that had gone wrong—everything that could go wrong. And I realised: I didn’t just need to fix this. I needed to prevent it.

The Birth of Sentinel

Sentinel didn’t start as a product. It started as a script. A crude, ugly thing that ran core monitoring roughly every 5 minutes via a long-running systemd daemon with APScheduler interval jobs—cron was intentionally avoided to keep the crontab clean and uncluttered—and checked a list of things:

Is the database running?
Are the SSL certificates valid?
Is the CPU spiking?
Are the bots hammering the contact form again?

It wasn’t impressive. But it worked.

Over time, it grew. A dashboard here, a fleet view there. Integration with Fail2Ban. AI-powered checks for anomalies.

Today, Sentinel is one of our core offerings. It’s running on our servers, and it’s running on other people’s servers too. What started as a desperate fix became a product.

Why I Ditched Laravel

I didn’t hate Laravel. But I didn’t understand it either.

The codebase I inherited was a patchwork quilt of freelancer decisions—shortcuts, half-working features, and choices that made sense to someone, somewhere, at some point. But not to me.

So I rewrote it.

From scratch. A modern stack for a platform that needed to be fast, clean, and scalable.

It wasn’t easy. It took months. But when it was done, I understood every line of code. Every decision. Every fix.

The AI Shift

I wasn’t always good at this.

Years ago, I couldn’t tell you what SSH stood for. Today, I’m building SaaS products that people pay for.

The difference? AI.

Not as a crutch, but as a collaborator.

With tools like Claude, I could think out loud. I could describe a problem—badly, imprecisely—and have the imprecision noticed and questioned. I could ask why, not just how.

I learned to verify before implementing. To trust my instincts when something felt off. To push back when the AI suggested something technically correct but fundamentally wrong.

That back-and-forth—human judgment combined with AI capability—was what made the difference.

The Products That Came From Chaos

I didn’t set out to build a company.

Sentinel started as a fix for my own server. 24ad.info started as an idea on a construction site. PostPilot—they all started as tools I needed to solve problems I faced.

Today, they’re products. Real ones. With pricing, documentation, and customers.

The Lessons I’ve Learned

Tools matter less than you think. Find what fits how you work. I tested several different servers, each handling what it did best, but ran into conflicts. Caddy was chosen only after testing as the best overall fit. I stuck with it because it worked.
Breaking things is the education. The things I remember most clearly are the things that went wrong.
AI is a collaborator, not a replacement. The code is better when I understand it. The solutions are better when I push back.
Shipping beats perfecting. Every product I have is imperfect. Every product I have is live.
The story is the product. Authenticity is the differentiator.

The Invitation

If you’re reading this and you have an idea you haven’t started because you don’t have the technical background—start.

Not with a plan to learn everything first. Not with a commitment to do it properly before doing it at all. Just start.

The knowledge follows the doing.

I didn’t learn to manage a server and then build products. I built products and learned to manage a server because I had to.

The credential doesn’t come before the work. It comes from it.

"I don’t know programming languages at an expert level. I don’t need to.

I imagine, describe, verify—AI codes. I decide."

— Slawomir Luzny

Founder, FixFlex LTD • West London

The AI-Powered Classifieds Stack That Posts in Seconds

slawekluzny — Tue, 02 Jun 2026 23:21:28 +0000

The AI-Powered Classifieds Stack That Posts in Seconds

Users can upload a photo to 24ad.info. AI assists with the listing details.

The ad goes live before any manual steps are complete. Here's how the stack works.

The Pipeline

1. Vision Processing (OpenRouter + Gemini 2.5 Flash)

When you upload photos:

// Simplified image analysis flow
const analysis = await openRouter.chat.completions.create({
  model: "google/gemini-2.5-flash",
  messages: [{
    role: "user",
    content: [
      { type: "image_url", url: uploadedImage },
      "Describe this item for a classified ad. Identify make/model, condition, and realistic price."
    ]
  }]
});

Key observations:

Processes images quickly
Handles mixed content
Price suggestions draw on available data

2. Category Assignment

The system first tries keyword matching. If uncertain, it queries the classification options.

Two clever bits:

Dormant category reactivation - Instead of creating duplicate categories, it finds and revives inactive ones
Custom field generation - For categories like Cars, AI suggests relevant fields

3. Multilingual Output

Using the same call flow, translations are generated.

The response lands in our locales/ directory with i18n keys.

The Stack That Makes It Possible

Frontend

React 19 + Vite 7 - For the instant form updates
shadcn/ui - Pre-built components with Tailwind
wouter v3 - Lightweight routing (no React Router bloat)

Critical UX details:

File upload starts analysis during selection
Price/category suggestions appear as editable previews
Location auto-fills from browser geolocation or IP

Backend

tRPC v11 - Keeps frontend/backend types in sync
Drizzle ORM - For type-safe MySQL queries
Express 4 - Handles the traffic types:
1. User requests (API/SSR)
2. Googlebot HTML injection
3. Health checks (/api/system-health)

Infrastructure

Caddy v2 - Wildcard subdomains with HSTS
PM2 cluster mode with 4 instances - load-balanced
MariaDB - Heavily indexed for search (title, location, price)

CREATE TABLE `posts` (
  `id` bigint AUTO_INCREMENT PRIMARY KEY,
  `title` varchar(191),
  `price` decimal(17,2),
  `country_code` varchar(2),
  `latitude` float,
  `longitude` float
  -- geolocation uses standard B-tree index on latitude/longitude
);

Pain Points We Solved

1. AI Latency

Initial versions waited for all AI steps sequentially. Now:

Parallel processing - Fire all AI requests simultaneously
Fallback caching - Common items use template descriptions if needed

2. Location Handling

Early users saw unexpected placement. Fixed by:

Subdomain locking - Forces location based on subdomain
Clear labels - Shows target country

3. Spam Protection

Current defenses include:

AI content check - Flags suspicious patterns
IP/email blacklist - Shared across country subdomains
Stripe verification - Premium ads require validated payment

The Admin Toolkit

Moderators get bulk tools plus:

AI banner rotator - Generates event-specific graphics
Health monitor - Checks subsystems including font rendering and upload permissions

Performance

Median ad creation time is low. Category handling is accurate.

Lessons Learned

AI isn't magic - Pricing suggestions benefit from additional rules.
Condition detection - The AI spots visible details in photos.
Speed matters - The entire process must fit within user attention.

Try it yourself: 24ad.info.

Project Brain: Giving Claude Code a Memory That Actually Works

slawekluzny — Mon, 01 Jun 2026 18:02:01 +0000

Project Brain: Giving Claude Code a Memory That Actually Works

Every developer using Claude Code hits the same wall eventually:

You explain your project's architecture
You explain the deployment setup
You walk through the stack choices
You recap what's already been built
You list the known pitfalls

...and then tomorrow, you do it all again. Worse, after a few hours of work across multiple projects, Claude starts blending details between them.

The core issue isn't capability - it's memory. Without persistent context, every session starts from zero. The current "solutions" are either:

The README Dump: Pasting your entire documentation into each session (expensive in tokens, tedious to maintain)
The Flat Notes File: A giant markdown doc that grows until even you can't navigate it
The Memory Game: Hoping Claude will somehow remember (it won't)

How Project Brain Actually Works

Project Brain is a Claude Code skill that implements a simple but effective pattern:

.project-brain/
  index.md                          # Lightweight map of projects → topics
  projects/
    acme-api/                       # one folder per project
      auth.md                       # one file per topic — loaded only when needed
      deployment.md

The key innovations aren't technical - they're structural:

Index-first navigation: Claude reads the small index (cheap) before diving into details (expensive only when needed)
Status tracking: ✓ verified vs ✗ failed vs ⚠ in-progress means Claude knows what actually worked
Versioned knowledge: Superseded approaches are preserved, not overwritten

What It Actually Fixes

Let's be brutally honest about the wins:

Fewer hallucinations: The map is an anchor. The model stops inventing your deployment or swapping one project's stack for another's.
Context anchoring: Switching between projects no longer risks blending their architectures
Long-term memory: Returning to a project after months doesn't require re-teaching everything

The token savings depend on your current workflow. If you're currently pasting a 1000-line README into every session, the win is substantial. If you already use focused context, the gain is smaller but real - mostly from avoiding redundant re-explanation.

Implementation That Doesn't Get in the Way

The installation is straightforward:

git clone https://github.com/OoneBreath/claude-code-project-brain.git
cd claude-code-project-brain
./install.sh

Start a new Claude Code session after installing (skills load at session start). Then, inside your workspace, invoke the skill and tell it what to do:

/project-brain   →   "init"   sets up the brain and detects your projects

The system is deliberately lightweight:

Detects projects from package.json / pyproject.toml / git
Doesn't pre-scan your codebase (unless you explicitly backfill)
Creates plain markdown files you can edit directly

The Tradeoffs

This isn't magic - it's a disciplined approach to knowledge management:

Gradual buildup: The brain fills as you work, not in one massive dump
Truth in documentation: Only knows what you've explicitly recorded or backfilled
Light upkeep: A bundled brain-check validator is there when you want it - run it after big changes to catch broken links or status drift. It's optional, not a chore.

Why This Works When Other Approaches Fail

Most "AI memory" solutions make one of two mistakes:

The Database Fallacy: Assuming dumping everything into a vector store solves the problem (it doesn't - retrieval is still expensive and noisy)
The Flat File Trap: Creating an ever-growing notes.md that becomes impossible to navigate

Project Brain works because it mirrors how human engineers actually think about systems:

Start with the high-level map
Drill down only when needed
Preserve decision history, not just current state

Getting Started Without Overcommitting

The pragmatic approach:

Install the skill
Run init on one active project
Work normally - let the brain build organically
Only backfill when you hit a clear need

After a week, you'll notice the difference in:

Session setup time
Cross-project clarity
Reduced "wait, we already tried that" moments

The system's real power emerges over time - as the brain accumulates not just what you built, but why you built it that way. That's the kind of institutional memory that normally only exists in long-tenured teams. Now your AI assistant has it too.

The Unlikely Journey from Bricks to Bytes

slawekluzny — Sat, 30 May 2026 15:35:42 +0000

I'm a builder. I taught myself to run servers because freelancers kept burning my money.

West London, 2021. I was standing on a site holding a cup of tea that had gone cold an hour earlier, watching a crew argue about where a wall should go. That's my actual job. Schedules, suppliers, the kind of problems that only exist at 7am when half the crew hasn't shown up and the client is already phoning.

But my head was somewhere else. I'd been chewing on an idea for a classifieds platform for months. Not a grand vision, nothing with a business plan and projections. Just a gap I could see — a way to connect buyers and sellers that felt easier and more global than what was out there.

The problem was that I knew nothing about programming. And I mean nothing. I didn't know what a database was. I'd never written a line of code. My entire technical CV was "reasonably good at not breaking my own phone."

So I did what most people in my position do. I tried to buy my way in.

The expensive year

I found a ready-made classifieds script online. Looked professional, had features, didn't cost the earth. The smart shortcut, I told myself. Then I hired a freelancer to customise it. Then another one, when the first disappeared mid-project. Then another, when the second delivered something that worked on a good day and fell over on a bad one.

Here's the thing nobody warns you about hiring freelancers when you can't read code: you can't judge the work. You can't tell the difference between someone who wrote something clean and someone who duct-taped it together to last until the invoice clears. Both show you the same thing — a screen where the button does what the button's meant to do. So you pay, you say thanks, you move on. And three months later the button stops working and the freelancer's gone.

Meanwhile the bots had found me. Within weeks of going live, automated scripts were hammering the contact form, then the registration page, then the login. "It's normal," a freelancer told me. "Happens to everyone." What he didn't mention is that "happens to everyone" and "your server is set up to handle it" are very different sentences. Mine wasn't.

After about a year I did the maths on what I'd spent. The number made me feel a bit sick. And the product still wasn't right.

There was a specific evening — kitchen, about 11pm, laptop open, staring at another error I couldn't read — when I decided: either I figure this out myself, or it never launches. Not "I'll find better freelancers." Not "I'll get a technical co-founder." Just: I'm going to understand what's happening on my own server.

I had no idea what that actually involved.

Learning by breaking things

The first thing Linux teaches you is that it'll tell you exactly what's wrong. The second thing it teaches you is that understanding what it just told you takes a lot longer.

My first real SSH session was about fifteen minutes of typing things wrong, being told I didn't have permission to do them, and then being told I didn't have permission to give myself permission. I didn't quit — not because I'm brave, but because I was annoyed. It was my server. I was paying for it.

There's no syllabus when you learn this way. You learn whatever the problem in front of you needs. I learned SSH because I needed to get in. Linux commands because I needed to read logs. Fail2Ban because someone mentioned it in a forum thread about bots. I learned about web servers by breaking them — Nginx, then Apache, then LiteSpeed, then Varnish, then H2O for a bit. Eventually I found Caddy, which is what you get when someone builds a web server for people who aren't web server experts. Its config reads almost like plain English. I'm still on it today.

I should admit something. For the first two years I didn't use Git. Everyone uses Git. I took snapshots instead — a full snapshot through the hosting panel before touching anything I wasn't sure about. Slow, inelegant, not how professionals do it. But when things went badly wrong, and they did with some regularity, I could roll back. It's how I survived long enough to eventually learn the proper way.

My process, which I wouldn't have called a process at the time: describe the problem in plain language, as precisely as I can, into an AI chat window. Read what comes back. Try to understand what it's meant to do before I run it. Then run it on the live server, with a snapshot as the safety net. Every developer reading this is wincing. But every mistake had real consequences, and there's no better teacher than a mistake that actually costs you something.

The night that built Sentinel

The alert came in just after 3am. Server unresponsive. SSH timing out. CPU pinned at a level I'd never seen — not a spike, a sustained load that had been building for hours while I slept.

It was the Laravel app, being hit by a coordinated bot campaign that had found the contact form. No rate limiting. No CAPTCHA. To a script, an open door. Nearly a million emails went out before I shut it down. The server got blacklisted — not by one service, by several. I spent the next week in a state of focused misery: site by day, then evenings contacting blacklist operators, waiting on reviews, and putting in the things that should have been there from the start. Rate limiting on every form. CAPTCHA where it mattered. SPF, DKIM, DMARC done properly. Monitoring on outbound email.

While I was fixing all that, I started a list of everything that could go wrong on a server like mine and what would have to be true to catch it. Nothing I could find did all of it. So I started building it myself.

The first version was not impressive — a Python script on a cron job, checking a list of things every few minutes. But it ran, and it found stuff. A service that had quietly crashed seven times in an hour. A query taking twelve seconds. Disk usage creeping toward full. Small things. The kind that become big things if nobody's watching. I was watching.

That tool eventually became Sentinel. As I write this, its blocked-attacks counter — every banned IP, every blocked request, every Fail2Ban trigger since it started running — reads 283,103.

What changed

For a long time I was still slow. Every feature took too long. The gap between having an idea and making it real was still too wide. Then the way I worked with AI changed — less "give me the answer," more "here's what exists, here's what I need to exist, here's how I'll know it works." I could think out loud and have the vague bits noticed and questioned. For someone still building the mental models that experienced developers have on autopilot, that was the unlock.

I also made a decision that felt dramatic and now feels obvious: I threw away the Laravel codebase I'd inherited from freelancers and didn't fully understand. Over a few months I moved everything to React, TypeScript, tRPC and Node. It was faster and cleaner, and I understood every part of it — because I'd either built it or understood what the AI built and why. At one point I rebuilt one of my smaller sites in about six hours. Eighteen months earlier that would have been unthinkable.

Where I am now

The alarm still goes off at 5:45am. Site by seven. By the time most tech founders are reaching for their first coffee, I've been working for hours. The construction company runs well and I find it grounding — at the end of a day there's something real in the world that wasn't there in the morning.

The software side now has a handful of live products, and every one of them started as a tool I needed rather than a product I planned: Sentinel for watching servers, the classifieds platform that was the original idea finally built properly, a spam filter that came straight out of that contact-form disaster, and a couple of tools for content. Sentinel has a free tier for a single server and paid plans beyond that — the details are on sentinel-ai.info if you run servers and the 3am story made you wince in recognition.

If you've got an idea you haven't started because you don't have the technical background — start anyway. Not with a plan to learn everything first. Just start, with whatever you've got. I didn't learn to run a server and then build things. I built things and learned to run a server because I had to. The knowledge follows the doing, not the other way round.

I still keep steel-toe boots by the door.

The Construction Worker’s Guide to Building SaaS Without a CS Degree

slawekluzny — Mon, 25 May 2026 23:29:08 +0000

The Construction Worker’s Guide to Building SaaS Without a CS Degree

This morning, I checked Sentinel’s dashboard—283,103 blocked attacks. Four years ago, I couldn’t even spell "SSH."

I’m Slawomir Luzny, founder of FixFlex LTD in West London. I still wake up at 5:45am for construction work. I still code at night. And I just published a free ebook about how I built 5 live SaaS products without a computer science degree.

Why This Exists

In 2021, I was a construction worker with an idea for a classifieds platform. Zero coding experience. I did what everyone does:

Bought a ready-made script
Hired freelancers (who delivered half-working solutions)
Watched bots attack my server while Cloudflare shrugged
Spent a year and a small fortune fighting fires

Then I made a decision: Either I learn this myself, or the project dies.

What’s Inside the Ebook

6 chapters of hard-won lessons:

The Idea
- Cold tea on a construction site. Buying scripts. Freelancer roulette.
- Key fact: First version of 24ad.info launched with a Laravel codebase I didn’t understand.
The Expensive Lesson
- Freelancers who vanished. Databases with no indexes.
- Key fact: Server blacklisted after bots sent nearly a million spam emails through an unprotected contact form.
Learning by Fire
- SSH sessions ending in permission errors. Testing Nginx, Apache, LiteSpeed—finally landing on Caddy.
- Key fact: Used server snapshots instead of Git for two years.
The Attack
- 3am alert. CPU at 100%. The birth of Sentinel from that chaos.
- Key fact: First version was a Python cron job checking disk usage and services.
The Pivot
- Discovering Claude. Rewriting everything in React 19 + tRPC.
- Key fact: Rewrote breathtime.info in 6 hours—something impossible a year prior.
Where I Am Now
- 5 live products. Still coding after construction shifts.
- 283,103 attacks blocked by Sentinel — all-time
- Free ebook available: fixflex.co.uk/ebook.html
- "I don't know programming languages at expert level. I don't need to. I imagine, describe, verify — AI codes. I decide." ---

The Tools That Actually Worked

AI: Claude for reasoning, GPT for code snippets
Stack: React 19, TypeScript, tRPC, Node.js (after abandoning Laravel)
Infrastructure: Caddy server, OVH, droplets, Fail2Ban
Security: Sentinel (born from my own bot attacks)

Who This Is For

Non-technical founders tired of outsourcing to agencies
Bootstrappers who need to move fast without a dev team
Anyone who thinks you need a CS degree to build SaaS

How to Get It

Free download: [Gumroad link]
Email access: fixflex.co.uk/ebook.html

No fluff. No "10x productivity" nonsense. Just the exact steps that took me from construction site to 5 live products.

Final note: If you’re waiting until you "know enough" to start—stop. The knowledge follows the doing.

"I don’t know programming languages at an expert level. I don’t need to. I imagine, describe, verify—AI codes. I decide."

— Slawomir Luzny

Founder, FixFlex LTD • West London

277,000 Attacks Blocked — Here's What the Data Shows

slawekluzny — Fri, 15 May 2026 00:00:00 +0000

We pulled a year of Sentinel Audit logs. Here's what 277,463 blocked attacks reveal about the threat landscape for self-hosted VPS operators.

From Construction Site to SaaS: How I Built Sentinel Without Knowing How to Code

slawekluzny — Fri, 08 May 2026 00:00:00 +0000

How a construction worker built a real SaaS product using AI — from zero programming knowledge to Sentinel, a production server autopilot used daily.

Why Fail2Ban + CrowdSec Alone Isn't Enough (And What to Add)

slawekluzny — Fri, 01 May 2026 00:00:00 +0000

Fail2Ban and CrowdSec leave three gaps: no DB-layer awareness, slow fleet propagation, and no AI anomaly detection. Here is what to add.