A Non-Technical Founder's Blueprint for Vibe Coding

What I Built and What It Costs

I spent 25 years in sales and marketing without writing a line of code. Today I run a live website I built myself, a blog I publish through a visual editor, an email list that people sign up to, and behind all of it, a data pipeline that reads competitor websites and sorts what it finds. I describe what I want in plain English and an AI writes the code. People have a name for this way of working now. They call it vibe coding.

The website costs about $21 a month to run. That is the $20 Claude plan I started on, plus a dollar or so for the domain name. The pipeline behind the product costs a lot more, somewhere around $175 to $195 a month, because it crawls sites and calls models every day. Some of that jump is the Claude plan itself. The pipeline work ran into the limits of the cheaper plan, so I moved up to the $100 plan, and that one subscription now serves both the website and the pipeline. It shows up once, even though it appears in both cost breakdowns further down. The pipeline runs today, and the product it feeds is still being built and not open to anyone yet.

This post is the blueprint I wish someone had handed me when I started. It covers the choices I made, the tools I use, the way I work with the AI from one day to the next, and the mistakes that cost me the most time. You can follow it with no coding background, because I had none.

25 Years Without Writing a Line of Code

My background is sales and marketing. 25 years of it, and for the last 15 I have bootstrapped startups and consulted for companies trying to grow. I have written for Mind the Product, HuffPost, and Search Engine Journal. I know how to find customers and how to tell a company's story. Code was the one thing I always paid someone else to handle.

Years ago I founded a matchmaking startup in India called Jodi Logik. Every feature I wanted meant hiring a developer, waiting, explaining the idea a second time, and paying for work I could not check myself. That pattern followed me into consulting. Every product idea ran into the same wall. By my own rough estimate, hiring a developer would run somewhere between $5,000 and $50,000, or I could spend a year learning to code. Both roads were too long, so most of my ideas stayed as notes in a file.

That changed in October 2025. I started asking Claude small questions. How do I write a spreadsheet formula that does this. How do I pull a list of pages from a website. The first script it wrote for me worked on the first run. So I asked for something harder, a script to read a competitor's site and pull out the services they sell, and that worked too.

Each time, the AI wrote the code and I ran it. When something broke, I pasted the error back and asked what it meant. I never memorised syntax. I learned how to describe what I wanted clearly enough that the AI could build it. People have started calling this vibe coding, and the name fits. The skill is describing what you want in enough detail that a capable AI turns it into working software, then reading the result and asking for the fixes.

By January 2026, about three months after that first question, I had a live website built this way. I had spent more evenings on it than I expected, and I had built more working software than I managed in the previous 25 years put together. The only bill that whole time was a Claude subscription and a domain name.

The Architecture Decisions

Before I built anything, I had a few decisions to make, and the AI helped me think through each one.

The first choice was what the website should run on. WordPress is the default, and I have watched WordPress sites break under plugin updates and fall to attackers through outdated code. The hosted builders like Squarespace and Wix are easier to start with. They charge a monthly subscription that starts around the price of the entry Claude plan and rises with each tier, and they lock you into their system. What I was really weighing was control over the result, and Astro gives me that. It is a static site generator. It costs nothing to run, it loads fast, it needs no server of my own, and it keeps no database sitting there as a target.

Publishing blog posts was the next question. I could keep each post as a file in the project and push it up by hand, which works and turns writing into a technical chore. Sanity solved it better. It is a headless CMS, so I write in a clean visual editor in my browser while the site itself stays static and free.

Hosting was the last piece, the question of where the site lives so people can reach it. Traditional hosting means renting a server every month and keeping it patched. Vercel does the job for free. It adds HTTPS on its own and serves the site from fast machines around the world.

The pieces connect like this. When I push code to GitHub, Vercel notices within seconds, rebuilds the site, and deploys it in about a minute. Content moves along its own track, from Sanity's editor into Sanity's cloud, and the published site reads from both.

The Monthly Cost Breakdown

A website costs almost nothing to run. These are the monthly costs that keep growthfornuts.com online:

• Claude subscription: $20, the plan a website on its own needs
• Vercel hosting: free
• GitHub: free for public repositories
• Sanity CMS: free for a small team
• Astro: free and open source
• Python: free and open source
• Buttondown email: free up to 100 subscribers
• Domain name: about $1 a month

That comes to about $21 a month, and it assumes the $20 Claude plan, which is plenty if a website is all you are building. The subscription is the part doing real work. It stands in for the developer I would once have hired for thousands, and a hosted site builder would cost more than this on its own while giving me less control over the result.

The pipeline behind the product is a different kind of bill. It crawls competitor sites and calls models every day, so it runs on real infrastructure. The Claude line below is the same subscription as above, moved up a tier. The pipeline work ran into the limits of the $20 plan, so I upgraded to the $100 Max plan, and that one plan now covers both jobs:

• Claude subscription: $100, the Max plan (the same one from the website list, not a second subscription)
• Anthropic API for extraction: $30 to $50
• Firecrawl for crawling: $20
• Cloud Run and Cloud Storage: about $26 (2,500 INR)
• Neon database: free tier
• Vercel frontend: free tier

That lands at about $175 to $195 a month. The Claude plan sits in both lists because it is one subscription doing both jobs, so count it a single time rather than adding the tables together. The jump from a website to a working data pipeline is still large, and nobody warns you about the size of it before you are standing in it.

The Tech Stack Explained for Non-Technical People

These are the tools I use, each explained as if you have only ever touched email and a web browser.

Command Prompt

Command Prompt, or Terminal on a Mac, is a way to talk to your computer by typing instead of clicking. Think of it as texting your machine. You type an instruction, it does the thing, and it types back. Every tool in this stack is driven from here, and once the fear wears off it is faster than hunting through menus. A short session looks like this:

C:\Users\You> cd Documents
C:\Users\You\Documents> mkdir my-project
C:\Users\You\Documents> cd my-project

You told it to move into your Documents folder, make a folder called my-project, and move into that folder. That is the whole idea.

Python

Python is a programming language, which is a way to write instructions a computer can follow. If English is how you talk to people, Python is one way to talk to computers, and it reads closer to English than you would expect. Python runs the scripts behind the data pipeline. You will not write it. The AI writes it and you run it. A first line of Python looks like this:

print("Hello, World!")

That prints the words Hello, World! to the screen. To check whether Python is already on your machine, open Command Prompt and type python space dash dash version. A line like Python 3.11.4 means you are set.

GitHub

GitHub is a website that stores your code and records every change you make to it. Picture a version of Google Docs for code that saves a labelled snapshot each time you decide to, so you can walk back to any earlier state. You need it because Vercel watches your GitHub and rebuilds the site whenever you send new code up. A repository is the project folder. A commit is a saved snapshot. A push sends your commits to GitHub. Sending up a change looks like this:

git add .
git commit -m "Added email signup form"
git push

Three commands, and your change is saved, documented, and uploaded.

Notepad and VS Code

A text editor is where code files get written and changed. Notepad already ships with Windows and needs no setup, so you can open any code file with it. VS Code is a free upgrade that colours the code so mistakes stand out and suggests the next few characters as you type. I began with Notepad because it was already there, and I moved to VS Code once I wanted to see more of a file at a glance.

Node.js

Node.js is a program that runs JavaScript on your computer. Python runs Python scripts, and Node.js runs JavaScript ones, which matters because Astro and Sanity both sit on top of it, and so does the tool I lean on most. You install it once and forget it is there. To check, type node space dash dash version and npm space dash dash version in Command Prompt, and you should see version numbers come back.

Astro

Astro is a framework for building websites. Buying IKEA furniture is a fair comparison, because you assemble a site from ready-made parts instead of cutting every board yourself. Astro is faster than the heavier options for a content-first site, it treats each file in the pages folder as a page on the site, it works cleanly with Sanity, and it is free and open source. A small Astro project looks like this on disk:

my-website/
src/
pages/
index.astro (becomes yoursite.com/)
about.astro (becomes yoursite.com/about)
components/
public/
package.json

Every file under the pages folder becomes a web address on its own, with no routing to configure.

Sanity CMS

Sanity is a content management system, the place where you write and organise blog posts without touching code. It gives you the friendly editor people like about WordPress and skips the plugins, the security holes, the hosting, and the database that come with it. It is free for a small team. You open Sanity Studio in your browser, see your posts listed down the left, and edit them in a clean panel on the right.

Vercel

Vercel is a company that hosts your website for free and makes it reachable to anyone. Your site is built on your computer, and Vercel takes a copy and serves it to the world from fast machines placed around the globe. The free tier is generous, HTTPS is automatic, it connects straight to GitHub, and there is nothing to configure. When you push code to GitHub, Vercel rebuilds and redeploys on its own.

A finished deploy in Vercel looks like this.

Claude

Claude is an AI assistant from Anthropic that writes code and explains ideas in plain language, and it helps you find the cause when something breaks. Think of a patient developer sitting beside you at any hour, one you brief in plain English. In the browser at claude.ai I work out strategy and architecture and write instructions. It follows detailed instructions well, produces code I can rely on, holds a long conversation without losing the thread, and carries some memory across sessions. A paid plan runs a flat monthly fee.

Claude Code

Claude Code is the same Claude, moved into the terminal. Instead of living in a browser tab, it runs inside your project folder with permission to read and change the files and run commands itself. It reads any error straight from the output, so nothing gets copied between windows. It installs through npm, which is the reason you already put Node.js on your machine, and a single command adds it. It needs a paid Claude plan to run. This is the tool the Step-by-Step section below tells you to use, because for a beginner it removes the two parts people struggle with most, working out which file a snippet belongs in and copying text back and forth without a slip.

Step-by-Step: Build Your First Site

This is the exact path from nothing to a live website. Set aside three to four hours for the first run. You will move faster after that.

Part A: Set Up Your Computer, one time, about 45 minutes

1. You already have Notepad

Notepad comes with Windows. Press the Windows key, type Notepad, and press Enter. That is your code editor for now. You can move up to VS Code later from https://code.visualstudio.com/ when you want colour and autocomplete.

2. Install Node.js

Go to https://nodejs.org/, download the LTS version, run the installer, and accept the defaults. Node runs Astro, and it is also what installs Claude Code a few steps from now.

3. Install Python

Open https://www.python.org/downloads/, download the latest version, and check the box that adds Python to PATH before you click install. Python runs the data scripts.

4. Install Git

Head to https://git-scm.com/downloads, download the Windows installer, and run it with the defaults. Git tracks your code versions and talks to GitHub.

5. Configure Git

Tell Git who you are, so your name shows up in your commit history:

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

Part B: Set Up Your Accounts, one time, about 20 minutes

Create these accounts before you start building:

• GitHub at https://github.com/, sign up, and verify your email.
• Vercel at https://vercel.com/, sign up with your GitHub account, and authorise it.
• Sanity at https://www.sanity.io/, sign up with Google or GitHub.
• Claude at https://claude.ai/, create an account and take a paid plan, which the browser assistant and Claude Code both use.
• Buttondown at https://buttondown.com/ for email signups, and create your newsletter.

Part C: Install Claude Code, about 10 minutes

With Node already on your machine, open Command Prompt and run the single install command from the Claude Code page, then sign in with your Claude account. From here on you start it inside any project folder by typing its command, and it reads and changes the files in that folder for you.

Part D: Create your website, about an hour with Claude Code

Open Command Prompt, make a folder for your site, move into it, and start Claude Code. Then describe the whole first stretch of work in one go, with your decisions already made. Something like this:

Create a new Astro site in this folder, get it running locally so I can see it in a browser, set up a GitHub repository for it, and connect it to Vercel so it deploys when I push. I am on Windows. Explain each step in plain language before you run it, and stop and show me the result before you move to the next part.

