DEV Community: Akın Coşkun

I Built a RAG Chatbot Platform With Java Spring Boot and Next.js

Akın Coşkun — Fri, 25 Sep 2026 07:00:00 +0000

TL;DR

I built an AI Chatbot Platform: a SaaS where you upload PDFs, URLs, or plain text, and it turns that content into a chatbot that only answers from what you gave it. Under the hood it's a RAG (Retrieval Augmented Generation) pipeline: pgvector with an HNSW index for similarity search, and a two-provider AI setup that tries Groq's Llama 3.3 first and falls back to Google Gemini. The backend is Java Spring Boot, the frontend is Next.js, and the resulting chatbots embed into any website with one line of code.

What it actually does

A user uploads documents (PDF, URL, or raw text), the platform chunks and embeds them, and stores the vectors in Postgres via pgvector. When a visitor asks the chatbot a question, the platform retrieves the most relevant chunks by vector similarity and feeds them to an LLM as context, so the answer is grounded in the uploaded material instead of the model's general training data. The finished chatbot can be embedded into any website with a single script tag.

Why pgvector with an HNSW index

Storing embeddings in Postgres (via the pgvector extension) instead of standing up a dedicated vector database keeps the stack to one database for both relational data (users, chatbots, documents) and vector data. HNSW (Hierarchical Navigable Small World) is the index type that makes similarity search fast at scale: it builds a layered graph of embeddings so a query doesn't have to compare against every stored vector, trading a small amount of recall for a large speedup. For a platform where every chatbot response depends on a fast retrieval step, that trade-off is the right one.

Why two AI providers, not one

The platform calls Groq's Llama 3.3 first because Groq's inference is fast and cheap, which matters when every chatbot reply requires a live generation call. But relying on a single provider means a rate limit or an outage on their end becomes an outage for every chatbot built on the platform. So there's a fallback path to Google Gemini: if the primary call fails or gets rate-limited, the request retries against Gemini instead of just failing. It's a small amount of extra complexity in exchange for not going down when one vendor has a bad day.

Java Spring Boot for the API, Next.js for the frontend

Most of my other projects are Node/Next.js end to end, so splitting to a Java Spring Boot backend here was a deliberate choice, not a default. Spring Security handles JWT-based auth, and Spring Boot's ecosystem made it straightforward to wire up the document ingestion pipeline (chunking, embedding calls, pgvector writes) as a set of clearly separated services rather than a pile of API route handlers. The frontend stays in Next.js 14 with TypeScript and shadcn/ui, talking to the Spring Boot API over REST. Keeping the boundary explicit (one API, one frontend, deployed separately on Render and Vercel) made it easy to reason about what each layer is responsible for.

The stack

Java 21, Spring Boot 3.x, Spring Security (JWT), PostgreSQL with pgvector, Next.js 14, TypeScript, shadcn/ui, Groq (Llama 3.3), Google Gemini, HuggingFace, Render, Vercel, Neon.

Try it

The AI Chatbot Platform is live at chatbot-web-peach.vercel.app, frontend source on GitHub: akincskn/chatbot-web, backend API: akincskn/chatbot-api.

I'm Akin Coskun, a full-stack developer from Turkey building production SaaS tools with zero-cost infrastructure. More projects on my portfolio: akin-coskun.web.app.

Why I Chose Kafka Over a Simple Job Queue for a Solo-Built Incident Management Tool

Akın Coşkun — Tue, 22 Sep 2026 14:08:32 +0000

TL;DR: I built OpsFlow, a B2B incident management tool, and the hardest decision wasn't the UI or the on-call rotation logic — it was picking Kafka over a much simpler Redis-backed job queue for the alert pipeline. Here's why the "boring, simple" choice would have actually cost me more.

The problem

OpsFlow needs to take an incoming alert (from a monitoring tool, a webhook, or a manual page) and fan it out to multiple things at once: notify the right on-call engineer, update a status page, log a timeline event, and potentially trigger an escalation policy if nobody acks in time. Each of these is a separate concern, they fail independently, and they need to happen reliably even if one consumer is temporarily down.

My first instinct, since I was building this solo with zero infrastructure budget, was to skip Kafka entirely. A Redis list with BLPOP and a couple of worker processes would have gotten me 80% of the way there in an afternoon.

Why I didn't stop at Redis

Two things changed my mind once I actually mapped out the failure modes:

Replay matters for incidents. If the notification service crashes for three minutes, I don't want those alerts gone — I want every consumer to pick up exactly where it left off once it's back. A Redis list is destructive on pop; once a worker reads a message, it's gone if that worker dies mid-processing. Kafka's consumer groups with offset tracking meant I could restart a crashed consumer and it would resume from the last committed offset, no lost alerts.

Multiple independent consumers, one event. Notification, status page, timeline, and escalation are four different services that all need to see the same alert. With Redis I'd have needed to either duplicate the message four times at publish time (fragile — what if I add a fifth consumer later?) or build a pub/sub fan-out myself. Kafka topics with multiple consumer groups gave me that for free — each service reads the same topic independently, at its own pace.

What it actually looks like

// producer: alert-ingest service
await kafka.producer().send({
  topic: 'incidents.alerts',
  messages: [{
    key: incident.serviceId,
    value: JSON.stringify({
      incidentId: incident.id,
      severity: incident.severity,
      receivedAt: new Date().toISOString(),
    }),
  }],
});

// consumer: notification-service, its own consumer group
await kafka.consumer({ groupId: 'notification-service' }).run({
  eachMessage: async ({ message }) => {
    const alert = JSON.parse(message.value!.toString());
    await notifyOnCall(alert);
  },
});

Keying by serviceId matters more than it looks — it guarantees alerts for the same service land on the same partition, so escalation logic that needs to see events in order for one service never gets them out of sequence, even though alerts for different services process fully in parallel.

The honest trade-off

Running Kafka solo isn't free. I run it as a single-broker instance, which means I gave up the durability guarantees a real cluster gives you — if that one broker dies, I lose the ability to produce or consume until it's back. For a tool that's currently serving a handful of early customers, that's an acceptable trade for now. It's the kind of decision I'll revisit the day OpsFlow has enough traffic that "single broker" stops being funny.

