Real Projects

This module is where everything comes together. I am going to walk you through my most significant projects — not as a feature list, but as stories. For each one, I will tell you: what problem sparked it, what the first session with Claude looked like, the key decisions I made along the way, what surprised me or was hardest, and where the project is today. These are not toy demos. These are real applications solving real problems for real people.

The problem that sparked SMTPCloud Dashboard:

I was managing email campaigns at work and every tool I tried either cost a fortune or did not do what I needed. I needed to send email campaigns, track delivery in real time, manage recipient lists, handle bounces and unsubscribes, and see analytics — all in one place. Commercial platforms charge $500-2,000/month for this. I thought: what if I built my own?

This was not my first project. By this point, I had already built CampaignPulse, Quality Monitoring, and several smaller tools. I had experience with React, Express, and PostgreSQL. But this was an order of magnitude more ambitious than anything before.

The first session:

My first prompt was something like: "I want to build a SaaS dashboard for managing email campaigns. Users should be able to sign up, create campaigns with HTML content, upload recipient lists from CSV files, and send campaigns through SMTP. I need a dashboard showing delivery stats — sent, delivered, bounced, opened, clicked. Let us start with the project setup: Next.js frontend with TypeScript and Tailwind, Express backend with TypeScript, PostgreSQL database."

Claude set up the monorepo structure, the basic database schema (users, campaigns, recipients), and the authentication system. That first session gave me a login page, a dashboard skeleton, and the ability to create a campaign. Not pretty, not complete, but it worked. That was the foundation everything else was built on.

Key technical decisions and why:

- Raw SQL instead of an ORM — With 30+ tables and complex queries involving multiple JOINs, aggregations, and subqueries, I needed full control over the SQL. ORMs abstract too much for this level of complexity.
- Express for the backend instead of Next.js API routes — The backend needed to handle SMTP connections, background job processing, webhook receiving, and long-running tasks. Express gave me the flexibility to structure this properly.
- Vercel for frontend, Hetzner for backend — The frontend is a static React app that benefits from Vercel's global CDN. The backend needs persistent connections and background processes that Vercel cannot handle.
- JWT authentication with httpOnly cookies — Secure, stateless, works well for a SaaS with multiple user roles.
- Bot detection for email opens — Security scanners at email providers automatically "open" every email to check for malware. Without bot detection, open rates would be wildly inflated. Claude helped me build a system to identify and filter these fake opens.

Every one of these decisions came from hitting a real problem. I did not plan them upfront. I discovered I needed them.

What surprised me / what was hardest:

The email sending pipeline was the hardest part by far. It is not just "send an email" — it is: queue the emails, respect rate limits per domain (Gmail has different limits than Yahoo), handle bounces in real time via webhooks, retry failed sends with exponential backoff, track opens and clicks via tracking pixels and redirect URLs, manage unsubscribes for compliance, and rotate sending domains when one gets throttled.

What surprised me most was how much business logic goes into a SaaS. Features I never thought about at the start: API key management for programmatic access, Google Postmaster Tools integration, A/B testing for subject lines, timezone-aware sending, domain verification, and smart throttling. Each of these was its own multi-session project within the larger project.

Current state:

44,000+ lines of code. 145 git commits. 30+ database tables. 50+ API endpoints. User management with admin and client roles. Full campaign lifecycle from creation to analytics. Real-time tracking. A/B testing. Bot detection. Domain rate limiting. Running in production. This is the project that taught me everything.

The problem that sparked Quality Monitoring:

At INFUSE, the QA team tracked quality issues in Google Sheets. Seven different sheets for seven different teams. No dashboards, no automated reporting, no way to see trends or patterns. Team leads would manually count issues in their spreadsheet every week to write reports. It was slow, error-prone, and everyone knew the data was unreliable because people would forget to update their sheet.

I thought: what if there was a real tool that auto-synced from those sheets and provided dashboards, trends, and automated reports?

The first session and key decisions:

My first prompt: "I need a tool that syncs data from Google Sheets every 10 minutes and shows it in a web dashboard. There are 7 sheets, one per team. Each row is a quality issue with columns for category, severity, campaign, status, and assigned person. I need a dashboard showing issue counts by team, severity breakdown, and trends over time. Fastify for the backend, React with Vite for the frontend, PostgreSQL, deployed with Docker."

Key decisions:
- Fastify instead of Express — I wanted to try something different. Fastify is faster and has a great plugin system. Claude handled both equally well.
- Docker Compose from the start — I knew this would run on AWS and the team needed consistent environments.
- Google Sheets as the source of truth — People were already comfortable with Sheets. Instead of forcing them to switch, I synced FROM the sheets. They kept their workflow; they just got a better dashboard on top of it.
- AI-powered insights using Claude API — I connected the app to Claude's API so it could analyze patterns in quality issues and generate weekly insight summaries automatically.

