Share

Episode 009: Building Community (What Actually Happened)

Building in public means showing the real numbers, the experiments that didn’t work, and the pivots that emerged from doing the work. This episode covers:

- The honest numbers: 131 followers, 61 subscribers (not the 100 I targeted)

- The workshop experiment that didn’t go as planned

- The repositioning insight: expert rapid builder vs. teacher of vibe coding

- How I use Claude to plan, strategize, and iterate on content

- The prompts and process behind AI-assisted content creation

- What’s coming in Season 2

Current projects mentioned:

- uPoll.live — course engagement platform, university pilot

- BuildWith — builder/client marketplace

- QueryBase — writers’ SaaS for share agent database to use as a querying and research platform

- Landing page/lead magnet tool (in development)

The repositioning:

I can validate your business idea in 14 days. The opportunity cost of waiting is real. That’s the offer.

Get involved:

- What do you want Season 2 to cover?

- What tools would help your work?

- Reply, comment, or DM — the community shapes what comes next.

Subscribe: g8n.ai/subscribe

Share

You’ve read about vibe coding. You’ve seen what’s possible. You’re curious.

But you haven’t actually built anything yet.

That’s fine. Everyone starts somewhere. This is the guide I wish I had when I started—not theory, not philosophy, just what to do on Day 1 and every day after.

By the end of seven days, you’ll have shipped something real. Something you use. Something that proves to yourself that you can do this.

Let’s go.

Before You Start: The Only Tool You Need

Forget the complicated setups. Forget the YouTube tutorials about “the perfect AI stack.” You need one thing:

An AI assistant you can have a conversation with.

I recommend Claude. Not because it’s the only option—but because it specifically handles the things that matter for building: complex multi-file work, database design with security considerations, payment integrations, real-time architecture, and maintaining context across long sessions. The entire BuildWith marketplace I’ll show you later was built with Claude.

Which tier matters:

Pro: $20/mo - minimum for serious building

Max: $100/mo - recommended for production projects

Max+: $200/mo - heavy AI leverage, multiple projects

If you’re just starting, Pro is fine. If you’re building something real that you plan to deploy, Max is worth it. One subscription handles everything from ideation to deployment.

Free tiers work for your first experiments. But when you’re ready to build something production-grade, the paid tiers are where the capability lives.

Share G8N•AI

Day 1: Pick Your First Problem

Don’t start with “I want to build an app.”

Start with: “What do I do manually that annoys me?”

Look for something you do at least once a week. Something repetitive. Something that makes you think “there has to be a better way.”

Good first projects:

• A checklist you recreate every week

• A template you fill out repeatedly

• A calculation you do by hand

• Information you look up over and over

• A reminder system that doesn’t exist yet

Bad first projects:

• “An app like Uber but for...”

• Anything involving payments - save this for later, unless you have guidance or already know what you are doing when it comes to this

• Anything involving user accounts - save this for later, unless you can easily integrate an auth & auth solution - and if you don’t know what that is, you probably can’t

• Anything you’d need other people to use immediately

The goal for Day 1: Write one sentence describing your problem.

Not the solution. The problem.

“I waste 20 minutes every Monday creating the same meeting agenda template.”

“I can never remember which client prefers email versus Slack.”

“I manually calculate my freelance project profitability every month and I always mess up the formula.”

That sentence is your foundation. Everything else builds from there.

Spend the rest of the day, or however long you feel you need, putting together what you want in terms of features, workflows, journeys - however you want to think of your problems and what would work to solve them.

Leave a comment

Day 2: Describe What “Done” Looks Like

Open Claude (or your AI of choice). Start a new conversation. Paste your problem sentence. Then add:

“I want to solve this. What would a simple solution look like?”

Don’t accept the first answer. Push back. Ask questions. Have a conversation. Use the rest of the material and context you thought through on Day 1 and have the AI challenge your thinking, your approach, your assumptions, and your level of understanding.

The AI will probably suggest something too complicated. That’s fine. Say: “That’s too complex for a first version. What’s the simplest thing that would actually solve my problem?”

Keep going until you can describe “done” in one sentence.

“A single-page checklist that I can reset with one click.”

“A simple lookup tool where I type a client name and it shows their communication preference.”

“A calculator where I input hours, rate, and expenses and it shows my actual profit.”

The goal for Day 2: Write one sentence describing what the finished thing does.

Not how it works. What it really does, and how that ties back to solving your problem.

Day 3: Build the Ugly Version

Today you build. And it will be ugly. That’s the point.

Go back to your AI conversation. Say: “Help me build this. I want the simplest possible version that works.” Start from there, and don’t worry, you haven’t lost all that other context you’ve given it, because with memory capabilities and Claude Projects, you can have the AI review your other chats and any files you attach to your Claude Project. So for now, build the minimum viable solution to your specific problem.

If you’re comfortable with code or the terminal, at least, the AI can write it for you and you can stick with my recommendation of using Claude Code in the terminal. If you’re not, ask for a no-code approach—there are visual builders like Notion, Airtable, or Google Sheets that can handle simple tools.

For something more interactive, try one of these visual AI builders:

• Replit — Good for code-based builds with AI assistance, and the one I actually recommend, pay for and use regularly for products, including uPoll, which is continuing to be piloted at UTA, with new updates, bugfixes and feature improvements almost every day (usually via Claude Code, even if we still deploy via Replit before shifting to our production systems).

• Lovable (lovable.dev) — Builds React apps from descriptions

• Bolt (bolt.new) — Similar, builds full applications

Don’t worry about picking the “right” tool. Pick one and start.

You will hit errors. Things won’t work. This is normal.

Remember: Generate → Lint → Fix → Test → Fix → Repeat.

That’s not failure, that’s the actual workflow. I go deeper on this in the workshop - more on that below!

When errors happen:

1. Copy the error message

2. Paste it to your AI

3. Say: “I got this error. What went wrong?”

The AI will explain and suggest a fix. Try the fix. If it doesn’t work, tell the AI what happened. Keep going.

The goal for Day 3: Have something that works, even if it’s ugly.

“Works” means it does the thing you described on Day 2. Not perfectly. Not beautifully. It just does the thing.

Maybe you've already tried building something. Maybe you hit a wall—Bubble couldn't do what you needed, the AI output was garbage, the whole thing fell apart. That's actually a good sign. You've validated that the problem matters. Now you need a better approach.

Subscribe now

Day 4: Use It For Real

Today, no building. Today, you use the thing you made.

This sounds obvious. It’s not. Most people build something and then never actually use it. They move on to the next idea.

Don’t do that.

Use your tool for its intended purpose. If it’s a checklist, run through the checklist. If it’s a calculator, calculate something real. If it’s a lookup tool, look something up.

While you use it, notice what’s annoying. What’s missing. What’s confusing.

The goal for Day 4: A list of 3-5 things that bug you about your own tool.

Write them down. These become tomorrow’s improvements.

Day 5: Fix One Thing

Pick the most annoying item from your list. Just one.

Go back to your AI conversation (or start a new one with context about what you built). Describe the problem: “When I use this, [X] is annoying because [Y]. How do I fix it?”

Fix that one thing. Test it. Make sure it works.

Don’t fix everything. Just one thing.

The goal for Day 5: Your tool is slightly better than yesterday.

This is iteration. This is how real software gets built. Not in one perfect session, but through repeated small improvements, and a short feedback loop: test, track, iterate.

Day 6: Make It Accessible