If you're building something similar and trying to decide between "the simple thing" and "the correct thing," my rule of thumb ended up being: if losing a message silently is something you'd have to explain to a customer during an incident, don't use a destructive queue.

OpsFlow is free while it's early — if you're running on-call for a small team and curious, the link's in my profile.

Why I Used Kafka for a Small Incident Management Tool

Akın Coşkun — Fri, 18 Sep 2026 07:00:00 +0000

TL;DR

I built OpsFlow, an incident management SaaS for small ops teams: log incidents, assign severity, track SLA deadlines, and notify the right people in real time. Under the hood it's a microservice setup (API, frontend, and a separate notification service) that talks over Kafka. For a tool with a modest number of daily incidents, that's arguably more infrastructure than the traffic justifies, and that trade-off is worth being honest about.

What OpsFlow actually does

OpsFlow lets a team log an incident, assign a severity level, and track it against an SLA deadline. Every organization is multi-tenant isolated, every user has a role (RBAC) that controls what they can see and act on, and every state change (acknowledged, escalated, resolved) needs to reach the right people immediately, not on the next page refresh.

Why a separate notification service

The part that pushed OpsFlow toward a microservice split wasn't the incident CRUD (that's a normal REST API), it was notifications. Every incident state change can fan out to multiple channels and multiple people, and that work is bursty and shouldn't block the request that created the incident. So the API publishes an event to Kafka when something changes, and a dedicated notification service consumes those events and handles delivery. The incident API stays fast and simple; the notification service can retry, batch, or slow down without the person filing the incident ever noticing.

Was Kafka overkill?

Honestly, for OpsFlow's actual traffic, a Redis-backed job queue would have handled the load with a fraction of the operational surface. Kafka's real value here isn't throughput, it's the durable log: notification delivery failures don't lose the event, consumers can replay from an offset, and adding a second consumer later (an audit log service, for example) doesn't mean touching the producer at all. That's a real architectural benefit for a product built around "did the right person get told," even if the queue depth on any given day is small.

RBAC and SLA tracking, on the same event stream

Roles determine both visibility and action: who can see an incident, who can change its severity, who can close it. SLA tracking runs off the same event stream. An incident's assigned severity determines its deadline, and the notification service watches for approaching and breached deadlines the same way it watches for state changes, as events, not as a separate polling job.

The stack

Express.js, React, React Native, TypeScript, PostgreSQL, Kafka, Redis, MUI.

Try it

OpsFlow is live at opsflowweb.vercel.app, source on GitHub: akincskn/opsflow-api.

I'm Akin Coskun, a full-stack developer from Turkey building production SaaS tools with zero-cost infrastructure. More projects on my portfolio: akin-coskun.web.app.

Why I Chose Next.js Server Components for a Small Apartment Dues Tracker

Akın Coşkun — Fri, 11 Sep 2026 07:00:00 +0000

TL;DR

I built KolayAidat, a free apartment dues (aidat) tracker for Turkish apartment managers. Residents upload payment receipts, the manager approves or rejects them, and everyone can see the building's payment status without a spreadsheet. The whole app runs on Next.js Server Components, which turned out to be the right call for an app that is mostly "look at data, take one action" screens.

The problem with a shared spreadsheet

Most Turkish apartment buildings track monthly dues (aidat) in a shared Excel file or a WhatsApp group, updated by whoever the building manager happens to be that year. It's manual, error prone, and gives residents no way to check their own payment history without asking. KolayAidat replaces that with a small web app: residents log in, upload a receipt when they pay, and see their own payment record. The manager gets a single dashboard showing who has paid, who hasn't, and a queue of receipts waiting for approval.

Two roles, one dashboard

There are exactly two roles: resident and manager. A resident can only see and act on their own apartment's dues; a manager can see every apartment in the building and approve or reject any receipt. Rather than building two separate apps, the same dashboard route renders different data and different actions depending on the signed-in user's role, checked server-side on every request through NextAuth.js sessions, so a resident can't page-hack their way into another apartment's records by guessing a URL.

The receipt approval flow

When a resident marks a month as paid, they upload a receipt image or PDF. That payment sits in a "pending" state until the manager reviews it. The manager can approve it, which marks the month paid for that apartment, or reject it with a short note explaining why (wrong amount, blurry receipt, wrong month), which reopens the month for the resident to fix and resubmit. Nothing gets marked paid without a human on the manager side actually looking at the receipt, which matters more than automation here since these are real cash payments between neighbors.

Why Server Components, not a client-heavy SPA

KolayAidat's screens are almost entirely "load a list, show its status, take one action on a row." That's a pattern Server Components are good at: the dashboard's data-heavy list of apartments and payment statuses renders on the server with a direct database read, no client-side data-fetching waterfall, no loading spinners for what is fundamentally a boring table. The only client components are the small interactive pieces, uploading a receipt, clicking approve or reject, which keeps the JavaScript shipped to the browser small for an app whose users are, realistically, checking it once a month on a phone.

Email notifications without a queue

Residents get an email when their receipt is approved or rejected, and managers get one when a new receipt is waiting for review. At this scale (dozens of residents per building, not thousands), a full message queue would be overkill, so notifications fire directly from the relevant server action right after the database write succeeds.

The stack

Next.js 14, Prisma, PostgreSQL, Tailwind CSS, shadcn/ui, NextAuth.js.

Try it

KolayAidat is free for apartment managers. Live at kolayaidat.vercel.app, source on GitHub: akincskn/kolayaidat.

I'm Akin Coskun, a full-stack developer from Turkey building production SaaS tools with zero-cost infrastructure. More projects on my portfolio: akin-coskun.web.app.

I Built a Turkish Wordle for Football Fans: The Deterministic Puzzle Algorithm

Akın Coşkun — Fri, 04 Sep 2026 07:00:00 +0000

TL;DR

