We Built 15+ Apps With AI. Here’s What Actually Worked

Two years ago, neither of us would have described ourselves as software engineers. (1:48)

Since then, we have built writing tools, task managers, Chrome extensions, automated research databases, iPhone apps, websites, agent command centers, and a multiplayer game populated by squirrels.

Some projects worked. Some remain held together with the digital equivalent of duct tape. Several produced errors we still do not fully understand. It's a work in progress. We're still progressing!

But each project became easier than the last. And as we've experimented, we've gained confidence. (2:13:53)

And now we have a little bit to share to help you speed run your own AI coding journey.

See, AI coding tools can now generate enormous amounts of functional software, but opening a coding agent and saying “build my app” still produces unpredictable results. The skill is learning how to turn an idea into a plan, choose an appropriate starting point, supervise the build, and test what comes out. (3:06)

In our full livestream, we walked through more than 15 projects and reconstructed how we built them. This guide turns that conversation, plus the best questions from the live chat, into a repeatable process for anyone starting from zero.

The most important shift happens before you write code

Most people begin with a product category:

“I want to build a task manager.”

That framing immediately points you toward every feature a task manager might contain.

A better starting point is a specific moment of friction:

“When I get bombarded with Slack messages, I forget tasks. Existing apps feel too cumbersome, and gamification helps me follow through.”

That was the origin of Corey’s Circle Back task app. He needed:

• A fast place to dump thoughts
• Simple “now, soon, and later” deadlines
• Colored categories
• A running score for completed work
• Access from both his phone and computer

Those constraints led to a tool designed around one person instead of another generic productivity platform. (4:31)

Corey calls this “patching my vulnerabilities.” The best personal software often compensates for a behavior you already understand about yourself. (12:39)

The same pattern produced several other projects:

• Threadline came from forgetting articles Corey wanted to write about.
• On Deck came from the nightly “what should we eat?” stalemate.
• Bean Counter came from wanting to quantify the savings from making espresso at home. You can also see the finished app in Apple’s App Store.
• FlowState came from Grant’s frustration with writing inside existing AI interfaces.
• Sqwirl World began as an experiment to see whether an AI coding model could make a 3D dungeon crawler. You can visit Sqwirl World or play the game.

A small, specific frustration gives the AI clearer requirements. It also gives you a simple test for success: did the software make that moment less annoying?

One viewer had started in Lovable, hit roadblocks, and abandoned the project. That experience is common. A visual builder can still be useful as a sketchpad, but it does not need to become the permanent home for your project. If the tool starts fighting you, preserve the idea, export what you can, move the code into GitHub, and continue with a coding agent. (4:43)

The seven-step process we now use

1. Start with a problem you experience repeatedly

Write down the moment when the problem occurs. (1:15:42)

Avoid “I want a project-management platform.” Try:

Every morning, I collect tasks from Slack, email, and meetings. I need one place where I can add something in under five seconds, categorize it, and see what must happen today.

Include:

• Who the tool is for
• What they are trying to accomplish
• What currently goes wrong
• Which part consumes the most time or attention
• What would make the new experience noticeably better

A narrow tool that solves one real problem is a better first project than a social network, marketplace, or “all-in-one AI operating system.”

We have both attempted the last category. This advice comes from scar tissue.

2. Context-dump before asking the AI to build

Corey often begins with a voice conversation in ChatGPT or a long message in Codex plan mode. Grant uses a similar process in Claude Code. (3:06) (1:51:04)

ChatGPT Voice is especially useful when the idea is still fuzzy. Talking for 20 minutes often produces better raw material than trying to write a perfect product brief on the first attempt. (52:25)

Explain the problem like you are talking to a product manager:

• What prompted the idea
• How you currently handle it
• What you dislike about existing options
• Which features are essential
• Which features can wait
• What devices it should work on
• Your technical experience
• Your budget
• Your privacy expectations
• What “finished” means for the first version

Do not worry about using the correct engineering terminology. Describe the behavior you want.

When Corey could not remember the phrase “pill-style tabs,” he described “rectangular rounded ones with the round corners.” The AI eventually got there. Screenshots and examples make this much easier. (23:58)