Your tool works. You’ve used it. You’ve improved it. Now make sure you can actually get to it when you need it.

If it’s a web page, bookmark it.

If it’s a spreadsheet, pin it to your home screen.

If it’s code running locally, figure out how to launch it easily.

The best tool in the world is useless if you forget it exists. Make access effortless.

The goal for Day 6: You can open your tool in under 5 seconds. Optionally (though I always do it), make it so that you can easily deploy/update it. You want to be able to spot an improvement or bug, get a fix in place with the help of AI, and push it out to test/validate that it did in fact get fixed as quickly as possible.

Day 7: Reflect and Decide

You built something. You used it. You improved it.

Now ask yourself two questions:

1. Did this solve the problem I started with?

If yes, great. You have a tool. Keep using it. Keep improving it when things bug you.

If no, that’s valuable too. You learned something about what the problem actually is. That’s progress.

2. Do I want to keep building?

Some people do this once and they’re satisfied. Problem solved, move on.

Some people get hooked. They start seeing problems everywhere that could be solved the same way. They want to build more.

Both are valid. But if you’re in the second camp, you just discovered something important about yourself. As always, I delve deeper into this during the workshop, which I give details on below.

Share G8N•AI

What You’ve Proven

In seven days, you went from “I’ve never built anything” to “I built a thing and I use it.”

That’s not a small thing. Most people never do it.

You proved you can:

• Identify a real problem

• Describe a solution

• Work with AI to build it

• Handle the debug cycle (it’s normal, not failure)

• Use it and improve it

• Make it part of your workflow

The next build will be faster. You’ll know the rhythm. You’ll trust the process.

And the build after that will be faster still.

Key Takeaways

Five things to remember:

1. AI accelerates, doesn’t replace. You still need to understand the patterns. The judgment is yours.

2. Security first. Even for simple tools, think about who can access what. For production apps: authentication, input validation, access controls.

3. Debugging is normal. The Generate → Fix → Test → Repeat cycle isn’t a sign of problems. It’s how this works.

4. One tool, full stack. Claude handles planning, design, frontend, backend, devops, testing. You don’t need to learn five different tools.

5. Cost-effective leverage. $100/month for capabilities that would require a team. That’s the new reality.

   Subscribe now

What’s Next

If you want to keep going, here’s the pattern:

Week 2: Build something slightly more ambitious. Two features instead of one. A little more complexity.

Week 3: Build something you’ll share with one other person. A friend, a colleague. Get feedback from someone who isn’t you.

Week 4: Build something that solves a problem for someone else entirely.

Each week, you expand the scope slightly. You stretch into new territory. You learn what you don’t know.

That’s the whole game. Repeat until you’re building things you never thought possible.

And, if you go through this and find that building, while enabling you, takes too much time by yourself, or you aren’t willing to go through the trouble without guidance, you can always build with me during the workshop—details below!

What This Looks Like With Experience: The BuildWith Story

A couple of days ago, I built BuildWith: a two-sided marketplace connecting AI builders with clients. Production-ready with payments, messaging, security scanning. In a single day.

Here’s the honest truth: This is what 20 years of software engineering plus 3 years of building with AI looks like. Experience compounds. I’m not one or two steps ahead of someone starting out, I’m 10 or 20 steps ahead. And it’s crazy how much leverage AI can give you - I’ve built more apps in the last 12 months than I have in the previous 12 years!

But that’s the point. When you start doing this and build this leverage and learn these patterns, you can get here too. What I did in a single day, you can sustainably do in a week. And it’s only going to get faster and better as AI improves and the intelligence infrastructure - the pipelines, the capabilities - keep advancing.

Here’s what actually happened:

The Numbers

Commits: 28

TypeScript Files: 144

Database Tables: 10

Supabase Migrations: 24

E2E Test Suites: 7

Unit Test Files: 3

Build Time: Single Day

Subscribe now

Phase 1: Foundation (Before Any Features)

Before writing any code, I created a dedicated Claude Project using the Claude MacOS desktop client, and I used the first chat thread to describe what I wanted to build, and had it do deep research on competitors, features, roadmaps, as well as to come up with appropriate Claude Project instructions for the project. I update the project instructions with the results after some review and fine-tuning, then started a new chat and started having a conversation with Claude to figure out the plan, design, things I wanted in the MVP, strategy for building, etc. I ended up manually creating the initial code project directory with a CLAUDE.md file, which serve as persistent instructions that guide every conversation in Claude Code, the terminal-based interface I used in this case for the actual development of the marketplace.

NOTE: You don't need to understand this file in its entirety. The point is: I documented the patterns I wanted Claude Code to follow, so every conversation started with shared understanding. Now, here's what that looks like:

# CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

## Project Overview

BuildWith is a two-sided marketplace connecting AI/vibe coders (Builders) with clients seeking custom builds, template personalization, and repo customization. Deployed at buildwith.g8n.ai.

## Commands

```bash
npm run dev      # Start development server (localhost:3000)
npm run build    # Production build
npm run lint     # Run ESLint
```

## Tech Stack

- **Framework**: Next.js 16 (App Router), React 19, TypeScript strict mode
- **Database**: Supabase PostgreSQL with Row Level Security
- **Auth**: Clerk (Google, GitHub, LinkedIn, email)
- **Payments**: Stripe Connect Express (milestone-based escrow)
- **Realtime**: Supabase Realtime (messaging, notifications)
- **Styling**: Tailwind CSS v4 + shadcn/ui
- **State**: TanStack React Query for client-side data fetching
- **Forms**: React Hook Form + Zod resolver

## Architecture

### Route Groups
- `(auth)` - Authentication pages (sign-in, sign-up, onboarding)
- `(dashboard)` - Protected dashboard with role-based navigation
  - `/client/*` - Client features (post projects, manage applications, milestones)
  - `/builder/*` - Builder features (browse projects, listings, applications, earnings)
- `(marketing)` - Public marketing pages
- `/builders/[id]` - Public builder profile pages

### Supabase Integration
- **Server**: `createSupabaseServerClient()` from `@/lib/supabase/server` - uses Clerk JWT via `auth().getToken()`
- **Client**: `useSupabase()` hook from `@/lib/supabase/client` - uses Clerk session token
- **Admin**: `createSupabaseAdminClient()` from `@/lib/supabase/admin` - bypasses RLS for system operations
- **Types**: Manual types in `@/types/database.ts`

### Server Actions Pattern
Located in `src/app/actions/`:
- `builder.ts` - Builder profile, listings, applications
- `project.ts` - CRUD for projects, application accept/reject
- `milestone.ts` - Milestone management and payment flow

All server actions follow this pattern:
```typescript
type ActionResult<T = void> =
  | { success: true; data?: T }
  | { success: false; error: string };

export async function actionName(input: Input): Promise<ActionResult> {
  // 1. Auth check via auth() from Clerk
  const { userId } = await auth();
  if (!userId) return { success: false, error: "Unauthorized" };

  // 2. Zod validation
  const validated = schema.safeParse(input);
  if (!validated.success) return { success: false, error: validated.error.errors[0].message };

  // 3. Supabase operation with RLS
  const supabase = await createSupabaseServerClient();
  // ... operation

  // 4. Cache invalidation
  revalidatePath("/path");
  return { success: true, data: result };
}
```

### Validation Schemas
Located in `src/lib/validations/`:
- `builder.ts` - Profile, service listings, applications, filters
- Schemas defined in server action files for project/milestone operations

