I Rebuilt My Entire Website in One AI Session

The Build

The first version of the website was wrong in the way that a lot of first versions are wrong. The brand it reflected was not the brand the channel was building toward. The hook on the homepage described a generic value proposition that every side hustle channel and every creator economy newsletter was already saying. The headline did not say anything specific. The imagery did not match. The counter was static and hardcoded. It showed a date and a number that was already wrong before anyone visited the page. A countdown to an exit date is only valuable if it is live. A hardcoded countdown is a broken promise on day one. The decision to rebuild was not a long deliberation. The old site was embarrassing in the specific way that something is embarrassing when you know exactly what it should have been. Not embarrassing because it looked broken. Embarrassing because it looked like a first draft that shipped. A first draft is useful in the process. A first draft on the public URL is a different kind of signal. The moment the decision was made, the old site was two days old. The rebuild started the same day.

The question that comes up every time the Claude Code workflow gets described is the same question. But do you know how to code. The answer is that knowing how to code and using Claude Code to build something are two different skill sets, and only one of them is required for this workflow. Claude Code is not autocomplete for developers. It is an AI engineer that receives instructions in plain language, interprets the intent, generates the implementation, and explains what it built and why. The operator does not need to know the syntax of the language being written. The operator needs to know what the output should look like and whether the output matches the intent. That is a different kind of literacy. It is not easier. Directing an AI engineer requires the same clear thinking that directing a human engineer requires. You still need to know what you want. You still need to evaluate what you got. You still need to push back when the implementation does not match the intent. You still need to catch edge cases. The cognitive load does not disappear. It shifts. Instead of spending the cognitive energy on the syntax, you spend it on the architecture and the evaluation. For someone who has been a system thinker for twenty-eight years, that shift is not a downgrade. It is a better use of what the brain is already good at. The gap between idea and deployed website, when Claude Code is the engineer, is measured in hours. Not in weeks. Not in months. Not in a hiring process. Hours. The session that rebuilt this site ran for most of one afternoon. By the end of it there was a live URL with a dynamic counter and copy that matched the actual mission of the channel.

The build runs on four tools. Claude Code handles the engineering. GitHub handles the version control and the deployment trigger. Netlify handles the hosting for the static sites. Vercel handles the hosting for the more complex deployments. The pattern is the same whether the output is a landing page or a full web application. Claude Code writes the code. The code goes into a GitHub repository. A push to the main branch triggers an automatic deployment. The live URL updates within ninety seconds of the push. There is no FTP. There is no server management. There is no deployment pipeline to configure after the initial setup. The initial setup is a one-time thirty-minute task. Everything after that is push and deploy. Some of the sites in the stack are static HTML and CSS. The Exit Build website and the individual log pages are static. Netlify handles these for free at the current traffic volume. The EdReg application, which is a more complex React and Vite application with a database backend, runs on Vercel. The distinction matters for hosting cost and configuration complexity. Static sites are simpler. Full applications require more setup. Claude Code handles both. The workflow is the same in either case. Describe the requirement. Review the output. Push. The tool does not care whether the requirement is a static header or a dynamic search interface. Clear requirements produce good output. Vague requirements produce revisions.

The website rebuild was not the first site built through this workflow. It was the fifth. That is relevant because the first site is always the hardest one. The first site is where the workflow gets learned, where the mental model gets built, where the mistakes get made and the patterns get established. The second site uses the patterns from the first. The third site goes faster than the second. By the fifth site the process has collapsed into something predictable. The first session with Claude Code requires more direction, more correction, more back-and-forth to establish what good looks like for this specific project. The second site requires less of that calibration because some of it carries over. The shared mental model between the operator and the tool gets richer with each project. The EdReg application was built before the Exit Build website. The Exit Build website was built after the workflow was already established. That sequence is visible in the output. The Exit Build site is cleaner than EdReg was at the same stage. Not because the requirements were simpler. Because the operator had been through the workflow enough times to give clearer requirements at the start. Each site built through this workflow teaches something the next one uses. The lesson from the static counter on the first version of the Exit Build site was to ask for a live dynamic counter before the first deploy. That question now comes up in every site brief before the first prompt gets written. The workflow compounds. The output reflects it.

The rebuilt site is different from the first version in every element that matters. The hook is honest. The first version said something generic about building online income. The new version opens with the actual premise of the channel. There is a date. There is a salary. There is a gap. Those three things are specific enough to filter. Someone who does not find that premise compelling will leave. Someone who does find it compelling will stay. That filtering is not a problem. That filtering is the function of a specific hook. A generic hook keeps everyone engaged for slightly less time than a specific hook keeps the right people engaged for significantly longer. The counter is live. It calculates the days remaining to May 31 2027 at render time and updates every time the page is loaded. It is not approximate. It does not require a manual update. The day it goes to zero, it shows zero. That is not a detail. A static counter that shows the wrong number is a different signal than a live counter that shows the right number every time. The copy reflects the actual mission. Not aspirational language. Not the version of the exit plan that sounds clean in a pitch. The version that includes the corporate job still running, the affiliate links just getting approved, the subscriber count not yet at the threshold to qualify for the programs that declined the first applications. The site is a build log. Build logs should reflect the build as it is, not as it will be. The site is not finished. The about page needs another pass. The tools page is sparse. The log index needs better filtering. These are known gaps. They are documented so they get addressed. The point of a build log is that the imperfect version is visible and the improvement is visible and the trajectory is visible. The site will continue to evolve as the build evolves. That is not a caveat. That is the design.

The rebuild story is not significant because the site is impressive. The site is functional. Functional is the relevant bar for a channel at week two. The story is significant because the rebuild happened in one afternoon with no design fees, no developer, and no coding knowledge required. That gap between what this workflow produces and what that workflow used to cost is the most relevant fact for anyone who has a project that has been sitting in a document for six months because the next step is too expensive or too technical or too dependent on someone with a skill set that is not in the room. The tools exist. The gap between idea and deployed is not a technical gap anymore. It is a decision gap. The decision to sit down with an AI engineer and work through the requirements until the output matches the intent. That decision takes a few hours. The outcome is a live URL. The outcome is not perfect on the first session. It rarely is. The first session produces something that works. The subsequent sessions refine it. The process is iterative, not sequential. The good news for anyone watching this channel is that the process is visible. Every session gets documented. Every tool gets linked. Every cost gets itemized. You do not need to know the coding language. You need to know what you want. The tools exist to build it. The gap is gone. Follow along. This is the build log.

The Tools

The Math

The Next Log