A useful trick is to ask the coding agent to label the interface for you. Tell it to name each component on the screen, such as the sidebar, card, modal, dropdown, tab, toast, and navigation bar. Once you both use the same vocabulary, design changes become much easier to request. (25:10)

3. Make a plan before generating the application

This was the biggest improvement in our process. (3:06)

Ask the strongest model available to produce a written plan before it changes any files. (1:47:20)

A useful planning request looks like this:

I want to build the application described below.

Do not write code yet.

First:

1. Restate the user problem in plain English.
2. Identify the smallest useful first version.
3. Separate required features from later improvements.
4. Recommend the simplest technical approach.
5. Explain any databases, APIs, accounts, hosting services, or costs involved.
6. Identify privacy and security risks.
7. Break the build into testable stages.
8. Ask me any questions that would materially change the plan.

Assume I am a non-engineer. Explain unfamiliar terms when they first appear.

[PASTE YOUR CONTEXT DUMP]

Review the plan until you can explain it yourself.

You do not need to understand every line of future code. You should understand where information is stored, which services the application depends on, and what happens when a user presses its most important button. (1:17:00)

4. Design the interface before engineering the backend

Changing a mockup is cheaper than changing a working application.

Corey frequently asks ChatGPT to produce a visual “card” containing:

• A logo concept
• A color palette
• A rough interface
• Example buttons and navigation
• The overall visual mood

(6:50)

Grant often starts in Claude Design, Google AI Studio, or another visual builder. These tools let you iterate on the interface before dealing with databases, authentication, and deployment. (1:25:39) (1:49:15)

Ask for multiple options. Point to individual parts and say what feels wrong.

Useful feedback sounds like:

• “This feels too much like enterprise software.”
• “The main action needs to be obvious on a phone.”
• “Show completed tasks as a score.”
• “Reduce this to one screen.”
• “Use this screenshot as the visual reference.”
• “I need to perform the main action with one hand.”

The goal is not a perfect design system. The goal is to create a target the coding agent can follow.

A quick distinction helps here: Claude Design is for creating and iterating on the interface. Claude Code is for working through the underlying files, commands, and application logic. You can start in Design, download or connect the project, then continue in Code. (1:54:45)

5. Give the build to the right tool and model

You have several possible on-ramps. Pick the simplest one that matches the project. (17:36)

Easiest starting point: a visual prototype

Use a visual builder when you want to prove that an interface or workflow makes sense.

Good starting options include:

• Claude Design for websites, interfaces, and downloadable prototypes
• Google AI Studio when the application relies heavily on Gemini or other Google services
• v0 for rapidly creating and refining web interfaces
• ChatGPT Sites for small personal web tools that can be created and hosted inside ChatGPT

These remove much of the initial setup and let you see changes immediately. (1:25:39) (1:49:15)

Desktop app, terminal, or Cursor?

A viewer asked whether building in a desktop app or terminal produces a different result than working in an editor such as Cursor. The interface mostly changes how you supervise the work. (1:56:20)

• A terminal or autonomous desktop agent is useful when you want the AI to inspect the whole repository, run commands, test, and make coordinated changes.
• An AI editor is useful when you want to see the files, inspect diffs, and work beside the agent.
• A mobile interface is useful for ideation, planning, checking progress, and small changes. Native app builds still need the local development environment that can compile, test, and sign the application.

For beginners, the best interface is the one that makes the files, proposed changes, and errors visible enough that you can ask questions. The model, context, permissions, and review process affect the result more than the shape of the chat box.

Best first functional project: a Chrome extension

A Chrome extension is one of the easiest ways to make useful software. (1:09:39)

It can:

• Transform selected text
• Save information from a page
• Organize tabs
• Copy open links
• Add buttons to an existing workflow
• Run locally without a public server

Grant’s first extension surfaced synonyms without opening a thesaurus. Corey built Tab Crusher to gamify closing old tabs and Quote Gobbler to save selected passages. (1:13:40)

When someone asked how Tab Crusher was made, Corey explained that Codex handled the build and helped deploy it to the Chrome Web Store. (1:19:27) (1:30:37)

To install your own extension locally:

1. Ask the coding agent to package the extension.
2. Open Chrome’s Extensions page.
3. Turn on Developer mode.
4. Select Load unpacked.
5. Choose the generated extension folder.
6. Pin the extension to your toolbar.

