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

Two years ago, neither of us would have described ourselves as software engineers.

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.

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.

In our full livestream, we walked through more than 15 projects and reconstructed how we built them. This guide turns that conversation 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.

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

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.
• 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.

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?

The seven-step process we now use

1. Start with a problem you experience repeatedly

Write down the moment when the problem occurs.

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.

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.

3. Make a plan before generating the application

This was the biggest improvement in our process.

Ask the strongest model available to produce a written plan before it changes any files.

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.

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

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.

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.

5. Give the build to the right tool and model

You have several possible on-ramps. Pick the simplest one that matches the project.

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.

Best first functional project: a Chrome extension

A Chrome extension is one of the easiest ways to make useful software.

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.

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.

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.

This is ideal for:

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

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.

A common workflow is:

1. Create the prototype in 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.

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

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

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.

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.

7. Publish the smallest version that answers the question

Your first release is an experiment.

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?

You have several publishing paths.

ChatGPT Sites

Best for fast personal web apps and experiments created inside ChatGPT.

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

Vercel

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.

The resulting pipeline was:

Codex changes the code → GitHub stores the change → Vercel publishes it

Cloudflare

Grant recommends Cloudflare for personal sites, small web tools, and lightweight applications.

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.

Railway

Use a service such as Railway when the application needs a continuously running server, persistent database, multiplayer state, or user accounts.

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.

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.

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.

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.

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.

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.

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.

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

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, or another host.

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.

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.

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.

“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.

“I want a public website”

Start with:

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

“I want an application with users and stored data”

Consider:

• GitHub
• Claude Code or Codex
• Vercel or Cloudflare for the interface
• Railway, Supabase, Cloudflare’s database products, or another managed backend

Ask the coding agent to compare the options based on your budget, expected usage, privacy needs, and technical comfort.

“I want a native iPhone app”

Plan for:

• An Apple Developer 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

“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.

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.

The beginner coding session with OpenAI’s Alexander Embiricos goes deeper into the fundamentals of working with Codex. Our conversation with Ryan Carson covers which coding skills remain valuable when AI handles more implementation. For automation, our beginner’s guide to AI agents provides the next step.

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

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.

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.

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.