I built Santra, a Wordle-style daily puzzle game for Turkish football fans. Every day, everyone gets the same Super Lig player to guess, drawn from a static dataset of 198 players across 19 clubs. Picking "today's player" never touches a database: the puzzle is generated deterministically from the date itself, so the core game logic stays completely stateless.

A puzzle that doesn't need a database

Most daily puzzle games store "today's answer" in a database row that a cron job writes at midnight. Santra skips that step entirely. The player index for any given date comes from a seed built out of the date itself (year, month, day), run through a small deterministic hashing function, then taken modulo 198. Feed in the same date and you get the same number, every time, on every server, with no shared state. That means the puzzle can be computed on any request, cached aggressively, and it never drifts out of sync even if I redeploy at 11:59 PM.

Guessing in Turkish is harder than it looks

Turkish football surnames are full of i, s, g, o, u, c with dots, cedillas, and umlauts (Cakir, Muslera, Calhanoglu). A naive string comparison punishes a fan for a missing cedilla the same way it punishes them for guessing the wrong player entirely. Every guess and every player name in Santra gets run through a normalization pass before comparison: Turkish-specific case folding (the dotted and dotless "i" problem breaks the standard lowercase function in most languages) plus diacritic stripping, so "calhanoglu" and "Calhanoglu" match cleanly.

Two modes, one dataset

The core game runs once a day, same puzzle for everyone, which is the whole point of a shared daily ritual. But some players want to grind. A separate /antrenman (practice) route reuses the same 198-player, 19-club dataset but picks a random index on every visit instead of the date-derived one, so it stays unlimited without ever touching the daily puzzle's determinism.

Testing a puzzle you can't screenshot

Wordle-style games are deceptively easy to break: off-by-one errors in attribute matching, case-sensitivity bugs, normalization edge cases that only show up on one specific surname. Santra's guess-comparison logic is covered by Vitest unit tests that pin down exact matches, partial matches (right club, wrong player, for example), and misses, so a refactor of the normalization function can't silently break the game for someone mid-streak.

The stack

Next.js 14, TypeScript, Prisma, Tailwind CSS, Vitest for testing, deployed on Vercel.

Try it

Santra is free, no account needed. Live at santra-theta.vercel.app, source on GitHub: akincskn/Santra.

I'm Akin Coskun, a full-stack developer from Turkey building production SaaS tools with zero-cost infrastructure. More projects on my portfolio: akin-coskun.web.app.

I Built a Multi-Tenant SaaS Where Customers Never Need an Account

Akın Coşkun — Fri, 28 Aug 2026 07:00:00 +0000

TL;DR

I built Arac Saglik Karnesi (Vehicle Health Card), a free digital service-history tool for auto repair shops in Turkey. Every vehicle gets an 8-character code. Customers type that code into a page and see the full maintenance history: no signup, no app, no password. The interesting engineering problem wasn't the lookup. It was making one shared Next.js app safely serve dozens of independent auto shops without any of them ever seeing another shop's data.

Two audiences, two access models

A shop owner needs a normal authenticated dashboard: add vehicles, log service visits, upload photos, manage staff. The shop's customers need zero-friction access. They got a code printed on a receipt, they type it in, they see their car's history. No account, no login screen, no "create a password to view your own car" moment that makes people abandon the page.

Those are genuinely different security models living in the same app, and mixing them up is exactly how multi-tenant systems leak data.

Multi-tenancy without accidental leaks

Every table that holds shop-owned data carries a tenant identifier, and every query is scoped by that identifier at the query layer, not just filtered in the UI afterward. That distinction matters: a bug in a screen's rendering logic can't accidentally show one shop's customers on another shop's dashboard if the database query itself was never allowed to fetch cross-tenant rows in the first place.

Auth.js v5 handles the owner-side session and ties every authenticated request to exactly one shop. The customer-facing lookup page is intentionally unauthenticated, and instead scoped entirely by the 8-character code, which functions as a capability token: whoever holds the code can view that one vehicle's record, and nobody can browse their way into someone else's car by guessing, since the code space and rate limiting make brute force impractical.

Why a code and not a login

Requiring the customer to create an account just to see their own service history kills the point of the product. The entire value proposition is a shop being able to say "we did the work, here's the record," and any friction between the receipt and that proof cancels out the trust it was supposed to build. An 8-character alphanumeric code is short enough to print on a receipt or text to a customer, and long enough that guessing your way to a specific vehicle isn't practical.

Compressing photos before they leave the browser

Shops attach before and after photos of the work, which is a strong trust signal for customers. Uploading full-resolution phone photos straight to Vercel Blob would be slow on shop wifi and adds up in storage and egress at scale. Photos are compressed client-side, in the browser, before the upload even starts, so what actually crosses the network is already the size it needs to be.

The stack

Next.js 16, React 19, TypeScript
Prisma 6 and PostgreSQL on Neon, tenant-scoped at the query layer
Auth.js v5 for shop-owner authentication
Upstash Redis
Vercel Blob for photos, compressed client-side before upload
Tailwind CSS

Try it

Arac Saglik Karnesi is free for auto repair shops, no monthly fee. Live at arac-saglik-karnesi.vercel.app, source on GitHub: akincskn/arac-saglik-karnesi.

I'm Akın Coşkun, a full-stack developer from Turkey building production SaaS tools with zero-cost infrastructure. More projects on my portfolio: akin-coskun.web.app.

I Solved Double-Booking Without Locks — Using One PostgreSQL Constraint

Akın Coşkun — Fri, 21 Aug 2026 15:23:17 +0000

TL;DR

I built Randevu, a free appointment booking system for Turkish barbershops and hair salons. The UI was the easy part. The hard part was making sure two customers can never grab the same time slot, even when they both hit "confirm" in the same millisecond. Instead of application-level locks, a job queue, or "check-then-insert and hope," I pushed the guarantee down into the database itself with a single PostgreSQL EXCLUDE constraint. Here's why that works and everything else I had to build around it.

The problem every naive booking app has

Most booking flows look like this on the backend:

Check if the slot is free (SELECT ... WHERE time = X)
If free, insert the new appointment