### User Roles
Three roles stored in `profiles.user_type`: `client`, `builder`, `admin`
- Role hooks in `@/lib/clerk/hooks.ts`: `useUserRole()`, `useIsBuilder()`, `useIsClient()`
- Dashboard sidebar in `@/components/layout/dashboard-sidebar.tsx` auto-switches navigation based on role

## Code Conventions

- TypeScript strict mode, avoid `any` types
- Zod schemas for all input validation
- Server Components by default, `"use client"` only when needed
- Named exports only (no default exports)
- Mobile-first Tailwind classes
- Use React Query for client-side data fetching with `useSupabase()` hook

## Database Tables

| Table          | Purpose                                          |
|----------------|--------------------------------------------------|
| profiles       | User data, linked to Clerk ID                    |
| projects       | Client project postings                          |
| applications   | Builder proposals for projects                   |
| milestones     | Payment stages with escrow status                |
| services       | Builder service listings                         |
| conversations  | Chat threads                                     |
| messages       | Individual messages                              |
| reviews        | Bidirectional ratings                            |
| notifications  | User notifications                               |
| security_scans | Snyk vulnerability scan results for deliverables |

## Security Requirements

- RLS policies on ALL Supabase tables
- Auth check at data layer (server actions), not just middleware
- Validate all inputs with Zod before database operations
- Verify Stripe webhook signatures
- User can only access their own data (enforced by RLS using `auth.jwt()->>'sub'`)

## Supabase Migrations

Migrations stored in `supabase/migrations/`. Apply via:
```bash
# Using Supabase MCP (preferred)
mcp__supabase__apply_migration

# Using CLI
npx supabase db push
```

This isn’t just documentation—it’s instructions that shape how Claude Code understands and extends the codebase. Every conversation started by reading it.

And this shape of the CLAUDE.md file? It’ll change by tomorrow, when I spend another day on it, making updates from feedback and piloting users, online research around the features and capabilities available in similar or competing marketplaces, safety and compliance checks, performance updates, or data gathered from folks helping me to test and iterate and improve this builder/client marketplace so that we can put together a template, if not a complete solution.

The template could serve as the basis for future workshops where we focus on clients getting to personalize and build their own marketplace rapidly using a pre-existing structure and minimum set of features.

Share

Phase 2: Core Features

Once the foundation was solid:

• Project posting and browsing

• Builder applications with proposals

• Milestone system with escrow tracking

• Real-time messaging

• Notification system

Phase 3: Design System

One significant commit overhauled the entire UI:

• Dark-first luxury aesthetic

• 760+ lines of CSS custom properties

• Theme switching (dark/light/system)

• Glassmorphism, mesh gradients, glow effects

Phase 4: Payments

• Stripe Connect Express for builder payouts

• Webhook handlers for all async events

• Escrow pattern (happy path complete, rejection path under design):

  • Client funds →

    • Status “funded” →

      • Builder delivers →

        • Client approves →

          • Transfer to builder (85%) + Platform fee (15%)

        • Client rejects (TBD, still reviewing what works best here) →

          • Feedback gathered and submitted back to Builder for Revision

          • Revisions negotiated between builder and client prior to escrow process

          • Client can opt for project/contract dismissal

            • 25% cancellation fee charged to client from current milestone price for 15% platform fee and 10% builder compensation regardless of dismissal.

            • Any milestones previously hit by builder will already have been awarded/paid out and had the platform fee collected, thus will not be refunded to client.

          • Delivered content for current milestone locked out to client after gathering feedback.

          • All deliveries to client from prior milestones will remain available to them, as that portion of the transaction is already paid out and considered complete.

Refer a friend

Phase 5: Security & DevOps

• Snyk integration for dependency scanning

• Security scanning on builder deliverables

• CI/CD pipeline with GitHub Actions

• Rate limiting middleware

Phase 6: QA & Fixes

Multiple commits fixing TypeScript errors, ESLint warnings, test selectors, formatting. This phase is important to understand:

The real workflow is: Generate → Lint → Fix → Test → Fix → Repeat.

AI doesn’t produce perfect code on the first pass. The git history shows fixes for strict null checks, type mismatches, unused imports, build-time vs runtime errors. This is normal. This is expected. The debugging cycle is part of the process, not a sign something went wrong.

The Cost

Claude Max: $100 per month

Vercel: Hobby Free

Supabase: Free tier - $0

Clerk Free: 10K MAUs - $0

Sentry (if you want to go that route instead of keeping it simpler up front): Free - 5K errors - $0

Total: $100/mo

$100/month for capabilities that would take a team. That’s the leverage.

Give a gift subscription

Why This Matters For You

The 7-day framework I supplied you with above is the sustainable version of what I compressed into one day for folks who don’t do this regularly. The speed came from experience with these patterns—patterns you’ll learn by doing.

What’s possible: BuildWith in a single day.

What’s sustainable for newcomers: The same quality in a week.

The gap closes faster than you think. And every month, AI gets better. The intelligence infrastructure improves. What takes a week today might take two days next year.

Workshop: Build With Me

I’m running a live workshop on Sunday, January 25th.

Three hours. Three spots. Everyone walks out with a working frontend prototype.

The goal isn’t to watch me talk. The goal is to build. I’ll walk through my exact process—the same approach behind uPoll, UltraPost, BuildWith, and everything else. Then we build together. You work on your project, I provide guidance and troubleshooting in real-time.

Investment: Normally $997. First run: $249.

Why the discount? I want three people who are serious about building, and I want to refine the format and the framework I’m putting together. You get a deal. I get proof. We both win.

I’m qualifying by project scope. Three hours is enough to get a working prototype if the scope is right. If your idea is too big, we won’t hit that goal, and I’d rather say no upfront than have you walk away frustrated.

Interested? Reply to this email or DM me with your project idea. I’ll tell you if it fits.

Next up: “Why Owning Your Tools Matters More Than Saving Money”—the real reason I build my own software. Subscribe so you don’t miss it.

Notes / Links

• The Vibe Coding Playbook: How I Actually Build -

• What Vibe Coding Actually Is -

• Software Sovereignty post: What If You Owned Your Tools Instead of Renting Them? -

Visual builders mentioned:

• Replit

• Lovable

• Bolt

AI recommendation:

• Claude Subscription

  • Pro $20/mo - minimum. Good enough for most people who are solving small pain points and first beginning to leverage AI to build things.

  • Max $100/mo - recommended. For folks serious about continuing beyond the prototypes and single-person artifacts they are putting together and getting comfortable building.

  • Max $200/mo - serious for heavy AI use. This option is for if you’re going to be full time on a project or building out your brand/business and willing to learn about and leverage multiple agents running in parallel or across multiple projects for you.

Projects mentioned:

• BuildWith — buildwith.g8n.ai

• uPoll — upoll.live

• UltraPost — ultrapost.g8n.ai

Share

I've shipped more in the last 12 months than in the previous 12 years.

A course engagement platform piloting at a university. A LinkedIn tool in beta. Games I'm building with my kids. Custom tools I'm building in public with peers.

All of it built the same way: describing what I want, iterating until it works, and applying judgment throughout.

Last week I wrote about what vibe coding actually is.

Today I'm sharing the exact system; including where it falls apart.

The Three Pillars

Pillar 1: Start With a Clear Outcome, Not a Feature List

AI can't read your mind. It doesn't know what "good" looks like for your specific situation.

Before I open any tool, I write one sentence describing what success looks like. Not a feature list. Not a technical specification. One sentence about the outcome.

