---
title: How to Build Your Own Web App in Five Easy Steps
author: Tris
date: 2026-05-23
url: https://www.trishussey.com/how-to-build-your-own-web-app-in-five-easy-steps/
---


Setting up GitHub and choosing your AI-enabled coding toolset



I can’t code my way out of a wet paper bag.



I’ve tried. I’ve lived through the eras of Perl, Java, and JavaScript, and honestly, programming languages just don’t click for me. I can’t look at a blank window and think, “Okay I know how to start this…” *Writing* however *is* how my brain works, and that happens to be perfect for the AI-enabled coding era.



My first attempts at vibe coding at the end of 2024 were [before the term was even coined](https://en.wikipedia.org/wiki/Vibe_coding), but it blew my mind. I took seven years worth of podcast data and threw it up against all the multivariate stats models I used in grad school (I had to dig out my thesis to double check which ones to use) and confirmed my gut feeling about what “worked” and what didn’t.



Mind. Blown.



I didn’t need to learn Python, I just needed to explain what I wanted. I write out the vision, ask an AI to pull it together, and then watch as it’s built. Back then, I was cobbling things together using Copilot (don’t judge, it was a paid enterprise plan), [Notepad++](https://notepad-plus-plus.org/), and Windows terminal (again, don’t judge). At the beginning of 2025 I started building “apps.” I use that term loosely because my first vibe coded “apps” were all just single HTML files Gemini built for me. I was skittish about building more than that. I didn’t have a good methodology to follow. I didn’t follow the “rules,” because *I didn’t know the rules*.



But the apps worked. A kanban board that synced with Google Tasks, a Value Proposition Canvas tool, a few fun interactive things for kicks. The real breakthrough was when [I built my content audit tool](https://trishusseywriting.substack.com/p/solving-my-problems-first).



My Python scripts to crawl and document websites worked. They might not have been the most efficient scripts in the worlds, but they did the job (those scripts are next on the “clean up this mess” refactoring I’m doing. However…it unlocked a whole engine of content audits, brand voice guides, and more “well if I can do this, I wonder if I can do *that*…” questions.



The more I built, the more confident (maybe cocky) I got. The more I thought, “you know I bet I can have something code that up for me…” the more I built. Not great. Terribly messy. *Extremely* disorganized. Still, over time, I learned how to build things better. How to set things the right way following development best practices so things were *less likely* to blow up in my face (they still do, often spectacularly). To be honest the big awakening for me was using [Antigravity](https://antigravity.google/) and [Gemini CLI](https://geminicli.com/). Those tools helped me sort out source control with GitHub, getting all the extra stuff installed that’s needed, and sort out the mess I made of my dev environment in general.



Which means…



If I can do it, so can you. And you don’t need to be a geek to do it. I promise. Here’s my simple workflow for building apps without writing a single line of code. Word people. All you need are words.



**A Note on the Tools**



I’m using Gemini AI Pro tied to a personal Gmail account (Google One). While I use Google Workspace for client work, I found personal Google accounts offered better access to the AI usage levels and tools I needed for more advanced coding (plus other goodies like Developer Premium accounts and credits on Google Cloud). We’ll be doing the heavy lifting in Antigravity (my tool of choice), but the principles apply to whatever you want to use. I also lean on:




[GitHub](https://github.com/)



[Gemini CLI](https://geminicli.com/) (which is [closing for most folks June 18th in favor of Antigravity CLI](https://developers.googleblog.com/an-important-update-transitioning-gemini-cli-to-antigravity-cli/))



[BBEdit](https://www.barebones.com/products/bbedit/) (the gold standard of Mac text editor IMNSHO)



A terminal app (the basic tool in MacOS and Windows is just fine, but I’ve been using [iTerm2](https://iterm2.com/) lately).




[Share](https://30plusdaysofai.substack.com/p/how-to-build-your-own-web-app-in?utm_source=substack&utm_medium=email&utm_content=share&action=share&token=eyJ1c2VyX2lkIjoyMzY5NjQ3LCJwb3N0X2lkIjoxOTg4OTU1NTAsImlhdCI6MTc3OTczMjc5NiwiZXhwIjoxNzgyMzI0Nzk2LCJpc3MiOiJwdWItNzUwNDIyMSIsInN1YiI6InBvc3QtcmVhY3Rpb24ifQ.0Q-MIXQyjNxiZ1pwhqRLuBlh-b6gPuuekSqsnOBy1ZY)



**Step 1: Setting the stage**



Before you start prompting to build your amazing app, you need to get organized. I made every mistake possible when I started out and set up my environment. My first project folder was called “Vibe Coding”—capital V, a space in the middle.



**Don’t do that.**



When you’re working in the command line (CLI), spaces and capital letters are a problem. They require extra typing and “escaping” characters that just slow you down. Not to mention I found AI coding tools often choked on needing to deal with the spaces. Even an AI would forget to escape the space when it used a command. This makes the whole coding experience tedious, frustrating, and annoying. Trust me, lowercase and no spaces (dashes “-” and underscores “_” are your friends) is the way to go.



**The Rule:** Keep it simple. Create a folder at the root of your drive called projects (all lowercase).




**Mac Users:** Keep this out of your iCloud folder. iCloud and GitHub (source control and version control system) don’t play nicely together. I don’t know why, but I’ve had enough issues keeping things in sync that I know just don’t do it.



**Structure:** Inside projects, create a new folder for every app. Let’s call our current one “new-app”.




Inside new-app, create three core directories:




app (or code): Where the actual code for your project will live.



prd: Where your “Product Requirements Documents” (PRDs) go.



info-files: For assets, screenshots of inspiration, and extra data for the AI to chew on. This is optional, but highly recommended.




This is where everything will live. When you’re working on something, this is where you’ll be all the time. You’ll get really used to keeping that window open and (when you’re using the Terminal—which you will be more often than you think) being in that directory.



**Step 2: The master PRD**



Writing Product Requirements Document (PRD) is the most critical step in building a solid app that doesn’t go through iteration after iteration of fixes and wrong paths. PRDs are the blueprints for the house you’re building. This is where you architect what to build. It’s the the master plan for your vision and everything coming next is built on its foundation.



You don’t start building a house by walking up to a plot of land, sinking a shovel into the dirt, and say “okay here’s where my house will be.” You need a *plan* to make it happen.



Here’s how you get started.



Open your AI of choice—use “Thinking Mode” or “Pro Mode” for this—and just talk it out. Use voice-to-text, use voice mode, whatever gets it done for you. Describe everything: the look, the feel, the buttons, the audience. Is this a local tool or a cloud-hosted app? Does it need AI? Does it need a database? Run it just on your machine or host it somewhere? You *literally* can’t give the AI too much info right now.



**The Goal:** You want a logical, well-structured document that describes the “what” and “why” of what you want to build. Once you’re happy with the results in your chat (I like to use the Canvas mode so I can edit as I go), save it as a Markdown file (e.g., master-prd.md) in your prd folder. For Gemini, I’ve found exporting to Docs, *then* downloading as a Markdown file works a lot better than copying and pasting. Yes, extra steps, but it’s worth it for a cleaner looking document. Your AI tool will give you all the saving options you need.




**? WTH is Markdown?:** [Markdown](https://daringfireball.net/projects/markdown/) is one of the native languages of AI (the others are JSON and YAML—file those away for now). Markdown is just a text file. Plain, boring text that’s been around for well over 30 years. It’s clean, universal, and doesn’t have the extra code Word docs or PDFs have—extra code that AIs have to spend time sorting out before they can even read the damn thing. If you’re exporting from Google Docs, make sure your preferences are set to handle Markdown correctly. TextEdit on the Mac or Notepad on Windows will do just fine with Markdown, but I recommend BBEdit for Mac and [NotePad++](https://notepad-plus-plus.org/) for Windows as the text editors of choice. Both are free. Both are easy to use for beginners. Here’s a good [Markdown cheat sheet](https://www.markdownguide.org/cheat-sheet/) to start with that covers the basics (and then some).




**Step 3: Tools & Repository**



Now for the “geeky” part: setting up your safety net and downloading the coding tools.



You need a code editor (IDE) and a place to back up your work. I use Antigravity for coding, but you can use VS Code, Codex, Cursor, or Claude Code. The gold standard for backup is GitHub. Here’s how to get started:




**Create a GitHub Account:** Use your Google ID, it’s easier.



**Initialize Git:** This creates a “repository” (repo) for your project. Think of this as a save point. When things go wrong—and they will—you can always “revert” to a version that worked.



**Keep it Private:** I keep all my repos private. It’s my lab, not a public gallery (at least not yet).




Instead of diving into all the parts of picking and IDE and setting up GitHub (do that first, btw), I created a separate guide for it.



[Newbies Guide to Setting up GitHub and Picking an IDE](https://www.30daysofai.io/assets/AI-Builders-Setup-Guide.pdf)



Let’s continue, shall we?



**Step 4: The sprint methodology**



Here’s the “secret” I didn’t know when I started building bigger projects: Don’t try to build the whole damn app at once. Asking whatever AI-assisted coding tool to read your master PRD and then tell it “Go for it!” will end in a mess.



A big mess.



I’ve done it. Lots. The AI loses the plot at some point in the whole process and you wind up burning a lot of your AI usage allowance just getting it—and keeping it—on track.



Instead, use *sprints*. Sprints are just breaking up your vision into smaller, easier to build chunks. Chunks that, btw, don’t use up your entire context window while building. Yes, IDEs have context windows too. If it’s talking with an AI, it has a context window. Sprints are a core part of the Agile Development Methodology. Think of it as the old “how do you eat a whole elephant?” bit, “slowly, one bite at a time.”




**? Why not create all the sprints at once?** You might wonder way don’t tell my tool to create all the sprint PRDs at once. The reason is simple—you don’t actually know what you need yet. Once you finish the first sprint you might think of a new feature that *wasn’t* in the original master PRD. You might even want to *remove* a feature entirely. You won’t know what you want to do in sprint 2 until sprint 1 is done.




This is where actually start building the project.



**A Note on the Tools**




Open your project folder in your IDE.



In Antigravity, you’re going to see a big, blank window and you’re going to need to start a new conversation and project. From the menu above the chat box scroll down until you see “New Project” and point it at the folder for your app. For other AI tools you’ll start working with something like Gemini Code Assist or GitHub Copilot (the AI chat inside your editor).



Ask the AI to read your master-prd.md and summarize it back to you. **Do not let it code yet.**



Once it understands the big picture, say: *“Okay, let’s break this into sprints. Write a new PRD for Sprint 1 and save it to the PRD folder. Create the PRD to be as token-efficient as possible and write it assuming a Flash model will be doing the coding. No guessing. Clear instructions for each step are critical. If there any set up tasks I need to do, put them in a separate section with step-by-step instructions for me.”*





??Over the time I’ve been writing this Google made big changes to Antigravity. They’ve made “Antigravity” the main app what was the Agent Manager before and there is no code editor portion. If you want the code editor (aka IDE), you can download it separately.




Do this with a thinking model (Gemini Pro, Claude Sonnet, Claude Opus) in planning mode. The AI needs this oomph to do a good job. Within Antigravity I’ve found the Claude models (Sonnet or Opus) to make better sprint PRDs than the Gemini Pro models. Give the sprint document a read, make changes as needed—don’t assume the AI will get it right, read the sprint PRD, and then buckle up, because it’s time to build.




**? Save to GitHub often:** Every time you’ve completed a thing (starting a sprint, ending a sprint, a big new feature within a sprint), commit the updates and new files to your repository and push up to Git. Before you create the first sprint prd; commit and push. After you have the sprint 1 prd; commit and push. After the AI finishes its first pass at sprint 1, commit and push. You’re getting the idea here.




**Step 5: Building**



Now, we watch the magic happen.



Switch to a Flash model (simple, easy, fast, cheap). I like to keep it in “Planning mode” (Google took this out of Antigravity as an option, I think it’s always in Planning mode now) for the work. Planning mode just means before it does anything it has to think it through, make a plan, and proceed.



Tell the AI to start Sprint 1.




**Watch the plan:** It will build a checklist. Review it.



**Permissions:** It will ask to run commands or create files. For the most part, let it. If you’re not sure if it’s a good idea, ask another AI.



**Persistence:** AIs don’t have feelings. If you have to step away for a day, save your work to GitHub and close the laptop. It will be right there when you get back.



**Test, push back, don’t just accept it:** As your tool builds things, it *will* make mistakes. A feature won’t work as it should—even though the AI said it was built. You might not like something once you see it live. That’s fine. Ask for changes and don’t move on to the next sprint until you’re happy.




When Sprint 1 is done and tested, commit and push to GitHub, then move on to Sprint 2. Repeat until you have a functioning app. As you’re testing a sprint, resist the temptation to start working on the next thing until you’ve created the PRD for the next sprint. Look at what the sprint was supposed to get done, do that and nothing else, *then* start moving forward on the larger plan.



**Isn’t this just a bit much?**



Nope.



Take it from someone who’s had to clean up a mess of projects and lots of time lost to fixing stupid things that both the human and the AI did. The time you spend now, and really it’s only a few minutes for the folder structure and a little longer for your master PRD, is well worth it in the long run.



This isn’t just about making “little web tools and apps,” [this is the new marketing and professional stack](https://30plusdaysofai.substack.com/p/the-new-marketing-skill-isnt-prompting).



Two years ago, my coding projects were flat HTML files that barely did anything. By following this methodology—architecting first, building in sprints, and using the right environment—I’m building functional prototypes that *actually solve real problems*. The five or ten minutes you need to set this all up is worth it.



And when things start getting messy, just ask for help cleaning things up. Believe it or not, you can have an AI help you clean up your mess—I absolutely did.



Remember, the most powerful coding language today is language. The superpower isn’t learning to code, it’s learning to manage the machine by knowing how to start out right *and* knowing what to tell it to do.



**Go build something. Have fun.**



Think someone else would like to read this? Share it. I made this post free for all subscribers so everyone can start building cool sh*t.