(1:14:10)

You can keep it private and use it yourself before deciding whether it belongs in the Chrome Web Store.

Best no-fuss personal tool: a web app

A web app runs in a browser and works across devices.

For a private tool, ChatGPT Sites or another hosted builder may be enough. You can also save a website to an iPhone home screen, giving it an icon and app-like launch experience without going through Apple’s review process. (15:15)

This is ideal for:

• Task trackers
• Calculators
• Writing utilities
• Internal dashboards
• Personal databases
• Meal planners
• Lightweight forms

Before you share: privacy, storage, and who can see what

Several of the most important questions in the chat were about privacy, personally identifiable information, and whether a prototype is public. (11:01) (15:47)

The practical rule is simple: do not put sensitive, confidential, health, payment, or personally identifiable information into a prototype until you understand the product’s access settings, data terms, storage, and logs. Keep passwords and API keys in server-side secrets or environment variables, never in visible client-side code.

A few useful distinctions:

• A new ChatGPT Site starts limited to its owner and workspace administrators until its access settings are changed. Choosing public access means anyone on the internet can open it, so review the content, forms, uploaded files, and data collection before publishing. OpenAI’s Sites guide explains the current access options and responsibilities.
• A Google AI Studio app is private by default. When you share it, other users may be able to see its code and fork it. Google’s current Build documentation explains sharing, secrets, GitHub export, and deployment. (1:28:00)
• A tool saved in your browser may use local storage, which usually keeps information in that browser on that device.
• A multi-user app normally needs authentication plus a database. Each record should be associated with the signed-in user’s unique ID. Without that separation, the application cannot reliably know which list belongs to which person. (22:08)

That last point matters for clubs, teams, and communities. If you create an app behind your own ChatGPT login, sharing a screenshot or private preview does not automatically give every member their own account and data. You need either workspace sharing that fits the use case, or a deployed web app with authentication, a server, and per-user storage. (27:05) (28:15)

Best path for an extensible public app: GitHub plus a coding agent

Once you want more control, put the project in GitHub.

Think of GitHub as a cloud archive for code. It records changes, lets you reverse mistakes, and makes it easier to move a project between tools. (47:20)

A common workflow is:

1. Create the prototype in Google AI Studio, Claude Design, or v0.
2. Export or connect the project to GitHub.
3. Open the repository in Codex or Claude Code.
4. Ask the coding agent to implement the backend and refine the application.
5. Save completed changes back to GitHub.
6. Connect GitHub to your hosting provider.

GitHub becomes the shared source of truth. You can prototype in one product, continue locally in another, and publish through a third. (1:30:43)

The Google AI Studio connection can feel less seamless than the marketing diagram suggests. A reliable fallback is to prototype in AI Studio, export to GitHub or download the code, then continue in Codex or Claude Code. Do not spend hours forcing every change to round-trip through the original builder. (47:59) (51:18)

GitHub can look hostile to a first-time builder. Treat it as save history, not a test of whether you deserve to code. When a screen does not match the instructions, take a screenshot, show it to the AI, and ask what to click next. (2:17:33) (2:17:51)

6. Test the application before you fall in love with it

When the agent announces that the build is complete, resist the urge to publish immediately.

Corey’s testing prompt asks a stronger model to:

• Review the code
• Review security
• Test every button and feature
• Evaluate the product from a user’s perspective
• Identify anything confusing or unpleasant

(18:00)

Use separate passes:

Perform a full code review of this project.

Look for:
- Bugs
- Fragile logic
- Unnecessary complexity
- Missing error handling
- Dependencies that could cause problems
- Data-loss risks

Explain each important finding in plain English before changing anything.

Then:

Perform a security and privacy review.

Identify:
- Where user data is stored
- What data leaves the device
- Exposed credentials or API keys
- Authentication weaknesses
- Unsafe permissions
- Risks created by third-party services

Rank findings by severity. Fix critical issues first.

Then:

Act as a first-time user.

Test every visible button, form, link, state, and primary workflow.

Report:
- Anything that does not work
- Anything whose behavior is surprising
- Anything that is difficult to understand
- Anything that looks unfinished
- The three improvements that would produce the greatest user benefit