When I started building uPoll, the sentence was: "A system where professors can broadcast questions to students in real-time and see responses instantly."

That clarity shaped every decision. When features got suggested that didn't serve that outcome, I said no. When I got stuck, I returned to that sentence to figure out what actually mattered.

The discipline isn't technical. It's knowing what you're building before you start building it.

Tactical takeaway: Before your next build, write one sentence.

"A tool that does [X] so that [Y] happens."

If you can't write that sentence, you're not ready to build yet.

Share G8N•AI

Pillar 2: Treat AI as a Collaborator, Not a Vending Machine

The critics who say vibe coding produces garbage aren't entirely wrong. If you treat AI like a vending machine - insert prompt, receive code, deploy without thinking - you'll get exactly what they describe.

That's not how this works.

AI handles the grunt work. I handle the judgment. Every suggestion gets reviewed. Every output gets tested. When something doesn't make sense, I ask why. When something breaks, I understand the failure before accepting a fix.

The split is roughly 70/30. AI generates 70% of the volume. I provide 30% of the direction, review, and decision-making.

That 30% is where the value lives.

When uPoll's context window filled up during a complex feature, Claude suggested pagination. Technically correct. But pagination would have broken the real-time experience that was the whole point. I had to recognize that and redirect.

AI gave me options. I made the choice. That's collaboration.

Simon Willison said it better than I could: "I won't commit any code to my repository if I couldn't explain exactly what it does to somebody else."

That's the line. Cross it, and vibe coding becomes the mess the critics describe. Stay on this side, and you have leverage.

Tactical takeaway: Before accepting any AI-generated code, ask: "Can I explain what this does?"

If no, don't ship it. Ask the AI to explain. Or simplify until you can.

Subscribe now

Pillar 3: Iterate Relentlessly, Ship Imperfectly

uPoll.live didn't ship polished. It shipped functional. The polish came from iteration.

The first version worked. Barely. Students could answer questions and professors could see responses. That was the core loop.

Then came testing. Real professors. Real students. Real problems I hadn't anticipated. One professor needed anonymous responses. Another needed response timing. A third found an edge case that crashed the whole thing.

Every problem became a conversation with AI. Every fix made the tool better. Three hundred hours of iteration later, it was polished enough for a university to trust it.

Here's what most people get wrong: they think shipping early means shipping garbage. It doesn't. It means shipping the smallest thing that proves the concept, then improving it based on reality.

The games I'm building with my kids started the same way. Simple. Barely functional. We played them, found what was fun and what wasn't, iterated. Now they're actually good.

Tactical takeaway: Your first version should be embarrassingly simple. Ship it anyway. The feedback will tell you what actually matters.

Leave a comment

Your First Week Building With AI

If you've never built anything with AI, here's how to start:

Days 1-2: One small automation.
Pick something you do manually at least once a week. A form you fill out. A report you compile. A message you send. Use AI to automate it. The goal isn't impressive. The goal is completing the loop: idea → build → ship → use.

Days 3-4: Expand slightly.
Take that automation and add one feature. Or fix something that annoyed you. The goal is learning how to iterate. You'll hit errors. That's fine. The errors teach you how the system thinks.

Days 5-7: Build something you'll actually use daily.
Now you've got the pattern. Pick something you'll use every day. A dashboard. A tracker. A tool that scratches your itch. Something small enough to finish in a few sessions but useful enough that you'll actually open it.

Tools to start with:
- Claude or ChatGPT for the conversation
- A visual builder like Google AI Studio, Replit, Lovable, or Bolt for the interface
- That's it. You can get sophisticated later.

Where It All Breaks Down

I'm not going to pretend this works for everything. It doesn't. Here's where vibe coding hits its limits:

Context limits: Long conversations lose coherence. The AI forgets earlier decisions. You get contradictory suggestions. The solution: break complex builds into smaller sessions with clear handoffs. Document your decisions outside the chat.

Complex debugging: When systems get interconnected, AI guesses can make things worse. One "fix" creates two new bugs. The solution: isolate the problem first. Strip away complexity until you can see what's actually broken.

Anything with real consequences: Payments. Authentication. Security. Data you can't afford to lose. The solution: prototype with vibe coding, but slow down for production. Understand what you're deploying when the stakes are real.

The solution isn't to avoid vibe coding. It's to use it appropriately. Prototype fast. Iterate freely. Then slow down when it matters.

Beyond Code: Building With AI as a Thinking Partner

Here's something I didn't expect when I started: AI isn't just useful for code. It's useful for thinking through problems.

The content strategy for this newsletter? Developed in conversation with Claude. The episode planning for the podcast? Same thing. The positioning for my services? Refined across multiple sessions.

I'm not accepting everything AI suggests. I'm challenging it, pushing back, using my judgment. But having something to react to is faster than staring at a blank page.

The 70/30 split applies to business building, not just coding. AI generates ideas and options. I decide what's actually right for my situation.

Share G8N•AI

What I'm Building Now

Here's where I'm at:

uPoll.live: Live, piloting at University of Texas at Arlington. Real professor using it with real students. The iteration continues.

UltraPost: In beta at ultrapost.g8n.ai. A LinkedIn content generation and scheduling tool built on these same principles. Testing with early users now.

Custom client tools: Building in public with peers who want their own solutions. More on this soon.

Games with my kids: Not for distribution, just for fun. But the process is identical.

And this whole thing: the newsletter, the podcast, the content machine. It’s a demonstration of what's possible when you approach AI as a collaborator.

Share

Workshop: Build Your First Prototype With Me

I'm running a live workshop on Sunday, January 25th.

Three hours. Three spots. Everyone walks out with a working frontend prototype.

The goal isn't to watch me talk. The goal is to build. I'll walk through my exact process - the same approach behind uPoll, UltraPost, and everything else. Then we build together. You work on your project, I provide guidance and troubleshooting in real-time.

Investment: Normally $997. First run: $249.

Why the discount? I want three people who are serious about building, and I want to prove this format works. You get a deal. I get proof. We both win.

I'm qualifying by project scope. Three hours is enough to get a working prototype if the scope is right. If your idea is too big, we won't hit that goal, and I'd rather say no upfront than have you walk away frustrated.

Interested? Reply to this email/post or DM me with your project idea. I'll tell you if it fits.

Next up: "Your First Week Building With AI" — a detailed walkthrough for complete beginners. Subscribe so you don't miss it!

Share

The barrier to building serious software has collapsed. This episode covers:

• Why most people who could build with AI don’t (hint: it’s not technical)

• What vibe coding actually requires: clarity, discipline, iteration

• Proof that this approach builds production software, not toys

• How Software Sovereignty and the citizen developer mindset connect

• What’s coming in 2026 with agentic AI and agentic workflows

Links referenced:

• “What If You Owned Your Tools Instead of Renting Them?” — https://www.g8n.ai/p/what-if-you-owned-your-tools-instead

• “What Vibe Coding Actually Is (And Why Both Camps Are Wrong)” — https://www.g8n.ai/p/what-vibe-coding-actually-is

Projects mentioned:

• uPoll.live — 300+ hours, university pilot, course engagement SaaS

• UltraPost — ultrapost.g8n.ai (in beta)

Subscribe: g8n.ai/subscribe

Share

The Real Skill Isn’t Using AI. It’s Knowing Where to Stop and Adjust.

In February 2025, Andrej Karpathy posted something that would define the year in software development.