In response, Claude Code creates the files, runs the commands, and shows you what happened at each stage. You approve each action before it runs, so control stays with you. When something breaks, it reads the error from its own output and fixes it, and you never take a screenshot.

Part E: Add Sanity CMS, about an hour with Claude Code

Once the site is live, start Claude Code in the same folder and tell it:

Add Sanity CMS to this Astro site so I can write blog posts in a visual editor. Create the Sanity project, define a simple post schema with a title, a body, an image, and a publish date, connect it to the site, and show me the Studio running before you finish.

It works through the project creation, the schema, the connection, and the running Studio, pausing wherever you need to make a call.

Part F: Add an email signup, about 30 minutes with Claude Code

Start Claude Code and tell it:

Add an email signup form to the homepage that posts to Buttondown for the username myusername. Put it in the footer and match the site styling.

It edits the real files, and you refresh the browser to see the form. Before you close the session, ask it to write down where things stand, so the next session starts with context. The next section covers what that note should hold.

How I Build Now

When I started, I worked with Claude in a browser tab. I read code in the chat, copied it into a file, ran the file, and pasted any error back as a screenshot. Every piece of information moved by my own hand, and each handoff was a chance to paste the wrong block or drop code into the wrong file. Claude Code changed where the work happens.

Claude Code runs in the terminal, inside the project folder, with permission to read and write the files and run the commands itself. You describe what you want and it edits the real files on your machine and runs them. You decide what it may run before it runs anything, so control stays with you. Because it reads errors straight from the output, nothing crosses between windows.

The sequencing surprised me. In a chat window, asking for one small thing at a time is the right instinct. An agent in the terminal turns that around, because it can carry a much larger task in a single pass. Ten narrow prompts in a row give the model ten chances to lose the thread of what you are actually building, and give you ten moments to wave through a step that has quietly drifted off course. The stronger move is to batch the whole arc of work into one prompt, with the judgment calls decided up front and written into the prompt. Set explicit stop conditions so it halts instead of inventing new scope. Require it to check its own work and hand back the raw evidence, the actual command output and counts, rather than a tidy sentence claiming success.

I run the whole thing as a relay. I use claude.ai for the strategy and the architecture, and to write the prompt that Claude Code will execute. Claude Code runs that prompt against the repository and changes the code. The result then goes back to claude.ai for an audit, a fresh read by a model that did not just do the work. Every stage is handled by a model that is not grading its own homework.

[IMAGE PLACEHOLDER: the claude.ai to Claude Code to audit relay, showing strategy and the prompt written in claude.ai, the prompt executed by Claude Code against the repository, and the output returned to claude.ai for an independent audit]

The shape of it looks like this. When I want the pipeline to reclassify a batch of companies under a revised set of categories, I do not ask for the change and then watch it work. I write out the new categories, name the exact table to update, give the rule for the close calls, and tell it to stop after a first slice so I can inspect the results before the rest runs. I ask it to report the count in each category and the number of rows it left untouched. One run showed a single category swallowing far more rows than it should, which pointed straight at a rule I had written too loosely. I fixed the rule rather than the data, then let the rest run.

That audit earns its place. An agent reporting its own success is worth very little on its own. When Claude Code tells me a job worked, I ask for the exact query it ran and the output that query returned. I ask for the per-class counts and the column totals that would have to be true if the claim held up. A model that has to show its numbers has a much harder time being confidently wrong. The check costs a couple of minutes, and it has caught real errors that a confident summary would have buried.

One warning comes with the power. Claude Code will happily rewrite files you never meant it to touch, and it will do it fast. Stopping that, and giving each new session enough context to make good calls without me standing over it, is the job of the project files.

The Project Files: How Every Session Starts Already Knowing

Every new session starts from nothing. A fresh browser chat knows nothing about my project. A fresh Claude Code session knows nothing either. Neither one knows a rule I learned the hard way early on, or why a tempting shortcut is actually a trap. The model also does not know what it does not know, so it will walk straight into the same mistake with real confidence and a well-formatted explanation. A lesson that took me weeks to learn is worth nothing to the next session unless it is written down where that session will read it.