Code review should happen during the build and before release. Run a focused review after each meaningful milestone, then run a broader code, security, and user test once the full workflow exists. That catches architectural mistakes early without asking the reviewer to re-audit every tiny change. (2:01:54)

Use the most capable model you can justify for planning, code review, security, and release tasks. Smaller models are often sufficient for repetitive implementation, formatting, retrieval, and monitoring. (2:09:27)

When asked whether to use Opus or Sol for review, our answer was the highest-intelligence model available. Reviews are exactly where better judgment is worth the extra tokens. (2:06:30) (2:06:57)

Corey’s Model Policy Skill formalizes this principle: reserve premium models for tasks where a quality difference changes the outcome, use strong mid-tier models for multi-step work, and use cheaper models for predictable operations. (2:11:23)

This routing also helps with token limits. One viewer was burning through Codex resets by using the strongest model for everything. A more sustainable pattern is:

• Strongest model for product planning, architecture, code review, security, and release decisions
• Mid-tier model for implementation and multi-step coding work
• Cheaper model for predictable edits, formatting, retrieval, and monitoring
• Fresh task threads with a short handoff summary when the context becomes bloated

(44:17) (44:38)

7. Publish the smallest version that answers the question

Your first release is an experiment. (40:03)

You are testing:

• Can someone understand it?
• Does the core workflow function?
• Does it solve the original problem?
• Do you continue using it after the novelty fades?
• Does anybody else care?

A working prototype lets you validate demand before raising money or hiring a team. (42:19)

“Is this available to the public?” depends on how you publish it:

• A local app or unpacked extension may be available only to you.
• A private preview may require your account or an invitation.
• A shared Site may be limited to selected people, a workspace, or anyone with access.
• A public website can be opened by anyone with the URL.
• An App Store or Play Store release can be discoverable to the public, testers, or a private organization.

(15:47)

You have several publishing paths.

ChatGPT Sites

ChatGPT Sites is best for fast personal web apps and experiments created inside ChatGPT. (7:19)

Advantages:

• Very little setup
• Hosting is handled for you
• Works across devices
• Useful for private tools and early validation

Trade-off:

• Less control than a separately hosted project
• Public access, authentication, portability, and data storage require closer attention
• A shared site does not automatically create isolated accounts and databases for every visitor

Vercel

Vercel is best for web applications and projects that begin in v0 or use modern web frameworks.

Corey initially built AI Matrix Map with v0, hosted it on Vercel, connected the project to GitHub, and later managed it through Codex. (33:22) (46:27)

The resulting pipeline was:

Codex changes the code → GitHub stores the change → Vercel publishes it (49:28)

For a full walkthrough of the v0 path, watch our app-building session with v0 and Vercel.

Cloudflare, Firebase, Cloud Run, and Railway

Vercel is one option, not a requirement. One viewer had successfully published through Firebase and Google Cloud Run, which can be a sensible choice when the app already lives in Google’s ecosystem. (53:00)

Grant recommends Cloudflare Workers or Cloudflare Pages for personal sites, small web tools, and lightweight applications. (1:35:39)

It works well when you want:

• A custom domain
• Fast global hosting
• GitHub deployment
• Small APIs or Cloudflare Workers
• A relatively inexpensive place to publish

Grant’s personal site was created with coding agents and deployed through this workflow. (1:35:39)

Use a service such as Railway when the application needs a continuously running server, persistent database, multiplayer state, or user accounts. (1:41:20)

Grant used Railway behind Sqwirl World to track players and run the game server. Cloudflare hosted the public-facing site, while Railway handled the heavier application infrastructure.

A useful rule:

• A portfolio or static landing page probably does not need Railway.
• A multiplayer game with user accounts probably does.
• A Google-heavy app may fit Firebase or Cloud Run.
• A lightweight site or API may fit Cloudflare.

(53:45)

Apple’s App Store

A native iPhone app introduces more steps:

1. Join the Apple Developer Program.
2. Create the app’s listing in App Store Connect.
3. Build the application through Xcode.
4. Test it with TestFlight.
5. Prepare screenshots, descriptions, privacy details, and legal declarations.
6. Submit it for Apple’s review.

(1:02:29) (1:05:06)