“There’s a new kind of coding I call ‘vibe coding,’” the OpenAI co-founder wrote, “where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

He described his approach: accepting all AI suggestions without reading them, copy-pasting error messages without analysis, letting “the code grow beyond my usual comprehension.”

The response was immediate and polarized.

One camp embraced it completely. Suddenly feeds filled with people claiming anyone could build production apps overnight. No coding required. Just describe what you want and AI handles the rest.

The other camp rejected it just as forcefully. Senior engineers called it irresponsible. They pointed to security vulnerabilities, deleted databases, applications that collapsed under real usage. A study from METR found developers actually worked 19% slower with AI tools—even though those same developers believed they were faster. Before the study, developers predicted AI would speed them up by 24%. After experiencing the measured slowdown, they still believed AI had improved their productivity by 20%.

That perception gap should concern everyone.

Here’s what both camps missed: Karpathy explicitly said this approach was for “throwaway weekend projects.” Not production software. Not apps handling real users or real money. Weekend experiments where the stakes are low and the learning is high.

That context got stripped away in every hot take that followed.

Share G8N•AI

The Actual Question Nobody’s Asking

The debate over whether vibe coding is “good” or “bad” misses what matters. The real question is simpler: Where does AI help end and human judgment begin?

Simon Willison—creator of Django, one of the most widely-used web frameworks—drew the line clearly: “Vibe coding does not mean ‘using AI tools to help write code.’ It means ‘generating code with AI without caring about the code that is produced.’”

His personal rule: “I won’t commit any code to my repository if I couldn’t explain exactly what it does to somebody else.”

That’s the distinction. Not whether AI wrote the code, but whether you understand it.

If you’ve reviewed everything, tested it, and can explain what it does? That’s not vibe coding—that’s software development with better tools. If you’re accepting suggestions without reading them and hoping it works? That’s the approach Karpathy reserved for throwaway projects.

The people having success with AI building aren’t the ones who’ve figured out how to give AI complete control. They’re the ones who’ve figured out how to collaborate—when to trust AI’s output and when to question it.

Subscribe now

When to Use This Approach

Not every project deserves the same level of scrutiny. A weekend experiment is different from software handling customer data. The skill is matching your approach to the stakes.

This approach works well for:

Personal tools and games you’re building for yourself. The worst case is you waste some time if something breaks.

Prototypes where you’re testing whether an idea is worth pursuing. Speed matters more than polish. You’re trying to learn something, not ship something.

Learning projects where the goal is understanding, not production. Breaking things is part of the process.

Automation for your own workflows. Connecting tools, moving data around, simplifying repetitive tasks. Low stakes, high leverage.

This approach breaks down for:

Anything touching money. Payments, transactions, financial data. The cost of getting it wrong is too high.

Anything touching security. Authentication, authorization, user data. A Veracode analysis found 45% of AI-generated code introduced security vulnerabilities. That’s not a rounding error—that’s a pattern.

Production systems you don’t understand. If you can’t explain what the code does, you can’t debug it when it breaks. And it will break.

Code that other people depend on. When the blast radius extends beyond yourself, the standards have to go up.

The Permission You Might Need

Here’s something that took me too long to realize: you don’t need to “become a developer” to build useful things with AI.

That framing is wrong. It implies there’s a binary—either you’re a developer or you’re not, and you need to cross some threshold before you’re allowed to build.

The data suggests otherwise. According to research on vibe coding adoption, 63% of people using this approach identify as non-developers. Product managers, designers, entrepreneurs—people building functional applications without traditional engineering backgrounds.

The goal isn’t becoming an engineer. The goal is solving your problems.

What you do need: willingness to try, willingness to break things, willingness to ask questions when you’re stuck. The barrier isn’t knowledge—it’s permission.

And here’s the thing about permission: you don’t need anyone else to give it to you. You can just start.

Build something small. Something where the stakes are low and you’ll learn regardless of whether it works. See what happens. See if you like it. See if you want to keep going.

Most people who build successfully with AI didn’t start with a grand vision. They started with a small annoyance they wanted to fix. The skills compound from there.

What Comes Next

This piece was intentionally about framing. About understanding what vibe coding actually is, when it applies, and where the real skill lies.

Next week, I’ll share the actual playbook—the specific principles that guide how I build, with examples from tools I’ve shipped. The tactics work better once this framing is in place.

But here’s what I want you to take from today:

The skeptics aren’t entirely wrong. There are real risks, real failures, real reasons to be careful. Understanding those risks is part of being good at this.

The enthusiasts aren’t entirely wrong either. The barrier to building has genuinely collapsed. Things that required teams of engineers five years ago can be built by individuals now. That’s real and significant.

The skill isn’t picking a side in that debate. It’s developing judgment about when to trust AI’s output and when to verify. It’s understanding enough about what you’re building that you can catch problems before they become disasters.

That’s not magic. It’s not “just vibes.” It’s a learnable skill. And it starts with permission—permission to try, to break things, to build something even if you don’t have all the answers yet.

You’re allowed to try this.

Leave a comment

Next week: The Vibe Coding Playbook—specific principles for building with AI, with examples from tools I’ve shipped. Subscribe so you don’t miss it.

The trap you might not know you’re in

Here’s something that surprised me when I actually sat down and counted: I was paying monthly fees to eleven different software companies. Email tools, automation platforms, database services, payment processors, scheduling apps. Eleven separate bills showing up every month like clockwork.

And I don’t think I’m unusual. Most people who build anything online probably have a similar stack of monthly fees. Whether you’re running a business, creating content, or selling courses. Maybe more subscriptions than you’ve counted. Each one feels small. Twenty bucks here, fifty there. But they add up.

The thing that started bothering me wasn’t the money, though. It was the realization that I don’t actually own any of it.

Every tool I use belongs to someone else. They set the prices. They decide when to change features. They can triple their rates tomorrow, or shut down entirely, and I’d just have to deal with it. I’m renting my entire business infrastructure from companies that don’t know I exist.

I started asking myself an uncomfortable question: What would happen if any of these tools suddenly cost three times as much? What would I do?

For most of them, I didn’t have a good answer.

Share G8N•AI

What is Software Sovereignty?

I’ve started calling this idea Software Sovereignty. It’s not a common phrase, and that’s intentional. I needed a name for something I was thinking about that didn’t have good language yet. I’ve seen similar terms, such as digital sovereignty, being used at a national level in some cases, where countries are trying to be more “digitally independent” from corporate control (collaboraonline.com/blog/openmatters004).

Digital sovereignty, cyber sovereignty, technological sovereignty and data sovereignty refer to the ability to have control over your own digital destiny – the data, hardware and software that you rely on and create.

Or, as the Centre for Africa-Europe Relations puts it: the physical layer (infrastructure, technology), the code layer (standards, rules and design) and the data layer (ownership, flows and use).

from weforum.org/stories/2025/01/europe-digital-sovereignty

Software Sovereignty, in my case or the case of our brands and businesses at a more local level, means having agency over your tools, not just access to them.

It means owning your own data so you can take it anywhere. It means controlling your costs in a way that doesn’t scale against you as you grow. It means understanding your systems well enough that if something breaks, you can fix it. And it means having the freedom to change things when your needs evolve.

Here’s what Software Sovereignty is not about: being cheap. I’m not interested in penny-pinching my way through building a business. Life’s too short, and my time has value.

And here’s the other thing it’s not about: becoming a programmer. I’ve written software professionally for twenty years, so I obviously have that background. But the version of this I want to share doesn’t require you to become a developer. It requires you to stop being trapped.