A single handoff note helps with continuity. At the end of a working session I can ask the model to summarise where things stand, and I save that. The trouble is that a handoff note captures one day. Read it a month later and it tells you what I was doing that afternoon, and almost nothing about the rules the project runs by.

The fix turned out to be plain. I keep a small set of markdown files in the repository, and every session reads them before it touches anything. The whole set stays short enough to skim, and each file has one job:

• CLAUDE.md holds the operating rules, the do-not-break rules, and the environment gotchas that bite once and never again once they are written down.
• ARCHITECTURE.md explains how the system fits together, so a session can reason about a change instead of guessing at it.
• PROJECT_MEMORY.md records the decisions and the reasoning behind them, so I never re-argue a call I already settled.
• OPERATIONS_MEMORY.md covers how to run things and what has broken before, with the procedures I have actually checked.
• BACKLOG.md lists what is open, ordered by value, with the evidence for why each item earns its spot.
• A dated handover file holds the current state of play, written to stand on its own and meant to be read first.

The dated handover ties the rest together. It states the read order at the top, so a cold session knows which file to open and in what sequence before it changes any code. A model that reads them in order arrives with roughly the context I carry in my head.

[IMAGE PLACEHOLDER: the read order of the project files, showing CLAUDE.md, ARCHITECTURE.md, PROJECT_MEMORY.md, OPERATIONS_MEMORY.md, BACKLOG.md, and the dated handover feeding a new browser chat and a new Claude Code session before either one touches the code]

A fair question is why I keep this in plain files rather than loading it into Claude's Projects feature, which also holds background knowledge. Git versions the files, so I can see exactly when a rule changed and read the commit that explains why. Claude Code reads them with no setup, because they already sit in the folder it works in. The files travel with the code as the same kind of artifact, reviewed the same way as everything else, and they work whether I am in the browser or the terminal, and in any editor that opens a text file. I have switched laptops and tools more than once, and the files came along each time with no migration. The Projects feature has its own strengths as a home for reference material that is not tied to a particular commit.

The discipline is the hard part, and I want to be plain about it. The system only works if I write the rule down the moment I learn it, while the pain is fresh and the reason is obvious. I keep the evidence that produced the rule right next to it, the error message or the query result, so a later reader can trust the rule instead of taking my word for it. When a rule gets replaced, I mark the old one as superseded and leave it in place, because the reason it changed is usually the exact thing I need to understand later. The payoff shows up months on, when a session I never watched picks up a rule I wrote in a hurry and makes the right call without me in the room.

There is a real cost to this. The files grow. One of mine has grown long enough that a model cannot read it fresh at the start of every session, which is what the dated handover is for. It distils the current state down to a single page, so a new session reads one focused document and pulls in the deeper files only when it needs them. I trim it when it gets noisy, and I fold anything still true back into the permanent files, so nothing important lives only in the handover.

One clarification before you build this. What I am describing sits apart from Claude's built-in Projects feature, which has real uses of its own. I have a separate post coming on how to use Projects well and where each approach fits.

AI Will Solve the Wrong Problem If You Let It

The most important thing I learned has nothing to do with any tool. An AI wants to solve the problem directly in front of it. It does not step back and ask whether that is the problem worth solving. You have to do that part.

Here is what it cost me to learn. I was building a tool to pull the services a company sells out of its website. The first version returned a pile of junk alongside the real services, so I asked Claude to help me filter the junk out. It gave me a filter that skipped anything shaped like a button. That cleared some of it. New junk appeared, so it gave me a second filter for text under a few words. More appeared. A filter for navigation menus. Another for footer text. This went on for weeks, one filter after another.

By the end I had eighteen filters and 847 lines of pattern-matching logic, and I was proud of how clever it had become. Then I ran it against real competitor sites. The filters rejected almost everything as noise, including the actual services I needed. On real sites the whole thing scored 43% accuracy. Every fix broke something else. Block the phrase Schedule a Demo and you also block Managed Demo Environments, which is a real product. I was playing whack-a-mole with no end in sight.