Corey used Codex to help build and submit Bean Counter. The agent opened an iPhone simulator, captured screenshots, prepared listing materials, and guided him through the parts requiring human review. (1:06:13)

He did not hire a software engineer to get this small app into the store. That proves the path is accessible, not that expert review has become unnecessary. Bring in an experienced engineer when the application handles high-risk data, money, identity, health, complex infrastructure, or a growing user base. (55:39) (55:51)

Publishing through Apple still carries real responsibility. You must read legal declarations, understand data handling, and verify the application yourself.

For a first project, a web app saved to the home screen usually provides faster validation. (15:15)

Google Play Store

The Android process is similar in shape, but the tooling and policies differ. (1:06:11)

A simple version is:

1. Create a Google Play Developer account and app record in Play Console.
2. Build and sign an Android App Bundle.
3. Upload the build to an internal or closed testing track.
4. Complete the store listing, content rating, privacy policy, and Data safety details.
5. Test with real devices and users.
6. Submit a production release for review.

Google AI Studio can now generate native Android projects and publish them to an internal testing track, while production releases are managed through Play Console. Google’s Android app guide explains the current workflow, and Play Console’s publishing guide covers release states and review.

A practical ladder for complete beginners

You do not need to jump from zero to an App Store launch.

Use this progression:

Level 1: Make one disposable prototype

Open Claude Design, ChatGPT, v0, or Google AI Studio. (1:25:39) (1:49:15)

Ask it to create a single-screen interface for a problem you experience. Change the words, layout, and buttons until the idea becomes concrete.

Success means: you can see the idea.

Level 2: Build a local Chrome extension

Create something that transforms a workflow you already perform in Chrome. (1:09:39)

Keep the information local. Install it with Developer mode.

Success means: you use it twice in one week.

Level 3: Build a private web tool

Create a task tracker, idea vault, calculator, or dashboard.

Save it to your phone’s home screen. (15:15)

Success means: the tool replaces a note, spreadsheet, or repetitive manual process.

Level 4: Connect the project to GitHub

Learn how to:

• Create a repository
• Save changes
• Inspect what changed
• Restore an earlier version
• Connect a coding agent

(47:20)

Success means: you can make a change without fearing that one bad prompt will destroy the project.

Level 5: Publish a public website

Use Cloudflare, Vercel, Firebase, or another host. (1:35:39)

Connect a custom domain and ask a few people to try it.

Success means: someone other than you can use it without a guided tour.

Level 6: Add accounts, a database, or agents

Only add these when the product requires them. (1:41:20)

This introduces more risk, cost, and maintenance. Run stronger security reviews and understand the service storing your information.

Success means: the system survives normal use and failures without losing important data.

Level 7: Package a native app

Move to an app store after the core idea has already proven useful. (1:02:29)

Success means: the native version offers a meaningful benefit beyond the web version.

How to choose the right service

Here is the stack we would recommend by goal.

“I want to see whether my idea makes sense”

Start with:

• Claude Design
• Google AI Studio
• v0
• ChatGPT

Focus on a clickable interface and one core workflow. (1:25:39) (1:49:15)

“I want a personal tool on my phone”

Start with:

• ChatGPT Sites or another simple web builder
• A mobile-friendly web interface
• Add to Home Screen

Skip the App Store until distribution or native phone features matter. (15:15)

For a true native app, use mobile or voice tools to plan, then move the repository into a local environment that can build and test the app. For iPhone, that means a Mac and Xcode. The Codex app or terminal is a workflow choice; the local toolchain is what makes compiling, simulating, signing, and submitting possible. (2:04:44)

“I want a public website”

Start with:

• Claude Design, v0, or an AI coding agent
• GitHub
• Cloudflare, Vercel, Firebase, or Cloud Run
• A custom domain

(1:35:39)

“I want an application with users and stored data”

Consider:

• GitHub
• Claude Code or Codex
• Vercel, Cloudflare, Firebase, or Cloud Run for the interface and server
• Railway, Supabase, Cloudflare D1, Firestore, or another managed backend
• Authentication that assigns every user a unique ID

Ask the coding agent to compare the options based on your budget, expected usage, privacy needs, and technical comfort. (1:41:20)

“I want a native iPhone app”

Plan for:

• An Apple Developer Program account
• A Mac capable of running the required Xcode version
• Xcode
• TestFlight
• App Store Connect
• A coding agent that can work with the local project

(1:02:29)

“I want the application to maintain itself”

Begin with one scheduled job, not a swarm of autonomous agents.

Corey’s AI Matrix Map uses agents to review companies, collect verified changes, update the project, and report what happened. That is powerful, but it also creates the possibility of automatically publishing mistakes. (43:35) (48:00)

An agent is simply a model operating inside a loop with instructions, tools, and permission to take actions. Start with a scheduled job that has one clear responsibility, approved sources, a report, and a human checkpoint. Our beginner’s guide to AI agents explains the fundamentals. (44:36) (48:24)

For each automated process, define:

• What sources it may use
• What counts as verified
• Which changes require approval
• Where it records its work
• What happens when it fails
• How you roll back a bad update

Automation magnifies your process. A weak process becomes a faster weak process.

What you actually need to learn

AI can write much of the code. Learning still matters.

Focus on the concepts that help you supervise the work:

• Frontend: what the user sees and interacts with
• Backend: the logic and services operating behind the interface
• Database: where persistent information is stored
• API: a structured way for one service to request something from another
• Authentication: how the app knows who a user is
• Repository: the project and its code history in GitHub
• Deployment: publishing a version people can access
• Environment variable: a protected place for credentials and settings
• Dependency: outside software your project relies upon
• Logs: records explaining what the application did or why it failed

Whenever the agent builds something unfamiliar, ask:

Explain how this application works to a smart non-engineer.

Walk through:
1. What happens when the app starts
2. What happens when I use its main feature
3. Where data is stored
4. Which external services it contacts
5. Which files contain the most important logic
6. What is most likely to break
7. What I should check first when troubleshooting

This turns each project into a lesson rather than a mysterious pile of generated files. (1:17:00)

For a slower beginner path, use these in order:

• Learn the absolute basics of coding with AI with OpenAI’s Alexander Embiricos
• Learn which coding skills still matter in 2026 with Ryan Carson
• Watch a complete app build with v0 and Vercel
• Read our Claude Code Beginner’s Guide
• Watch our beginner’s guide to AI agents

Those resources answer the “what do these words mean?” question before you try to operate a database, deploy a server, or publish a mobile app. (19:53) (31:26)

Key moments from the livestream