That works fine in a demo. It breaks the moment two requests hit that code path close together. Both read "free" before either has written anything, both insert, and now you have two customers standing in the same chair at 2:00 PM. This is a textbook race condition, and "just add a loading spinner" does not fix it.

The usual fixes are:

Row-level locks, meaning SELECT with FOR UPDATE: works, but you have to remember to use it correctly on every code path that touches appointments, forever.
A job queue that serializes all writes: solves it, but now you've added an entire piece of infrastructure just to stop double-booking.
A unique constraint on the exact timestamp: only works if every appointment has an identical, fixed duration. The moment services have different lengths, this falls apart, because two ranges can overlap without their start times ever matching.

What actually works: EXCLUDE with a range type

Postgres has a constraint type built almost exactly for this: EXCLUDE USING gist. Instead of saying "these two rows can't have the same value," it says "these two rows can't overlap," using a range type (tstzrange) and the btree_gist extension.

Conceptually, the constraint on the appointments table says: for a given barber, no two rows may have overlapping start_time to end_time ranges. It doesn't matter if the request comes from the API, a background job, or a manual database edit, Postgres itself refuses the insert if it overlaps. No application code has to remember to check anything, because it is physically impossible to violate.

The practical effect: when two customers submit a booking for overlapping times at the same instant, one INSERT succeeds and the other fails with a constraint violation, which the API just turns into a normal "sorry, that slot was just taken" response. No locks to hold, no queue to babysit, no race condition, ever.

Appointment timeouts had to be dynamic, not fixed

