Project

You have reached the final tutorial. Let’s build a complete full-stack Task Manager that uses everything you have learned in this series. What We Are Building A task manager app where users can: Sign in with GitHub Create, complete, and delete tasks See only their own tasks Filter tasks by status Tech stack: Next.js 15 (App Router) TypeScript Prisma v6 + PostgreSQL NextAuth.js v5 (GitHub OAuth) Tailwind CSS v4 Project Setup npx create-next-app@latest taskmanager # Choose: TypeScript, ESLint, Tailwind CSS, src/, App Router, Turbopack cd taskmanager npm install prisma @prisma/client next-auth@beta npm install @hookform/resolvers react-hook-form zod npx prisma init Database Schema // prisma/schema.prisma generator client { provider = "prisma-client-js" } datasource db { provider = "postgresql" url = env("DATABASE_URL") } model User { id String @id @default(cuid()) email String @unique emailVerified DateTime? name String? image String? createdAt DateTime @default(now()) tasks Task[] accounts Account[] sessions Session[] } model Task { id String @id @default(cuid()) title String description String? done Boolean @default(false) priority Priority @default(MEDIUM) createdAt DateTime @default(now()) updatedAt DateTime @updatedAt userId String user User @relation(fields: [userId], references: [id], onDelete: Cascade) } enum Priority { LOW MEDIUM HIGH } Notice we use String @id @default(cuid()) instead of Int @id @default(autoincrement()). cuid() generates random IDs that are safe to use in URLs without exposing sequential numbers. ...

In Part 1, we built a TCP server with SET, GET, and DEL. In Part 2, we added expiry, persistence, and pub/sub. Now we add more data types, benchmark our implementation, and make it production-ready. In this final part, we add: INCR — atomic integer increment LPUSH, LPOP, LRANGE — list operations Benchmarks against real Redis Graceful shutdown with signal handling Better error handling throughout Adding INCR INCR atomically increments a number stored at a key. If the key does not exist, it starts at 0. If the value is not a number, it returns an error. This is how real Redis counters work. ...

In Part 1, we built a TCP server that speaks the Redis protocol. We implemented SET, GET, and DEL commands with in-memory storage. But real Redis has many more features. In this part, we add three important features: Key expiry — keys that delete themselves after a timeout Persistence — saving data to disk so it survives restarts Pub/Sub — publish and subscribe messaging between clients Key Expiry In real Redis, you can set a key with an expiration time. After that time, the key disappears. This is useful for caches, sessions, and rate limiting. ...

Have you ever wondered how Redis works under the hood? In this mini-series, we build a Redis clone from scratch in Rust. No magic. Just a TCP server, a protocol parser, and a HashMap. By the end of this series, you will have a working key-value store that speaks the real Redis protocol. You can connect to it with redis-cli and run commands. This is Part 1. We will build: ...

This is the capstone article. Everything from 14 projects comes together. We started this series with a CLI todo app that took 35 minutes. Then we built REST APIs, Chrome extensions, full-stack blogs, SaaS dashboards, and mobile apps. Each project taught us something about working with Claude Code. Now the question: can we take a real product idea — something that could make money — from concept to deployed, production-ready app in a single working day? ...

Mobile development is hard. Cross-platform mobile development is harder. Kotlin Multiplatform sits in the middle — shared business logic with native UI on each platform. The Gradle configuration alone can take hours. Can Claude handle it? This is the most technically challenging project in the entire series. KMP has expect/actual declarations, platform-specific dependency injection, multiplatform Gradle config, and two completely different UI frameworks (Jetpack Compose for Android, SwiftUI for iOS). ...

Every article so far has used one Claude Code session. One terminal, one conversation, one context. That works for small projects, but what about larger codebases where different parts can be built in parallel? Claude Code supports multiple agents working on the same project. You can have one agent building the backend, another building the frontend, and a third writing tests — all at the same time. This article tests whether multi-agent development actually works. Does it save time? What happens when agents step on each other’s code? How do you coordinate? ...

SaaS boilerplate kits sell for $200-$500 on marketplaces. They include authentication, Stripe subscriptions, admin panels, and billing portals. The same starter template, over and over. Let us build one with Claude in an afternoon. This is the most complex project in the series so far. Stripe’s webhook lifecycle, subscription state management, role-based access, and usage tracking all need to work together. A lot can go wrong. Total time: 5 hours 22 minutes. 7 prompts. Stripe webhooks took the most iteration. ...

Welcome to Part 3: Advanced Projects. We are done with quick builds and half-day apps. Now we tackle complex, multi-component systems. First up: a real-time chat application. WebSockets, authentication, rooms, typing indicators, online presence, message history. This is the kind of project that tests whether Claude can handle multiple moving parts that all need to work together in real time. Total time: 4 hours 38 minutes. 7 prompts. WebSocket auth was the hardest part. ...

After a full-stack blog, a weather dashboard, a desktop app, and a mobile app, we close Part 2 with something different: a backend microservice in Go. Go is interesting for vibe coding because the language is simple and opinionated. There is usually one way to do things. Claude should have an easier time generating idiomatic Go than, say, idiomatic Rust. Let us find out. Total time: 2 hours 14 minutes. 6 prompts. Go’s simplicity made this the fastest Part 2 project. ...