This connects to something I think about a lot. I don’t wait for companies or institutions to protect my future. I build my own safety net. And renting every piece of software that runs my business means depending on companies that could pull the rug out from under me at any time.

That’s not a safety net. That’s a hope.

Subscribe now

Why this is possible now

Five years ago, if I told you to run your own tools instead of renting them, you’d need serious technical skills. You’d be reading dense documentation, learning arcane commands, troubleshooting obscure error messages. It would take months just to get something basic working. Maybe years to get comfortable.

The barrier was real. Building your own stuff required knowledge that took a long time to acquire.

AI changed that equation. Not completely (I want to be honest about this), but substantially.

Now you can describe what you want in plain English. You can say “I need to set up a system that sends automated emails when someone signs up for my list” and get back actual instructions. Specific steps. Real guidance. When something breaks, you can paste the error message into a conversation and get help understanding what went wrong.

The barrier dropped from “years of study” to “willingness to try and ask questions.”

I don’t want to oversell this. There’s still a learning curve. You’ll hit walls. You’ll get confused. Some days you’ll wonder why you didn’t just pay the monthly fee and move on with your life.

But the curve is shorter than it’s ever been. And for the first time, this option exists for people who aren’t professional developers. Not in theory. In practice.

What this looks like in practice

Let me tell you what happened when I actually tried this.

I have about 18,000 students in my online courses. They signed up through the course platform, but that platform owns the relationship. If I want to email them directly, to share updates or offer new courses or just stay connected, I need to bring them onto my own email list.

So I looked up what that would cost.

The email software most creators use would charge me somewhere between $145 and $155 per month for a list that size. That’s just for email. Add automation tools for workflows (when someone clicks this, do that), a database to track who’s interested in what, and monitoring to know if something breaks? I’m looking at $300-400 per month easily. Some people pay much more.

That’s $3,600-4,800 per year. For software I don’t own. For data I can’t fully control. For tools that could change their pricing whenever they want.

I decided not to pay it.

Instead, I spent a few days building my own system. Email sending, automation workflows, a database I control, monitoring that tells me when something goes wrong. All of it running on my own setup.

Total monthly cost: about $17. $21~25 if you add any volumes or enable backups, per Hetzner’s pricing. $32 for my specific case with my configuration and with a few more servers hosting other apps I’ve developed, and just to be transparent - but still significantly less than hundreds to thousands of dollars per month.

Let me be clear about something. This wasn’t easy. I hit obstacles. I made mistakes. The company I needed for email delivery rejected my application twice. Both times, manual rejections from actual people with no explanation. The second rejection even included “thank you for your understanding”—as if there was anything to understand when they’d told me nothing. I pushed back. Told them no, they didn’t have my understanding, and demanded an actual reason so I could address whatever the issue was. A couple of days later, they approved me. I changed nothing. They never explained. Bureaucratic friction is part of the game.

But now I have something that works. Something I own. Something that won’t suddenly cost me ten times more because a company changed their pricing tiers.

And I learned things along the way that will help me build whatever comes next.

This might not be for you

I want to be careful here. I’m not saying everyone should do this.

Some people are at a stage where the learning curve isn’t worth it. You’re in the middle of launching something, or your business is already humming along, or you genuinely don’t care about this stuff and your time is better spent elsewhere. All of that is valid.

But here’s what I do think: you should know this option exists.

Most people don’t. They assume that using business software means paying monthly fees forever. They’ve never considered that there’s an alternative. And because they don’t know, they never evaluate whether the rental makes sense or whether they’d be better off owning.

Software Sovereignty isn’t about everyone building everything themselves. It’s about having the knowledge to make a real choice. Knowing which tools make sense to rent and which ones make sense to own. Understanding the tradeoffs.

Once you see this, you can’t unsee it. Every time you sign up for a new tool with a monthly fee, you’ll find yourself asking: Could I own this instead? What would that cost me in time? What would it save me in freedom?

Sometimes you’ll decide the rental is worth it. I still rent plenty of software. But you’ll be making that choice consciously, not by default.

If you’re curious about how this works, I’m going to be sharing more of it. The thinking behind it, the actual steps, the places where I got stuck and how I got unstuck. Not as a course or a product. Just as part of building in public and showing what’s actually involved.

Follow along if you want. Ask questions if you have them. Try things if you’re ready.

Leave a comment

What Software Sovereignty really means

At the end of all this, Software Sovereignty isn’t really about software. And it’s not really about technology.

It’s about independence.

It’s about recognizing that every system you depend on but don’t control is a vulnerability. A point where someone else makes decisions that affect you. A place where you’re hoping for the best instead of building for it.

I think a lot about what it means to build your own safety net. To take ownership of outcomes even when the reasons things go wrong aren’t your fault. To have skills and systems that let you adapt when circumstances change.

Owning your tools is part of that. Not because it saves money (though it does). Not because it’s technically interesting (though it can be). But because it gives you options. Because it means one less company can hold your business hostage. Because it turns a hope into a plan.

That’s what G8N•AI is about, ultimately. Teaching agency through building. Showing that the things that feel locked away (technical skills, infrastructure, independence) are more accessible than they look.

You don’t have to become a software developer. But you can stop being trapped by software.

And that changes more than you might expect.

Share

If this resonated with you, subscribe to G8N•AI for more on building with AI, owning your tools, and creating the kind of independence that lets you focus on work that matters.

PS—I help founders replace their $400+/month SaaS stack with self-hosted tools they actually own. Two weeks. Complete setup. Training sessions so you understand what you have. You keep the savings forever.

If Kit’s 35% price hike made you wince—or if you’re just tired of feeling trapped by tools you don’t control—book a call and let’s talk about what sovereignty looks like for your business.

This is part of what I’m calling “teaching agency through building.” That’s what G8N•AI is about.

Share

Share

Share

Share

Transcription since Substack’s transcription feature is failing brilliantly:

Hello, I’m Ahad Amdani. Welcome back to Generation AI. That’s G8N.AI, where I explore practical ways to build with artificial intelligence. I’m building in public, vibe coding custom AI tools, and sharing everything I learned along the way.

This is episode two, and I’m recording this less than 24 hours after episode 1 went live. That’s not because I’m some productivity machine. It’s because I’ve built a system that makes showing up easier than not showing up. Today, I want to talk about that system and why building frictionless workflows is the single most important thing you can do if you want to create content consistently.

Here’s something I want you to understand. I don’t feel like doing this tonight. I’m tired. I had a long day. Part of me wants to just skip it. Tell myself I’ll do it tomorrow. But here’s the thing. I have set up my process so that skipping feels worse than doing it.

That’s the mindset shift. When you’re relying on motivation, you lose. Motivation is unreliable. It shows up when you don’t need it and disappears when you do.

But a system? A system works whether you feel like it or not.

Right now, recording this audio content dump takes maybe 15 to 20 minutes. Tonight’s actually took 40 minutes. I’m literally just talking into my phone. That’s it. No fancy equipment, no perfect environment, just me rambling through the ideas I want to share.

Then the AI takes over. It transcribes. It organizes. It produces a script that I can refine. All of the tedious parts, the parts that I hate are handled. What’s left is the creative work, the part that I actually enjoy.

So when I think about skipping a day, I’m thinking 15 minutes of talking versus the failure of breaking my streak. The system made that math easy.