111 automated tests. Role-based access with three levels (admin, team_lead, agent). Automated daily email reports. Used by real teams every single day at INFUSE.

What was hardest:

The Google Sheets sync was deceptively tricky. Rate limits (60 requests per minute), handling sheets with thousands of rows, dealing with inconsistent data formats (some people typed dates as "March 15" while others used "03/15/2024"), and making sure the sync did not miss changes or create duplicates. It took many iterations to make it bulletproof.

The problem that sparked it:

I got interested in crypto and Solana specifically. I wanted a system that could monitor token prices and execute trades automatically based on rules I defined — buy when a token drops 10%, sell when it rises 20%, that kind of thing. No existing bot did exactly what I wanted, and the ones that came close required trusting a third party with your wallet keys. I wanted to self-host everything and control my own keys.

This was the most technically ambitious project I had ever attempted. Blockchain APIs, real money on the line, cryptographic key management, real-time price feeds. Everything was new.

The first session:

My first prompt was something like: "I want to build a crypto trading bot for the Solana blockchain. It should monitor token prices via the Jupiter API, execute swaps when certain conditions are met, and send me Telegram alerts for every trade. I also need a web dashboard to configure trading rules, view portfolio, and see trade history. Monorepo with Turborepo. Next.js frontend, Express backend, PostgreSQL, TypeScript everywhere."

Claude set up the monorepo structure, the basic Solana wallet integration, and a simple price polling mechanism. The first version could check the price of SOL and display it on a web page. Not a trading bot yet, but a starting point.

Key technical decisions:

- Monorepo with Turborepo — shared TypeScript types between frontend, backend, and the trading engine. One npm install, everything works.
- BullMQ for job queues — trades are processed as background jobs. If the app restarts, pending trades do not get lost.
- AES-256 encryption for private keys — your Solana wallet key never stored in plaintext. Encrypted at rest, decrypted only when executing a trade.
- WebSocket connections — real-time price updates and trade notifications pushed to the dashboard instantly.
- Drizzle ORM — type-safe database queries. My first time using Drizzle, and I am sold on it for TypeScript projects.

This project also has a referral system built in, because I wanted to learn how SaaS monetization works.

What surprised me:

The biggest surprise was how critical error handling is when real money is involved. In a regular web app, if a request fails, you show an error message and the user tries again. In a trading bot, if a trade execution fails halfway through, you might end up in a state where you sold Token A but did not buy Token B. Every error scenario needed careful handling — retries with timeouts, transaction verification, balance checks before and after trades. Claude helped me think through every edge case, but it took many iterations to cover them all.

The problem that sparked it:

I collect things — cards, memorabilia — and I wanted a simple app to catalog my collection. Take a photo, have AI identify the item, log it with estimated value and details. Nothing on the market did exactly this with AI recognition. Plus, I wanted to learn mobile development.

This was my first time building anything for phones. Web development was familiar by this point, but mobile was a completely new world — app stores, native device features, camera access, push notifications.

The first session and key decisions:

"I want to build a mobile app for collectors. React Native with Expo. Users can photograph an item and the app uses Claude Vision API to identify it — what it is, estimated value, condition assessment. Items are stored in a collection with photos, descriptions, and values. Supabase for the backend — auth, database, file storage."

- React Native with Expo — same React concepts I already knew, but for mobile. Expo handles all the native build complexity.
- Claude Vision for item recognition — take a photo, send it to Claude, get back identification and value estimate. This was the killer feature.
- Supabase instead of building my own backend — for a mobile app, I wanted to move fast. Supabase gave me auth, database, and file storage out of the box.
- RevenueCat for subscriptions — handles Apple and Google payment processing. Building this yourself is a nightmare; RevenueCat abstracts it away.

Barcode scanning for quickly adding items. Social features — a feed where collectors share items, leave comments, rate collections. The social layer was the most complex part because it meant building a recommendation feed, notification system, and content moderation.

What was hardest:

Dealing with Apple and Google's app store requirements. Each platform has specific rules about UI, permissions, privacy policies, and in-app purchases. Getting the app approved required several rounds of fixing things the reviewers flagged. Claude helped me write the privacy policy, fix permission request wording, and adjust the UI to meet guidelines. The actual coding was not the hard part — the bureaucracy was.

The problem that sparked it:

This was the project that started it all (well, the first real web tool). Every email campaign at work needed manual QA: check all links work, verify UTM tracking parameters are present and correct, validate DNS records (SPF, DKIM, DMARC) for the sending domain, check HTML rendering, verify the unsubscribe link works. This took 30+ minutes per campaign, and we send dozens daily.

30 minutes times dozens of campaigns. Do the math. That is a lot of human hours wasted on mechanical checking.

The first session:

"I spend 30+ minutes doing QA on every email campaign. I want a tool where I paste the HTML and it automatically checks links, UTM parameters, and DNS records. Start with link checking — extract all URLs and verify each one returns 200. Vanilla JavaScript, no frameworks, keep it simple."