A "held" appointment (customer started checkout but hasn't confirmed) needs to expire so it doesn't block the slot forever. A flat "expires in 10 minutes" rule sounds simple until you notice it breaks at closing time: if a shop closes at 8 PM and someone starts booking at 7:55, a fixed timeout can quietly hold a slot past close, or expire mid-conversation. So the hold duration is calculated relative to the barber's actual working hours for that day, not a constant, short enough near closing time, normal otherwise.

WhatsApp notifications without the WhatsApp Business API

The official WhatsApp Business API is built for companies with support teams and approval budgets, not a single barber. Randevu sends confirmations and reminders as automated messages over regular WhatsApp instead of requiring the shop to apply for, pay for, and integrate the Business API. The customer gets a normal WhatsApp message; the barber never has to touch a Meta developer console.

Push notifications without Firebase

Web push almost always means "add Firebase Cloud Messaging." Randevu skips it and talks to the browser's Push API directly with VAPID keys: no Firebase project, no extra vendor, one less thing to configure per environment.

Keeping the public booking link bot-free

A booking page has no login wall by design, that's the whole point, a customer shouldn't need an account. But an open, unauthenticated form is exactly what booking-spam bots look for. Cloudflare Turnstile sits in front of the confirm step as an invisible, non-annoying check, so real customers never see a CAPTCHA, but scripted submissions get filtered out before they ever reach the database.

The stack

Next.js 16 and TypeScript, full-stack, no separate backend
Prisma and PostgreSQL on Neon, with the EXCLUDE constraint enforced at the database level
Upstash Redis and QStash for scheduling reminders and expiring holds
Web Push (VAPID) for notifications
Cloudflare Turnstile for bot protection on the public booking form

Try it

Randevu is free for barbershops and hair salons, no app to install, no monthly fee. Live at randevu-five.vercel.app, source on GitHub: akincskn/randevu.

I'm Akın Coşkun, a full-stack developer from Turkey building production SaaS tools with zero-cost infrastructure. More projects on my portfolio: akin-coskun.web.app.

I Solved Double-Booking Without Locks — Using One PostgreSQL Constraint

Akın Coşkun — Fri, 21 Aug 2026 15:15:51 +0000

TL;DR

The problem every naive booking app has

Most booking flows look like this on the backend:

Check if the slot is free (SELECT ... WHERE time = X)
If free, insert the new appointment

The usual fixes are:

Row-level locks, meaning SELECT with FOR UPDATE: works, but you have to remember to use it correctly on every code path that touches appointments, forever.
A job queue that serializes all writes: solves it, but now you've added an entire piece of infrastructure just to stop double-booking.
A unique constraint on the exact timestamp: only works if every appointment has an identical, fixed duration. The moment services have different lengths, this falls apart, because two ranges can overlap without their start times ever matching.

What actually works: EXCLUDE with a range type

Appointment timeouts had to be dynamic, not fixed

WhatsApp notifications without the WhatsApp Business API

Push notifications without Firebase

Keeping the public booking link bot-free

The stack

Next.js 16 and TypeScript, full-stack, no separate backend
Prisma and PostgreSQL on Neon, with the EXCLUDE constraint enforced at the database level
Upstash Redis and QStash for scheduling reminders and expiring holds
Web Push (VAPID) for notifications
Cloudflare Turnstile for bot protection on the public booking form

Try it

Randevu is free for barbershops and hair salons, no app to install, no monthly fee. Live at randevu-five.vercel.app, source on GitHub: akincskn/randevu.

I'm Akın Coşkun, a full-stack developer from Turkey building production SaaS tools with zero-cost infrastructure. More projects on my portfolio: akin-coskun.web.app.

How I Built an AI SDR Agent That Finds Leads and Writes Personalized Cold Emails

Akın Coşkun — Sat, 21 Mar 2026 14:42:59 +0000

TL;DR
I built LeadPilot — an AI-powered Sales Development Representative that automates lead discovery, company research, pain point analysis, and personalized cold email generation. A 4-agent AI pipeline does in 5 minutes what takes a human SDR 4+ hours. Here's how it works and what I learned building it.

What is an AI SDR Agent?
An SDR (Sales Development Representative) is the person who finds potential customers, researches them, and sends the first outreach message. It's the starting point of every sales pipeline.
An AI SDR agent automates this entire process. Instead of manually searching LinkedIn, reading company websites, and writing individual emails, AI does it all — faster, more consistently, and at scale.
LeadPilot handles 4 steps that would normally take hours:

Find leads matching your target criteria
Research each company by analyzing their website
Identify pain points relevant to your offering
Write personalized emails — not templates, genuinely personalized to each company

Why I Built This
I'm a freelancer. I need clients. The traditional approach — browsing job boards, sending generic proposals — is slow and competitive. Cold outreach works better, but it's time-consuming to do well.
I wanted a tool where I could say "Find SaaS companies with 10-50 employees that might need automation" and get back a list of companies with ready-to-send emails. So I built one.

The 4-Agent Architecture
LeadPilot uses a sequential AI pipeline. Each agent has a specific job, and the output of one feeds into the next.
Agent #1: Lead Finder
The user provides: target sector, company size, location, and their product/service. The Lead Finder uses Serper.dev (Google Search API) to find matching companies. It runs multiple search queries in parallel to cast a wide net, then AI extracts structured company data from the search results.
Input: "SaaS companies, 10-50 employees, US, N8N automation setup"
Output: List of 10 companies with names, websites, and descriptions.
Agent #2: Company Researcher
For each lead, this agent fetches the company's website using Cheerio (server-side HTML parsing) and extracts: what they do, their products, about page content, team information, and any public contact details.
This is where personalization starts. The researcher doesn't just grab the company name — it understands their business, their tech stack, their recent activity.
Agent #3: Pain Point Analyzer
This is the strategic brain. It takes the company profile and the user's product/service, then identifies specific pain points this company likely has. It also generates a match score (0-100) and the best "angle" for outreach.
For example: "This company uses Shopify but handles order notifications manually. Your N8N automation could save them 15+ hours/week on order processing workflows. Match score: 82."
Agent #4: Email Composer
The final agent writes a 3-email sequence for each lead:

Email 1 (Day 0): First touch. Opens with something specific about their company. States the problem. Offers the solution. Clear call-to-action.
Email 2 (Day 3): Follow-up. Different angle, social proof or case study reference.
Email 3 (Day 7): Last attempt. Short, direct, final compelling reason.

Every email is under 150 words. No corporate jargon. No "I hope this email finds you well." Each one references specific details about the company — because the previous agents already did the research.

The Tech Stack (Zero Cost)
LayerTechnologyCostFrontend + BackendNext.js 14 + Tailwind + shadcn/ui$0AI (Primary)Groq Llama 3.3 70B$0AI (Fallback)Google Gemini 2.0 Flash$0SearchSerper.dev (2,500 free searches/month)$0HTML ParsingCheerio$0AuthNextAuth.js v5$0DatabaseNeon PostgreSQL + Prisma$0DeployVercel$0
Total: $0/month.

Technical Challenges I Solved
Challenge 1: Long-Running Pipeline
A 10-lead campaign takes 3-5 minutes. You can't keep an HTTP connection open that long. My solution: fire-and-forget pattern. The API starts the pipeline in the background, immediately returns a campaign ID. The frontend polls /api/campaign/[id]/status every 2 seconds to get progress updates.
The user sees: "Finding leads... (3/10 found)" → "Researching companies... (5/10)" → "Composing emails... (9/10)" → "Complete!"
Challenge 2: AI Returning Invalid JSON
AI models sometimes return markdown-wrapped JSON, add explanations, or produce malformed structures. My solution: strict prompt instructions ("Respond ONLY with valid JSON"), JSON parse with try/catch, one retry with the same model, then fallback to the secondary model. If both fail, the lead is marked with an error but the pipeline continues.
Challenge 3: Website Scraping Reliability
Not every website plays nice. Some block scrapers (403), some redirect infinitely, some are entirely JavaScript-rendered (invisible to Cheerio). My solution: 10-second timeout on all fetches, User-Agent header to avoid blocks, graceful degradation (if scraping fails, the AI works with whatever the search result provided).
Challenge 4: Prompt Injection
Users enter free text (sector, product description, value proposition) that gets injected into AI prompts. A malicious user could try to manipulate the AI's behavior. My solution: input sanitization that strips control characters and potential injection patterns before they reach the prompt.
Challenge 5: SSRF Protection
The scraper fetches URLs from search results. Without protection, an attacker could trick it into fetching internal network resources. My solution: URL validation that blocks localhost, private IP ranges, and non-HTTP protocols before any fetch request.

What Makes Good Cold Emails
Building the Email Composer agent taught me a lot about cold outreach:
Personalization is everything. "I noticed your company uses Shopify" beats "Dear business owner" by 10x. The research agents exist specifically to feed the email agent with personalization material.
Shorter is better. Every email is capped at 150 words. Busy people don't read essays from strangers.
One CTA per email. "Would you be open to a 15-minute call?" — not "check our website, read our blog, follow us on LinkedIn, and also here's a PDF."
The 3-email sequence matters. Most responses come from email 2 or 3, not email 1. Persistence (without being annoying) is key. Day 0, Day 3, Day 7 is the sweet spot.

Real Output Example
Campaign: "Find marketing agencies in the US that need AI automation"
Lead: Bright Spark Digital (fictional example)
Email 1 — Day 0:
Subject: "Quick question about your client reporting"
"Hi Sarah, I noticed Bright Spark Digital manages campaigns across Google Ads and Meta for multiple clients. Reporting across platforms usually eats up 5-10 hours per week for agencies your size. I build custom AI automation workflows that pull data from all ad platforms into unified dashboards — automatically. Would you be open to a quick 15-minute chat about how this could work for your team?"
Email 2 — Day 3:
Subject: "Re: your client reporting"
"Hi Sarah, following up on my previous note. I recently helped a similar-sized agency reduce their weekly reporting time from 8 hours to 20 minutes using N8N automation. Happy to share exactly what we built. Worth a quick conversation?"
Email 3 — Day 7:
Subject: "Last note"
"Hi Sarah, I know you're busy. One quick question: if you could automate one repetitive task in your agency, what would it be? I might already have a solution built. Either way, no hard feelings — just wanted to make sure this didn't slip through the cracks."

Try It

Live app: leadpilot-ashy.vercel.app
Source code: github.com/akincskn/leadpilot

Create a campaign, define your target market, and get personalized leads with email sequences in minutes.

What's Next
LeadPilot is part of a larger ecosystem of AI tools I'm building. If you're interested in AI automation, SDR tooling, or building SaaS with zero-cost infrastructure, follow me for more.
Other tools in the ecosystem:

RivalRadar — AI competitor analysis
GEO Analyzer — AI search optimization scoring
Portfolio MCP Server — Query my portfolio via AI assistants

I'm Akın Coşkun, a full-stack developer and AI automation specialist from Turkey. I build production SaaS applications with zero-cost infrastructure. Find me on GitHub or check my portfolio.

I Analyzed My Portfolio with AI and Scored 53/100 — Here's How I Fixed It to 85+

Akın Coşkun — Sat, 21 Mar 2026 14:40:45 +0000

TL;DR
I built a GEO (Generative Engine Optimization) analyzer tool, tested it on my own portfolio site, and scored a disappointing 53/100. Then I systematically fixed every issue it found. Here's the exact process, what I changed, and why it matters for anyone who wants their content to appear in ChatGPT, Perplexity, and Google AI Overviews.

What is GEO and Why Should You Care?
Generative Engine Optimization is the practice of structuring your content so AI search engines can find, understand, and cite it. Traditional SEO gets you ranked on Google. GEO gets you mentioned in AI-generated answers.
This matters because the way people search is changing fast. Instead of clicking through 10 blue links, users are asking ChatGPT "What's the best competitor analysis tool?" or asking Perplexity "How do I automate cold outreach?" If your content isn't optimized for these AI engines, you're invisible to a growing segment of your audience.

The Tool I Built
GEO Analyzer evaluates any web page across 5 categories, each scored out of 20 points for a total of 100:

Content Structure — H1 tags, heading hierarchy, question-based H2s, internal links
E-E-A-T Signals — Author info, dates, citations, statistics, trust indicators
Technical AI Readiness — Meta tags, schema markup, Open Graph, canonical URLs, AI crawler access
Content Quality — Value, clarity, flow, Q&A format, originality (AI-evaluated)
AI Search Optimization — Snippable content, FAQ structure, definitions, lists, topic focus (AI-evaluated)

The first three categories are analyzed programmatically using Cheerio for HTML parsing. The last two use Groq's Llama 3.3 model for AI-powered evaluation, with Gemini as a fallback.

My Score: 53/100 (Grade: F)
Here's what the analyzer found on my portfolio site:
CategoryScoreIssuesContent Structure6/20No H1 tag, no question-based H2s, only 1 internal linkE-E-A-T Signals13/20No publication date, no statisticsTechnical AI Readiness13/20No schema markup, no canonical URLContent Quality13/20Low Q&A format, weak flowAI Search Optimization8/20No snippable content, no FAQ, no definitions
The biggest problems were clear: no schema markup (AI crawlers couldn't understand my site's structure), no question-based headings (AI engines love Q&A format), and no "snippable" content (short, quotable sentences AI can cite directly).

The Fixes (53 → 85+)
Fix 1: Schema Markup (0 → 5 points)
I added JSON-LD structured data to my site. This tells AI crawlers exactly who I am and what I do:
A Person schema with my name, job title, skills, and social links. Plus a FAQPage schema for common questions. AI engines parse this structured data directly — it's like handing them a summary card instead of making them read your entire page.
Fix 2: Single H1 + Question-Based H2s (0 → 10 points)
Changed my heading structure. One clear H1 at the top. H2s reformatted as questions: "What Technologies Do I Work With?", "What Problems Do I Solve?", "How Can I Help Your Business?"
AI engines are trained on billions of question-answer pairs. When your heading is a question and the content below answers it, you're speaking their language.
Fix 3: Snippable Content (0 → 5 points)
Added short, definitive sentences that AI can quote directly. For example: "Akın Coşkun is a full-stack developer specializing in AI-powered automation, N8N workflows, and zero-cost SaaS development."
This sentence is designed to be the answer when someone asks an AI "Who is Akın Coşkun?" or "Who builds N8N automations?"
Fix 4: FAQ Section with Schema (0 → 4 points)
Added a dedicated FAQ section with 5 common questions, each with a concise answer. Backed by FAQPage schema markup so AI engines can extract Q&A pairs directly.
Fix 5: Statistics and Data (0 → 4 points)
Added concrete numbers: "10+ production projects", "$0/month infrastructure cost", "1 published npm package", "4 professional certifications." AI engines love citing specific statistics.
Fix 6: Internal Linking (1 → 4 links)
Connected everything: project cards link to blog posts, blog section links to projects, FAQ links to relevant pages. AI crawlers follow internal links to build a complete picture of your site.
Fix 7: Canonical URL + robots.txt
Added canonical URL to prevent duplicate content issues. Updated robots.txt to explicitly allow AI crawlers (GPTBot, ClaudeBot, PerplexityBot).

What I Learned About GEO
After going through this process, here are the key takeaways:
Schema markup is non-negotiable. It's the single most impactful thing you can add for AI visibility. Person, FAQPage, SoftwareApplication — these schemas give AI engines structured data they can parse instantly.
Question-based headings work. AI engines are fundamentally Q&A machines. Format your content as questions and answers, and you're aligning with how they process information.
Snippable sentences are your AI elevator pitch. Write 1-2 sentences per section that could stand alone as an AI-generated answer. Clear, definitive, factual.
Traditional SEO still matters. AI engines often use Google search results as their source. If you rank well on Google, you're more likely to be cited by ChatGPT and Perplexity.
E-E-A-T is universal. Whether it's Google's algorithm or an LLM deciding which source to cite, expertise, experience, authoritativeness, and trust are what get you chosen.

Try GEO Analyzer Yourself
Enter any URL and get your GEO score with specific recommendations:

Live app: geo-analyzer-sepia.vercel.app
Source code: github.com/akincskn/geo-analyzer

What's Next
GEO is still a new field. Most websites score below 50/100 because nobody's optimizing for AI search yet. The developers and marketers who start now will have a massive advantage as AI search becomes the default.
I'm continuing to build tools in this space. If you're interested in GEO/AEO, AI automation, or zero-cost SaaS development, follow me for more.

I'm Akın Coşkun, a full-stack developer and AI automation specialist. I build tools like RivalRadar (AI competitor analysis), GEO Analyzer (AI search optimization), and LeadPilot (AI SDR agent). Find me on GitHub or check my portfolio.

N8N for AI Automation: How I Built Multi-Agent Workflows That Actually Work

Akın Coşkun — Thu, 19 Mar 2026 19:25:41 +0000

TL;DR
N8N isn't just a "Zapier alternative." I use it as the backbone for AI agent orchestration — multi-step workflows where AI models analyze data, make decisions, and produce structured outputs. Here's my practical guide based on building two production applications with N8N.

Why N8N Over Code?
Let me be direct: I can write Node.js. I can build Express APIs. I could orchestrate AI agents entirely in code using LangChain or CrewAI.
But I choose N8N for certain workflows because:
Visual debugging is unmatched. Click any node, see exactly what data went in and came out. When an AI agent produces garbage, you can inspect the prompt, the input data, and the response in seconds. In code, you'd be adding console.logs and redeploying.
Fallback logic is trivial. My primary AI model (Groq) sometimes hits rate limits. In N8N, I add an IF node after the AI call — if error, route to Gemini. Done. In code, this is a try/catch with retry logic, environment variables, and error classification.
Non-linear workflows are natural. Split a list of competitors into parallel analysis paths, merge the results, then feed everything into a report generator. N8N's Split In Batches → parallel nodes → Merge pattern handles this visually.
Changes don't require redeployment. I can update an AI agent's prompt directly in N8N's editor. No git commit, no CI/CD, no Vercel rebuild. For iterating on AI prompts, this speed matters.

My N8N Architecture Pattern
After two production projects (FormJet and RivalRadar), I've settled on this pattern:
Next.js Frontend
↓ (POST request)
Next.js API Route
↓ (auth check, validation, credit check)
N8N Webhook
↓ (workflow execution)
AI Agent Pipeline
↓ (structured JSON output)
N8N HTTP Response
↓
Next.js API Route
↓ (save to database, return to frontend)
Frontend renders result
The frontend never talks to N8N directly. The API route acts as a gateway — handling auth, input validation, and database operations. N8N only handles the AI orchestration part.
This separation matters because:

Auth stays in your application (not in N8N)
Database operations use Prisma (type-safe, not N8N's generic DB nodes)
N8N focuses on what it's best at: workflow orchestration

Building an AI Agent Pipeline in N8N
Here's the actual workflow structure from RivalRadar:
Step 1: Webhook Trigger
Receives company name + industry from the frontend.
Step 2: AI Agent — Competitor Finder

System prompt: "You are a competitive intelligence analyst. Given a company and industry, identify the top 5 direct competitors."
Tools: HTTP Request node configured for web search
Output: JSON array of competitor names

Step 3: Split In Batches
Takes the competitor array and processes each one individually. This is N8N's loop mechanism.
Step 4: AI Agent — Company Analyzer (runs per competitor)

System prompt: "Analyze this company. Return: overview, key products, pricing model, target audience."
Tools: HTTP Request for web research
Output: Structured company profile

Step 5: Merge
Collects all individual analyses back into a single array.
Step 6: AI Agent — Report Generator

Input: All competitor analyses + original company
System prompt: "Generate a competitive analysis report with: SWOT analysis, pricing comparison table, market positioning, and 3-5 actionable recommendations."
Output: Complete report JSON

Step 7: HTTP Response
Returns the report to the calling API route.

Practical Tips from Production
Tip 1: Always Force JSON Output
In your AI agent's system prompt, add:
IMPORTANT: Respond ONLY with valid JSON. No markdown, no explanations, no code blocks. Just pure JSON.
Then add a JSON Parse node right after. If it fails to parse, your error handler catches it and retries.
Tip 2: Implement Fallback Models
[AI Agent (Groq)] → [IF: error?]
↓ Yes
[AI Agent (Gemini)]
↓ No
[Continue workflow]
Rate limits are real on free tiers. Always have a backup model.
Tip 3: Use Sub-Workflows for Reusable Agents
If you have the same "analyze a company" agent used in multiple places, make it a sub-workflow. Call it from your main workflow with parameters. This is N8N's version of function extraction.
Tip 4: Log Everything to Stderr
N8N's stdout is reserved for the protocol. Use console.error() for debugging logs. This caught me off guard initially.
Tip 5: The Webhook Path Bug
If you're self-hosting N8N and your webhook paths aren't working, check the SQLite database. When webhookId is missing from the node data, getNodeWebhookPath() generates a compound path instead of your clean path. The fix: insert webhookId directly into the DB. The isFullPath: true flag only works when webhookId exists.

N8N vs Code-Based Alternatives
CriteriaN8NLangChain/CrewAIVisual debuggingExcellentNone (logs only)Prompt iteration speedInstant (edit in UI)Requires redeployComplex branchingVisual and intuitiveCode-basedVersion controlExport JSONGit nativeType safetyNoneFull TypeScriptTestingManual in UIUnit testableProduction monitoringBuilt-in execution logsCustom implementation
My take: Use N8N for AI orchestration workflows where you need rapid iteration. Use code-based frameworks when you need type safety, unit testing, and tight integration with your application logic.

Self-Hosting N8N for Free
Here's my setup:

Render.com — Free tier web service running N8N's Docker image
UptimeRobot — Pings the instance every 5 minutes to prevent sleep
SQLite — N8N's default database (sufficient for low-volume workflows)

Total cost: $0/month.
The trade-off: Render's free tier sleeps after 15 minutes of inactivity. UptimeRobot keeps it alive, but the first request after a sleep cycle takes ~30 seconds. For my use case (on-demand analysis), this is acceptable.

What I'm Building Next
I'm expanding into:

CrewAI/LangChain for code-based multi-agent systems
MCP servers for connecting AI to custom data (already published one on npm)
GEO/AEO optimization tools for AI search visibility
SDR automation agents for sales outreach

N8N will remain my go-to for rapid prototyping and visual workflow design. But as I tackle more complex agent architectures, I'll complement it with code-based frameworks.

Resources

N8N Documentation
N8N AI Agent Templates
My project using N8N — RivalRadar
My project using N8N — FormJet

I'm Akın Coşkun, a full-stack developer specializing in AI automation and N8N workflows. Find me on GitHub or check my portfolio.

I Published My Own MCP Server on npm — Here's Why Every Developer Should

Akın Coşkun — Thu, 19 Mar 2026 19:25:00 +0000

TL;DR
MCP (Model Context Protocol) is becoming the standard for connecting AI models to external data. I built a personal portfolio MCP server and published it on npm. Now anyone can add my server to Claude Desktop and ask AI about my projects, skills, and experience. Here's how I built it and why this matters for your career.

What is MCP?
If you've used Claude Desktop, Cursor, or Claude Code recently, you've probably seen MCP in action. MCP is an open protocol developed by Anthropic that lets AI models talk to external tools and data sources.
Think of it this way:

REST API: Human (browser) → your server → data → human reads it
MCP: AI model (Claude) → your server → data → AI uses it to answer questions

If you know how to build an Express API, you already know 90% of what you need to build an MCP server. The concepts are identical — you define endpoints (called "tools" in MCP), handle inputs, and return responses. The only difference is the protocol.

Why I Built a Portfolio MCP Server
The idea is simple: instead of copy-pasting my project details into every AI conversation, I built a server that AI can query directly.
When someone adds my MCP server to Claude Desktop and asks "What are Akın's projects?", Claude calls my server, gets the data, and presents it naturally.
This is powerful for three reasons:

Personal branding. Almost nobody has a personal MCP server. It immediately signals that you understand cutting-edge AI infrastructure.
Practical demonstration. Instead of saying "I know MCP" on your resume, you can say "Here's my MCP server — install it and try it."
It's the future. MCP is becoming the de facto standard. OpenAI is sunsetting their Assistants API in favor of MCP. Over 1,000 community-built MCP servers already exist. This ecosystem is only growing.

How I Built It
The Stack

TypeScript (strict mode)
@modelcontextprotocol/sdk (official MCP SDK)
Zod (input validation)
stdio transport (runs locally, no server needed)

Project Structure
akin-portfolio-mcp/
├── src/
│ ├── index.ts # MCP server entry point
│ ├── data/
│ │ ├── about.ts # Personal info
│ │ ├── skills.ts # Tech stack
│ │ └── projects.ts # All 8 projects
│ ├── tools/
│ │ ├── about.ts # get_about, get_contact tools
│ │ ├── skills.ts # get_skills tool
│ │ └── projects.ts # get_projects, search_projects tools
│ └── types/
│ └── index.ts # TypeScript interfaces
├── package.json
├── tsconfig.json
└── README.md
Defining a Tool
Here's the core pattern. If you've ever written an Express route handler, this will look familiar:
typescriptserver.tool(
"get_projects",
"Lists all of Akın's projects with descriptions and tech stacks",
async () => {
return {
content: [{
type: "text",
text: JSON.stringify(projects, null, 2)
}]
};
}
);
That's it. Define a name, a description (this is what the AI reads to decide when to call your tool), and a handler function.
For tools with parameters, you add a Zod schema:
typescriptserver.tool(
"search_projects",
"Search projects by technology or keyword",
{ keyword: z.string().describe("Technology or keyword to search for") },
async ({ keyword }) => {
const results = projects.filter(p =>
p.stack.some(s => s.toLowerCase().includes(keyword.toLowerCase())) ||
p.description.toLowerCase().includes(keyword.toLowerCase())
);
return {
content: [{
type: "text",
text: results.length > 0
? JSON.stringify(results, null, 2)
: No projects found matching "${keyword}"
}]
};
}
);
Publishing to npm
The key insight: MCP servers distributed via npm can be run with npx — no installation required. Users just add this to their Claude Desktop config:
json{
"mcpServers": {
"akin-portfolio": {
"command": "npx",
"args": ["-y", "akin-portfolio-mcp"]
}
}
}
To make this work, your package.json needs a bin field pointing to your compiled entry point, and you need .npmignore to exclude source files from the published package.

The 7 Tools My Server Provides

get_about — Personal information and bio
get_skills — Full tech stack by category
get_projects — All 8 projects with details
get_project_detail — Deep dive into a specific project
search_projects — Find projects by technology keyword
get_contact — Contact information
get_experience_summary — Career overview

What I Learned
MCP is easier than you think. If you can write a TypeScript function, you can build an MCP server. The SDK handles all the protocol complexity.
Descriptions matter more than code. The tool descriptions are what the AI reads to decide when to call your tools. Poor descriptions = AI never uses your tools. Good descriptions = seamless integration.
stdio is the simplest transport. No server deployment needed. The MCP server runs as a local process on the user's machine. npm distribution makes it effortless.
Error handling is critical. When a user asks about a project that doesn't exist, your server should return a helpful error, not crash. I use isError: true in responses so Claude can communicate failures gracefully.

Try It Yourself
Install my server:
bashnpx akin-portfolio-mcp
Or add it to Claude Desktop / Claude Code:
bashclaude mcp add akin-portfolio npx -y akin-portfolio-mcp
Then ask: "What are Akın's projects?" or "Does Akın know N8N?"
Source code: github.com/akincskn/akin-portfolio-mcp
npm: npmjs.com/package/akin-portfolio-mcp

You Should Build One Too
Seriously. Here's why:

It takes a weekend (mine took a day)
It demonstrates real MCP knowledge
It's a conversation starter in interviews and on LinkedIn
Almost nobody has one yet — you'll stand out

Start with your portfolio data. Add your projects, skills, and experience. Publish it on npm. Link it in your GitHub README. That's it — you now have an MCP server that AI assistants can use to learn about you.
The developers who understand MCP early will have a significant advantage as this ecosystem grows. Don't wait.

I'm Akın Coşkun, a full-stack developer building AI-powered tools and MCP servers. Find me on GitHub or try my MCP server: npx akin-portfolio-mcp