Let me walk you through exactly how this works. This is the same process I used for episode 1, and I’m validating it again right now with episode two.

Step one, audio content dump. I open the recorder app on my phone and I just talk. No script, no outline, just the ideas I want to cover in whatever order they come out. Sometimes it’s 10 minutes, sometimes it’s 40. Doesn’t matter. The goal is to capture raw content.

Step two, transcription. I drop that audio file into NotebookLM, Google’s AI Notebook tool. It generates a transcript. It’s not perfect, but it’s good enough for the next step.

Step three, script generation. I take that transcript and I paste it into my Claude project. I spent time building detailed instructions for how I want my podcast scripts formatted: tone, structure, pacing cues, everything. Claude transforms my rambling into a coherent script with sections, transitions, and delivery notes.

Step four, refinement. I read through the script. I adjust anything that doesn’t sound like me. I practice it out loud a few times. And this is where I spend my creative energy, not on the production logistics or on uh audio style or uh things that don’t really matter to me, right?

I care about the content. I care about making it appealing and I care about spreading this knowledge. I want to make sure that the message lands.

Subscribe now

Step five, recording. Once I’m happy with the script, I record it properly. Right now, that’s still me reading into a microphone. Eventually, I’m planning to use an AI voice clone trained on my speech patterns. Either way, the recording is the easy part because all the thinking has already been done.

Step six, post-production. I run the audio through Podcastle AI to clean it up, reduce background noise, normalize levels, fix any obvious issues. Then it’s ready to publish.

Total time from idea to finished episode, 2 to 3 hours. And most of that is refinement, the work that I actually want to do. Right now, I’m still in the middle of this script, so I don’t know yet exactly how I’m going to make a bunch of changes.

For example, everything I’m saying right now isn’t scripted, but this is why I’m sharing this process in detail.

If you’re building a personal brand, if you’re trying to create content consistently, if you’re a solopreneur or a technical founder or someone who wants to share your expertise, you’ve probably struggled with the same problem I did. You know, you should be putting out content. You know it matters for your growth, but the friction is too high.

Share G8N•AI

Writing a blog post from scratch, that’s a whole afternoon. Recording and editing a podcast the traditional way, that’s a whole day. And when it takes that long, you don’t do it. You push it off. You tell yourself, “Next week, this weekend, whatever.” Anything to get out of doing it right then.

But what if it took an hour? What if the hardest parts - the organization, the editing, the production - were handled by AI? Suddenly, consistency becomes possible. Suddenly, daily content isn’t crazy. It’s just a system.

The same philosophy applies to any high-value activity you’ve been avoiding because it’s tedious. Figure out what you hate about the process, then automate that part. Keep the creative work, delegate the rest.

Let me give you a concrete example of what’s possible when you apply this thinking to tool building. I built an app called Stack Coach AI. You can check it out at stack.g8n.ai. That’s stack.g8n.ai.

It’s a Substack content creation and coaching tool. You can draft posts, get AI feedback on your writing, generate images, transcribe audio, even get monetization strategy suggestions.

Subscribe now

Here’s the thing. I built it in 3 hours. 3 hours start to finish. Front end. backend, deployment, custom domain, all of it. I used Gemini and Google AI Studio for the initial prototype. Then brought in Claude Code with Opus 4.5 to add the backend infrastructure. The tech stack includes React, TypeScript, SQLite, and it’s hosted on Vercel and Fly.io.

Now, I’m a senior developer with almost 20 years of experience. I knew the technologies involved. But even accounting for that, 3 hours to go from zero to deployed is insane. That’s the power of vibe coding with modern AI tools.

Is it production ready at scale? No, it’s a prototype. But prototypes become products. And if the prototype takes three hours, operationalizing it takes weeks, not months.

The point is the barrier to building custom solutions is collapsing. If there’s a tedious part of your process that you hate, you can probably automate it faster than you think.

I want to be clear about why I’m doing this. I believe most people are under-leveraged on AI. They’ve heard the hype. They might be scared of it. They’ve maybe played with ChatGPT a few times, but they’re not using these tools to fundamentally change how they work.

Share

And I get it. There’s a learning curve. There are legitimate concerns about safety and bias and job displacement. And I’m not dismissing any of that.

But the technology is here. It’s getting better every month. And the people who learn to use it well, the citizen developers, the builders, the ones willing to experiment, they’re going to have a massive advantage. Not because they’re smarter, because they built better systems. Frictionless systems.

And that’s what I want to help with. Education, upskilling, showing what’s possible, building tools that demonstrate the approach, creating a community of people who are figuring this out together. If that resonates with you, stick around, subscribe, share this with someone who might benefit.

For episode three, I’m going to document something fun. I mentioned I’ve been talking to my business partner about updating some stale course content we have on our company site Explainly. He was skeptical that we could refresh it efficiently.

Subscribe now

So I walked him through this exact podcast process, showed him episode one, explained the workflow, demonstrated the time savings. He’s convinced. We’re booking time to apply this approach to our educational content.

So episode three will cover that conversation, what objections came up, how I addressed them and what we’re planning to build together. It’s a real time case study in using AI to solve an actual business problem.

If you want me to vibe code a tool for you, something small, practical, something that solves a real pain point, drop a comment on this episode. Serious offer. I’ll pick one and build it live for a future episode.

That’s where we’ll leave it for today. Thank you for spending this time with me. I know there are infinite things competing for your attention.

And the fact that you chose to listen here? I don’t take that for granted.

Head over to g8n.ai for show notes and resources. That’s generation.ai and check out Stack Coach AI at stack.g8n.ai if you want to see what three hours of vibe coding looks like.

Until next time. Keep building, keep learning, keep asking good questions. Talk soon.

AI Cred: https://www.aicred.ai

Built by https://substack.com/@limitededitionjonathan in collaboration with https://substack.com/@natesnewsletter.

[/Show notes]

Post content below describes the build process, AI tooling, and prompts leveraged so that anyone could follow along

I recorded an audio dump of my brand strategy and the raw contents of the original script for this episode.

The script was refined with a Claude Project around my publication’s podcasts, whose instructions I used Claude Opus 4.5 deep research mode to create.

I subsequently used contents from the research report to re-order the script and contents in the optimal way for a podcast to convey its content, and I then edited and refined it until it fit my style and voice.

I subsequently recorded the audio for the podcast following this transcript.

Then leveraged AI sound editing software provider Podcastle.io to boost the quality of the audio recording to studio level and help remove background noise.
I also used an AI effect to auto-level the volume and remove long silences and pauses.

I then used the audio mixing and timeline tools to and make some edits and clean up places where I screwed up or had to re-state a line, and lastly exported it as an mp3 file.

Finally, I generated these infographics with NotebookLM after Gemini 3 Pro’s launch.

Nana Banana Pro’s text fidelity in image generation is pretty unparalleled. Still not completely mistake free, but I also generated from an 18m audio clip, so it was a little information dense.

Here’s a great infographic of the brand strategy for me:

And a pretty easy to consume one that’s geared a bit more client/customer-facing:

Plus the one you already saw above, showcasing the publication’s process for educating and up-skilling the new generation of digital content creators.

Transforming them into future citizen developers.

The publication’s Substack banner/header image was generated in Gemini with Nana Banana Pro, and it included the logo, so I took that portion and made proper podcast artwork and publication logo in Substack’s formats with it.

I’m sharing the prompts for each of the pieces of artwork that were generated below, and I already described the simple process for generating the infographics via NotebookLM above.