Claude gave me a single HTML file with a textarea, a button, and JavaScript that extracted URLs using regex and checked them. It did not work perfectly (CORS issues blocked browser-side URL checking), but it was a starting point.

Key decisions:
- Vanilla JavaScript — no React, no build tools, no npm. Just HTML, CSS, and JS files. I wanted it dead simple and instant to deploy.
- n8n webhooks for the heavy lifting — link checking and DNS lookups happen on the server side via n8n workflows, avoiding browser CORS limitations.
- GPT-4o for content analysis — the AI reads the email content and flags potential issues a human might miss (misleading subject lines, missing legal disclaimers, etc.).
- Scoring system — every check contributes to an overall score out of 100. Quick pass/fail at a glance.

Current state: Running in production at campaignpulse.infuse.com. What took 30 minutes now takes under 60 seconds. The QA team uses it for every single campaign. This is the project where the ROI was most obvious — hours saved every single day.

The problem that sparked it:

The lead management process at work was chaotic — leads tracked in spreadsheets, duplicate entries everywhere, no clear workflow for moving leads through statuses (new, contacted, qualified, converted, etc.). I needed a proper lead management tool with duplicate detection, bulk operations, and status tracking.

I chose Python and FastAPI for this one deliberately. I wanted to prove to myself that the approach — describe to Claude, build iteratively — works regardless of the programming language.

The first session:

"I need a lead management tool. Python with FastAPI for the backend. A frontend with AG Grid for a spreadsheet-like interface. PostgreSQL database with SQLAlchemy ORM. The main features: import leads from CSV, 13+ status categories, duplicate detection by email, bulk status updates. Deploy on my Hetzner server."

Key decisions:
- Python/FastAPI — different language from my usual TypeScript. FastAPI has automatic API documentation (Swagger), which is great for development.
- SQLAlchemy ORM with Alembic migrations — Python's mature database toolkit. More verbose than Drizzle but extremely reliable.
- AG Grid — a powerful data grid component that gives spreadsheet-like filtering, sorting, and editing in the browser. Perfect for managing thousands of leads.
- Celery with Redis — background task processing for Python. Bulk imports of 50,000 leads happen in the background without blocking the web interface.

What surprised me:

Switching from JavaScript to Python was way easier than expected. The concepts are identical — routes, middleware, database queries, authentication. The syntax is different but Claude handles both languages equally well. My prompts did not change at all. "Add an endpoint that returns leads filtered by status" works whether the backend is Express or FastAPI.

AInurturingPortal — An internal tool for managing nurturing email sequences. Users configure multi-step email campaigns that send automatically based on time delays and recipient behavior. Built with Next.js and PostgreSQL. Nothing groundbreaking technically, but it solved a real workflow problem at work.

RT Helper — A real-time automation tool powered by n8n workflows. It monitors incoming data (webhook events, email responses, tracking data) and triggers automated actions — updating spreadsheets, sending notifications, flagging issues. Runs on the same Hetzner server as the SMTPCloud backend. This tool is the invisible workhorse that connects many of my other systems.

Job Hunter Bot — A personal project I built when a friend was job hunting. It scrapes job listing sites, filters results based on criteria (location, salary range, keywords), and sends daily digest emails with new matching listings. Built with Node.js, runs as a cron job. Took about two sessions with Claude to build. Not pretty, but functional.

Nurturing Reports — A CSV-to-Excel reporting system. Upload raw CSV data from email campaigns, and it generates formatted Excel reports with charts, summaries, and trend analysis. FastAPI backend, Next.js frontend, containerized with Docker. Runs on the AWS server alongside Quality Monitoring. The QA team uses it weekly for client reporting.

The pattern across all projects

Looking across everything I have built, the pattern is always the same:

1. A real problem — not a tutorial exercise, not a portfolio project for show, a genuine frustration or need.
2. A first conversation with Claude — describing the problem, the desired solution, and the tech stack. Starting with the simplest possible version.
3. Iterative building — one feature at a time, testing after each change, fixing bugs as they appear.
4. Gradual complexity — the first version is always simple. Features get added over weeks and months as I discover what is needed.
5. Deployment — getting it on a server where people can actually use it.
6. Real-world feedback — users find problems I never imagined. Fix them. Add features they request.

Every project made me better at the next one. Not because I memorized more syntax, but because I got better at thinking about architecture, anticipating edge cases, and communicating clearly with Claude. CampaignPulse taught me web basics. Quality Monitoring taught me enterprise patterns. SMTPCloud taught me SaaS architecture. MyVaultKeep taught me about handling real money. VaultKeep taught me mobile.

The progression is natural. Each project pushes you slightly beyond what you know. And by the time you are done, you know more than you did. That compound effect, over 20+ projects, is how someone with zero programming background ends up running 5 production servers with 44,000+ lines of code. There is no shortcut and no secret. Just real problems, clear communication, and relentless iteration.