First commit. ✅ It's just code right now. But this is the foundation of something I've been thinking about for a while.

Teaching AI agents to run my business workflows. Search the web. Query databases. Send emails. Process payments. All on their own. Not using no-code tools. Pure Python, real APIs, actual database. Each agent has memory, tools, and knows when to call another agent. Just starting...

Completed ✅ — built the full money stack Stripe handles payments with two products set up — monthly retainer ($500 recurring) and setup fee ($1,500 one-time). Both checkout flows tested with the test cards, success and decline paths. n8n webhook pipeline listens to three Stripe events: checkout.session.completed, invoice.paid, and customer.subscription.deleted. Each one routes to its own branch — new client gets inserted into Supabase, recurring payment gets logged, cancellation updates the client status automatically. Also wired a Tally form webhook so inbound leads land in a leads table the moment someone submits. Supabase holds four tables: payments, clients, leads, and agent_sessions. React dashboard (Vite + Supabase JS) pulls everything together — total revenue, active clients, lead funnel by status, recent payments window, and a data sources health check so you can see at a glance if any table has stopped receiving data. You can update lead and client statuses directly from the UI with a confirm modal before anything gets saved in supabase. Also.. Git — everything committed and pushed. Quick note on the emails — in the test I'm playing both the client and the seller so both alerts land in my inbox. In real life those go to two different people, the automation is working correctly. Test worked end to end: Post → checkout link → 4242 4242 4242 4242 → webhook fired → n8n processed → Supabase stored → email alert sent → dashboard updated. Where this could scale: The schema already has agent_sessions for when AI runs start getting logged. The Tally → n8n → leads flow can extend into a full nurture sequence (email drip, Calendly booking, auto proposal) without touching the dashboard code. Is it perfect? Definitely not. There are rough edges and things I'd clean up. But the point was to build something scalable and learn the stack — and that part worked. Good challenge.

Security-First Architecture ✅ (+ Boss Level) Built secure foundations BEFORE writing more features. .env.agents single source of truth, 4-tier credential hierarchy, and a wrapper script that keeps MCP configs public-safe. Tier hierarchy (treat them differently or you'll mix them up) 🔴 Tier 1 Critical — Supabase service_role, Stripe secret → rotate immediately 🟠 Tier 2 Sensitive — n8n tokens, admin access tokens → rotate within 24h 🟡 Tier 3 Restricted — anon keys, scoped API keys → weekly/monthly 🟢 Tier 4 Public — URLs, doc links → commit-safe Challenge deliverables • .env.agents with 7 credentials grouped by tier (gitignored, mode 600) • .env.agents.example committed as template with tier sections • .gitignore widened to .env* with !*.example exceptions — future env files caught automatically • Git history grep: clean across 4 git repos audited Boss Level — secure MCP wrapper (+300 XP) scripts/secure-mcp-wrapper.sh reads .env.agents at runtime then execs the MCP server. Refuses to start if .env.agents is missing (fail loud), warns if perms aren't 600. Result: .mcp.json contains zero secrets — safe to commit, safe to screenshot. Engineering note (the bug I caught while writing the wrapper) First version used `source <(grep ... ENV_FILE)` to strip comments. `set -a` exports didn't propagate through process substitution, so vars came out empty in the child process. Fix: bash handles # comments natively on source — drop the grep filter, source the file directly. Verified 31-char key load. Takeaway Security-first isn't security-only. It's making sure the boring infrastructure (where secrets live, how they get loaded, who can read them) is correct BEFORE you add the exciting features. 30 minutes of setup now > one Friday-night incident response later. #SecurityFirst #EnvAgents #RLSEnabled

First API Script ✅ Built a Python script that talks to JSONPlaceholder: lists every post, creates a new one, and handles failures gracefully. What it does GET all posts → prints the count using len() POST a new post with my name as title → prints status code + new id try/except with friendly messages for timeouts, connection errors, HTTP errors Bonus: f-strings everywhere + a list comprehension for the first 3 titles Real output Total posts on JSONPlaceholder: 100 First three titles: ['sunt aut facere repellat...', 'qui est esse', 'ea molestias quasi...'] POST status code: 201 New post id: 101 New post title echoed: 'Alex' Real failure mode (bonus story) The API went down for a few hours yesterday. My script caught it cleanly: Request took too long — check your connection and try again. That's the whole point of try/except — your script doesn't crash when reality misbehaves. Better proof than any mocked timeout. Takeaway 201 Created returns the new resource (so you get the id back). len() on a JSON array gives you the count without parsing. f-strings beat .format() for readability. Specific exception classes beat a bare except: because they tell you what went wrong.