Using a single-source notebook works best in my opinion, unless you’re really compiling a lot of information from a lot of sources together.

The other thing to take note of is that while I specified a bit of detail in the initial prompts, I kept things pretty simple, and stuck with only regenerating a few times, making a decision quickly in order to get published.

It doesn’t matter if it’s rough. It doesn’t matter if you want to change it down the line - it’s easy to do, and what really matters is the content.

I personally feel my delivery’s a bit wooden some times, and sometimes a bit robotic or stilted. That’s fine - if this gets enough traction, I’ll re-record it and update the post with the higher quality recording.

In software development, there’s an old saying: Make it work, make it right, make it fast. This refers to getting it published/functional, then appropriately refactored/pretty, then optimize it and make it scale.

This iterative approach emphasizes incremental progress and quality improvement over time, ensuring functionality and correctness are prioritized before performance.

In the content creator world, there’s an alternative approach, or at least the path I’m pursuing: write intentionally, test quickly, polish relentlessly.

Share

Banner prompt:

Wide horizontal banner aesthetic. A detailed, multi-layered digital blueprint background with faint isometric grid lines. Hovering above the blueprint is a glowing, holographic 3D model of a complex, impossible architectural structure (like an Escher design). The light sources are soft gold and sapphire blue, suggesting deep focus and intellectual exploration.

Overlaying the blueprint texture, position the text:

Title in a distinguished, clean font: Shape the Present

Subtext: Leverage bespoke AI tooling to customize your business workflows and design your operation

Below the text, a button designed to look like a glowing schematic outline, containing the text: Discover G8N•AI

Detailed, schematic overlay, digital drawing style, deep depth of field. Aspect ratio 21:9

Create an on-brand logo for my Substack at https://g8n.ai/ whose short description is GenerationAI • Focus with Intention and Leverage with AI

Logo prompt:

Wow, I love that logo that’s on the top right of the one you just made. Let’s get a square image version of that 256x256 px

Podcast Artwork Prompt:

I need a 1400x1400px version of the above logo/image as well for my substack’s podcast artwork

[End of Post Content]

Share G8N•AI

[Transcription]

Hello, I’m Ahad Amdani, and welcome to Generation AI. That’s G8N dot ai, where I explore practical ways to build with artificial intelligence. I’m building in public, vibe coding custom AI tools, and sharing everything I learn along the way.

This is actually my first real episode, and I want to talk about something I’ve been thinking about a lot lately. Why custom vibe-coded tools are going to become as essential to solo builders as spreadsheets were to corporate workers.

Let me explain what I mean by that. Think about how spreadsheets work in corporate environments. People use Excel for everything. Budgets, tracking, analysis, reporting, you name it.

And sure, eventually companies move to dedicated software. They get web apps, portals, maybe something like PowerBI for visualization. But here’s the thing, people still use their spreadsheets alongside those tools because spreadsheets are flexible. They are personal. They fit the way you actually work.

Now, we’re entering a new era. More people are building personal brands. More people are starting custom businesses, growing communities, creating content. And for those people, the solopreneurs, the independent creators, the folks just getting started? The custom vibe-coded AI tool is becoming the new spreadsheet.

Subscribe now

Let me be specific about what I mean by vibe-coded. It’s using AI to build tools quickly, iteratively - based on feel rather than formal engineering processes.

You describe what you need, the AI helps you build it, and you refine as you go. It’s not about being a professional developer. It’s about becoming a citizen developer. And that’s a shift worth paying attention to.

I’ve got about 18 to 20 years of experience in software development. But when I build these vibe-coded tools, I’m not writing traditional code most of the time. I’m prompting, I’m iterating, I’m using Claude, ChatGPT, Gemini - whatever model fits the problem. Right now, I’m on the Claude Max plan.

That is $100 a month and it gives me access to Claude Code which I use constantly for development work. I also have subscriptions to Google’s AI Pro and ChatGPT. My company covers a couple of those which helps.

And honestly, I use these tools for my day job, too. So, it’s not wasted spend.

Here’s the thing, though. Even when someone outgrows vibe-coded tools when they scale up and need enterprise software: they’re not going to cancel their AI subscriptions.

They still use AI for prompting, for custom artifacts, for their personal workflows. The subscriptions stick around because the value compounds.

Share

So, if you’re starting out with $20 a month on ChatGPT or $100 on Claude, think of it as infrastructure. It’s the foundation you’ll build on for years.

If you’re building a personal a brand, growing an audience, starting a side project while still working your day job, you don’t have the budget for expensive SaaS tools.

You can’t pay $50 per user per month for every piece of software that you need. It doesn’t scale when you’re a team of one.

But here’s what you can do. You can build a custom vibe-coded solution, something specific to your workflow - your needs - for a one-time cost. Maybe it’s $3,000. Maybe it’s $5,000. But now you own it. It connects to your systems. It automates the tedious parts of your process. It lets you focus on the work that actually matters.

That is powerful. It means you can operationalize from day one without the recurring cost burden that kills so many early stage projects. And here’s the trajectory. You start with these custom tools. You grow. Eventually, you hire people and those people bring their own tooling and workflows. You graduate to more centralized systems just like companies graduated from spreadsheets to web apps. It’s a natural progression, but you have to start somewhere accessible.

Now, I want to be honest. To become a citizen developer, you need some education. You need to understand how AI tooling works. Not just surface level prompting, but how to build safety rails, how to guard against biases, how to test your outputs.

Share G8N•AI

There’s a tool I’ve been looking at called AICred. It’s an assessment that takes about an hour and it helps you understand where you are with AI literacy. What you know, what you don’t, and what you should study next. It even generates personalized learning plans. I’ll link to it in the show notes.

The point is, even if you decide you don’t want to build these tools yourself, understanding what’s possible empowers you. You can hire someone to build exactly what you need. You can evaluate what they deliver. You can make informed decisions instead of just hoping for the best.

So, here’s what I’m committing to with this podcast and this publication. I’m building everything in public.

The newsletter, the vibe-coded tools, the marketing strategies, the mistakes, all of it.

Every week I’m going to build and release a new tool. I’ll show you how I construct safety rails, how I test across different models, how I deploy - the whole process, visible.

I’ve also rebranded the publication. It was called Focus and Flow. Now it’s Generation AI, g8n.ai.

That’s G, the number eight, N, dot AI. Eight letters between G and N.

Similar to the naming style of N8N, if you’re familiar with that automation platform, it’s supposed to be pronounced node-mation (node + automation). G8N stands for generation.

Share

And I’m doing this while working my day job, learning from mentors in a couple of cohorts, and trying to grow my presence on both Substack and LinkedIn. It’s a lot, but I think that’s the point. Showing what’s actually possible. when you have the right tools and the right systems.

Here’s what I’m asking from you. If there’s a specific kind of vibe-coded tool you’d find useful, something small, practical, something that could help a lot of people?

Drop a comment, reply to the newsletter, let me know. If it’s the right fit, I might build it and demo it in a future episode.

And if any of this resonated, if you’re building your own brand, starting your own side hustle, figuring out how to work smarter with AI? Subscribe. The newsletter goes out weekly. The podcast is just getting started.

That’s where we’ll leave it for today. Thank you for spending this time with me.

I know there are infinite things competing for your attention and the fact that you chose to listen here? I don’t take that for granted.

Head over to g8n.ai for show notes and resources. That’s G8N dot AI.

Until next time: keep building, keep learning, keep asking good questions. Talk soon.

Share