One day I stopped and asked myself why I kept adding filters. The answer was obvious the moment I said it out loud. Rules cannot understand context. The word Platform on its own is noise. The phrase Analytics Platform is a real product. No amount of pattern matching tells the two apart, because the difference between them is meaning.

What worked was to let an AI read the text, since it weighs context the way a person does. I deleted all 847 lines of filter logic and replaced them with a single clear prompt. The accuracy climbed far past anything the filters had reached. The lesson stuck with me. Your job is the strategy, which means holding the why and the what in your head, deciding which problem is even worth solving, and pointing the work at it. The AI does the building, and it does it fast, whatever you point it at. The value you add is the aim.

What I Learned the Hard Way

A few habits carried the most weight, and none of them are technical. The biggest lesson, that you own the strategy while the AI does the building, has its own section above, so I will not repeat it here.

Commit constantly

After every change that works, save it to GitHub with git add dot, a git commit carrying a short message, and a git push. It takes ten seconds, and it has saved me hours of redoing work I broke by accident.

Name your sessions

After a few weeks I had dozens of browser conversations and terminal sessions, and finding the one where I set up Sanity meant scrolling forever. Now I name each session the moment I start it, something like Growthfornuts Brand Setup, so I can find it again later.

Walk away when stuck

Sometimes I circle the same error for an hour, trying the same fixes and getting angrier at the screen. The move that works is to leave. Get a coffee, come back in half an hour, and the obvious mistake is usually sitting right there. Fresh eyes have saved me more times than I can count.

Let the tool set the size of your ask

In a plain chat, ask for one small thing at a time. With Claude Code in the terminal, hand it the whole arc of a task in one prompt with your decisions already made. Each tool wants a different size of request, so I let the tool set it rather than forcing my old habit onto the new one.

Running Models Locally: What Stopped Me

I wanted to run the extraction model on my own laptop at first. No API bills, and the data would never leave my machine. I installed Ollama, a tool that runs open models locally, and downloaded one to try.

Then I waited. The first test took about ten minutes to get through ten items, and at that rate a full run would have taken most of a day. When I checked, the model was running entirely on my CPU. My laptop has Intel integrated graphics, and the local acceleration Ollama uses needs an NVIDIA graphics card, which I do not have. On this hardware it was too slow to use.

I had two ways forward. I could buy a laptop with an NVIDIA card for a four-figure sum, or I could run the model through a cloud service instead of on my own machine. I went with the cloud. Groq offers a free tier and a choice of models, any of which would probably have handled the job, and it carried me through development.

Extraction runs on Claude now. I made that choice because I was already working with Claude directly every day and I had more confidence in it. That was a personal call, and I would rather say so plainly than dress it up as the result of a benchmark I never ran.

What's Next

This website proves the blueprint works, and it is a step toward something larger.

The goal is a tool that helps a small business owner keep track of the market. Behind it runs the pipeline I keep mentioning. As of the 26th of August 2026 it tracks 1,345 company websites across 33 B2B SaaS verticals. It reads each site, and a Claude model sorts what it finds into categories. I started that classification with a machine learning model and dropped it in May 2026, once the Claude approach did the job more simply.

The product around this pipeline is still being built, and it is not open to anyone yet. I will share the build as it goes, the wins and the dead ends alike. I wrote about the earlier machine learning stage of this story in Rules, AI, and ML Walk Into a Crawler. I also have a separate post coming on Claude's Projects feature and where it fits. All of it is built by vibe coding, the same way this site was.

If you want to follow along, subscribe below. A $20 Claude subscription is enough to change what you can build on your own, with no engineering background. The bigger bill only arrives once the work grows past a website, the way it did for me. You need the subscription and enough patience to describe what you want and to fix it when it comes back wrong. That is the whole entry fee.

Srinivas

Chief Nut @ Growth for Nuts