• (1:48) Grant explains that both hosts started with no engineering background and learned by building.
• (3:06) Corey replaces “vomiting ideas” into ChatGPT with a planning-first workflow.
• (4:31) Circle Back begins as a specific problem: capturing tasks quickly and making progress feel like a game.
• (6:50) Corey designs the visual card, colors, logo, and interface before committing the idea to code.
• (12:39) Corey describes personal apps as a way of “patching my vulnerabilities.”
• (15:15) A web app can be saved to an iPhone home screen and used much like a native application.
• (17:36) Corey assigns planning and review to stronger models while using cheaper models for implementation.
• (18:00) The complete Circle Back workflow: plan, make a design card, build, review the code, review security, and test every feature.
• (23:58) Missing the correct design vocabulary creates friction, but descriptions, examples, and iteration can bridge the gap.
• (27:16) Threadline learns Corey’s voice through repeated batches of drafts, approvals, rejections, and specific feedback.
• (33:22) AI Matrix Map begins as a tool for tracking a field that changes too quickly to remember manually.
• (40:03) AI compresses the path from an idea to a proof of concept from months and thousands of dollars to hours.
• (41:42) Grant explains when human engineers still matter: after an idea gains users, stakes, and complexity.
• (42:19) A working prototype lets you validate demand before raising money or hiring a team.
• (43:35) Corey’s public database uses agents to monitor companies and push verified updates.
• (46:27) The AI Matrix Map moved from v0 and Vercel into a GitHub repository managed through Codex.
• (47:20) GitHub is explained as a reversible cloud archive for code.
• (48:00) Corey creates recurring agents by describing the schedule, sources, expected updates, and reports in plain English.
• (49:28) The deployment pipeline: Codex updates GitHub, and GitHub publishes to Vercel.
• (50:44) On Deck begins with a 90-minute voice conversation about food preferences, health, time, and household constraints.
• (57:00) Bean Counter turns one button and a savings calculation into a useful native iPhone app.
• (1:02:29) Grant outlines the Apple Developer, Xcode, TestFlight, and App Store Connect workflow.
• (1:06:13) Codex uses the iPhone simulator to capture Bean Counter’s App Store screenshots.
• (1:09:39) Grant recommends a Chrome extension as one of the least intimidating first software projects.
• (1:13:12) Recreating a small extension can give you more control over privacy than trusting an unknown developer.
• (1:15:42) Corey’s starting advice: notice your recurring annoyances and ask whether you could build the solution yourself.
• (1:17:00) Ask the agent to explain your own application’s code, architecture, dependencies, and decisions.
• (1:23:00) Grant describes progressing from a Chrome extension to modifying an open-source project.
• (1:25:39) Google AI Studio provides a low-friction environment for prototyping applications that use Google models and APIs.
• (1:30:43) Connecting a prototype to GitHub lets you continue building it in other tools.
• (1:32:43) FlowState evolves from an AI Studio experiment into a local writing application.
• (1:35:39) Grant explains why he selected Cloudflare for his personal website and smaller web projects.
• (1:41:20) Railway enters the stack when an application needs a database, users, or a continuously running server.
• (1:43:17) Sqwirl World starts as a forgotten experimental prompt and grows into a multiplayer game.
• (1:47:20) Ask the agent to explain its plan in non-engineering language before allowing it to build.
• (1:49:15) Claude Design creates Sqwirl World’s launch website directly from the GitHub repository.
• (1:51:04) Grant demonstrates a detailed voice dump for a community app, including features, budget, hosting, and learning goals.
• (1:52:53) Claude turns the vague request into concrete product questions before generating the design.
• (1:54:08) A downloaded design can become the starting point for a deeper Claude Code implementation.
• (2:09:27) Use the strongest available model for reviews and actions with serious consequences.
• (2:10:13) Save model-routing rules in project memory so the agent delegates work consistently.
• (2:11:23) Corey explains his model policy: premium intelligence for consequential work, mid-tier models for synthesis, and cheap models for predictable plumbing.
• (2:13:53) Grant’s experimentation gradually became confidence, competence, and a desire to keep building.
• (2:15:31) A non-technical business owner or independent creator can now build a personal website in hours.
• (2:16:35) GitHub feels intimidating until you begin taking each confusing screen back to the AI.
• (2:16:58) When instructions and reality do not match, share a screenshot and ask the agent to course-correct.

What AI still does not solve for you

The strongest counterargument to this entire guide is straightforward: generating software is not the same as operating reliable software.

An AI can create an impressive prototype while quietly introducing:

• Security vulnerabilities
• Unnecessary dependencies
• Unexpected usage bills
• Privacy problems
• Fragile authentication
• Unlicensed assets or code
• Features nobody wanted
• A maintenance burden you do not understand

The easier software becomes to generate, the easier it becomes to create more software than anyone can responsibly maintain.

That makes judgment more valuable.

You still decide:

• Whether the problem deserves software
• Which data the app should collect
• What level of reliability the use case requires
• When a human engineer should review the work
• Which legal declarations you can truthfully make
• Whether an automated update should reach production
• When to abandon a project

(41:42)

A personal coffee tracker and a medical records system belong in different risk categories, even if the same coding agent can generate both interfaces.

Our take

The first wave of AI coding focused on whether a model could write code.

The more useful question is whether ordinary people can use these systems to develop software judgment.

That happens by building small things, asking how they work, breaking them, repairing them, and gradually attempting harder projects. Your first extension teaches you about files and permissions. Your first website teaches you about hosting and domains. Your first database teaches you why “save” is more complicated than it appears. (2:13:53)

Each project expands the set of ideas you consider possible.

The compelling outcome is that writers, teachers, operators, designers, club organizers, and small-business owners gain the ability to create software for problems too small or specific to interest a traditional software company. (42:45) (2:15:31)

The unresolved question is how far that model can safely scale. Personal tools can tolerate rough edges. Products handling other people’s identities, money, health, or work cannot.

Start with the weird little tool living in your head. Make it solve one real problem. Understand what the AI built. Then earn the right to make the next one more ambitious. (1:15:42)