How I Built This Site With Zero Coding Experience

The Real Starting Point

I am not a software engineer.

My background is business development, commercial strategy, and B2B partnerships. I understand systems, incentives, positioning, and execution. What I did not understand, at least formally, was modern web development.

For a long time I experimented casually. I had ChatGPT Pro subscriptions. I played around with one-prompt site builders like Lovable. I watched developers talk about working inside the terminal with Claude Code. I kept hearing about Cursor as a serious code editor for AI-assisted development.

But there was this resistance I couldn’t shake.

The terminal (you know, that black screen with the blinking cursor where MS-DOS used to live?) felt like “real developer territory.” Local environments felt intimidating. Git (don’t worry if that word means nothing to you yet, we’ll get there) felt abstract. And honestly, I didn’t know what I didn’t know, which made it hard to even frame the right questions.

I also realized something about the way most people interact with AI right now. We’re using these incredibly powerful tools the same way we use Microsoft Word or Google. Type something in, get something out. It works, but it’s consumption, not creation. I wanted to pull back the veil. I wanted to actually feel the learning curve, not just follow along as a consumer of someone else’s product.

Then something clicked. If I wanted technical fluency, not just technical output, I had to stop hovering at the surface and go one layer deeper.

This site is the result of that decision.

Why Not a Website Builder?

I looked at Squarespace, Wix, and WordPress. They’re legitimate tools. They’re optimized for convenience. And for a lot of people, they’re the right choice.

But I wanted something different:

Full control over the HTML structure and SEO
Performance measured in milliseconds, not seconds
Direct ownership of the codebase (the actual files that make up the site)
A workflow that teaches me how modern software is actually built
No recurring platform fees
A deployment pipeline I actually understand
A real learning curve with AI tools beyond the chatbot screen

Website builders abstract away infrastructure. That’s useful early on, but over time it creates what I started calling abstraction debt. That’s the gap between what your tools do and what you actually understand about what’s happening underneath.

I didn’t want to drag blocks around in a browser UI. I wanted to know what actually gets shipped to the browser. What happens during build time. How hosting works. What GitHub does. What a deployment platform like Vercel actually manages behind the scenes.

This wasn’t about saving money. It was about closing the gap between the tool and my understanding of it.

How the Stack Evolved

This site didn’t start where it is now. It evolved through three distinct phases, and each one taught me something the previous one couldn’t.

Phase 1: Rapid Scaffolding with Lovable

The very first version of this site was scaffolded in a single prompt using Lovable. That tool is extremely fast. You describe what you want, and it generates a functioning web application built on React (a popular framework that developers use to build interactive websites) and deploys it almost immediately.

For momentum, it’s ideal. You go from nothing to something in minutes. That first dopamine hit of seeing a real website with your name on it is genuinely powerful.

But rapid scaffolding is not the same as long-term architecture. The code it generates works, but it’s not yours in any meaningful sense. You can’t explain it, maintain it, or extend it with confidence.

So instead of staying inside Lovable’s hosted environment, I cloned the repository locally (basically downloaded a copy of the entire project to my computer), opened it in Cursor, installed Claude Code in the terminal, and started iterating directly on the codebase.

That shift, from browser abstraction to local control, is where the real learning started.

If any of that sounds intimidating, I get it. I was right there not long ago. Feel free to reach out if you’re trying to figure this stuff out. Happy to share what I’ve learned.

Phase 2: Claude Code, Cursor, and the Terminal

Here’s what each tool actually does in practice.

Claude Code runs inside your terminal as an AI pair programmer. If you’ve never seen it in action, here’s a quick walkthrough. It reads your entire project. It edits files, refactors architecture, generates new features, runs commands, and asks clarifying questions when it needs more context.

One of the most useful things it does is interview you about your project. It asks about goals, tech stack preferences, constraints, performance targets, SEO requirements, deployment strategy. Then it generates a file called PLAN.md (a Markdown file, which is just a simple text format for writing structured documents) inside your project that acts as persistent memory. Even when the context window resets between sessions (that’s the amount of conversation the AI can “remember” at once), it can reference that file and pick up exactly where things left off. It knows what the project is, what phase you’re in, what constraints matter, and what decisions were already made.

This prevents drift, which is what happens when an AI loses track of the bigger picture and starts making suggestions that don’t fit your project anymore. It’s a real problem, and having a persistent plan file solves it. It also forces you to think like a product manager, because precision in the plan directly improves the quality of what gets built. (I’m writing a deeper post on this architecture, how PLAN.md, CLAUDE.md, and planning mode all work together. Stay tuned.)

Cursor is the local development environment. Think of it as a souped-up text editor designed for code. It’s where the code lives on your machine. Where you stage and commit changes (save snapshots of your progress), inspect Git history, review diffs (side-by-side comparisons of what changed), and push to GitHub. If Claude Code is the engineer, Cursor is the workshop. Getting comfortable here is what takes coding from something abstract to something tangible.

Phase 3: Migration from React SPA to Astro

The original Lovable scaffold was a React Single Page Application. That works well for interactive apps, but for a personal brand website focused on SEO, content, fast load times, and blog indexing, a static site is the better architecture.

So we preserved the original Lovable code on a legacy branch (think of it as a saved copy of the project at a specific point in time) as insurance, then rebuilt the entire site from scratch on main using Astro.

What that actually meant in practice:

Replacing client-side routing with file-based static routing
Rebuilding React pages as Astro components that output pure HTML
Shipping minimal JavaScript to the browser
Moving rendering to build time instead of runtime

The reason this matters is concrete. Search engines index static HTML more reliably. Performance improves because less JavaScript runs on the client. Time to First Byte drops. Core Web Vitals improve. And for someone trying to build a strong search presence, these aren’t nice-to-haves. They’re the foundation.

Astro has this concept called selective hydration. Interactive components can still use React, but only where they’re actually needed. The experience timeline on the homepage, for example, is a React “island” inside an otherwise static page. Everything else ships as plain HTML.

The final frontend architecture:

Astro for static page generation
Tailwind CSS for styling
React only where interactivity is required (modals, mobile nav)
Minimal JavaScript shipped to the browser

This isn’t a style preference. It’s deliberate performance engineering.

If you’re reading this and thinking “I have no idea what half of these terms mean but I’m still following along,” good. That’s exactly how I felt six weeks ago. You’re closer than you think.

GitHub and Version Control

The project lives on GitHub. That gives me version history, branch safety, rollbacks, and deployment triggers.

Commits act as checkpoints. Branches act as safety rails. When we migrated from React to Astro, the old code was preserved on a separate branch before we touched anything on main.

That’s not just technical ceremony. It’s structured risk management. And it’s one of those things that sounds obvious after you learn it, but felt completely foreign before I started.

Deployment: Vercel + IONOS

Vercel handles deployment. It watches the GitHub repository, builds the site whenever changes are pushed, and hosts the static output globally. It also gives you preview deployments for branches, so you can test changes before they go live.

Hosting is effectively free at this scale.

The domain, scottkrukowski.com, is registered through IONOS, which also handles my email. The only fixed cost to run this entire site is about $10 a year for the domain. No recurring platform fees. No monthly subscriptions. Just a repository, a build pipeline, and a domain.

Every git push to main triggers an automatic build and deployment. The site is live within about a minute of pushing code.

The Workflow Today

Here’s how the full system fits together:

Lovable was used for the initial scaffold (now retired)
Cursor manages the local development environment
Claude Code handles architectural decisions and code generation
PLAN.md governs long-term direction and acts as project memory
GitHub stores version history and triggers deployments
Vercel handles hosting and auto-deploys from main
IONOS manages the domain and email

This is a real software workflow. Not a no-code illusion.

Building and Documenting in Parallel

One thing I baked into this project from the start: as features get built, the process gets documented. The same system that builds the site also produces the raw material for writing about how it was built.

The File Clarity™ case study is the first real example of this. It’s a project that was documented as it was built, with an interactive demo and a companion blog post. The build audit became the blog post. That’s the workflow now.

It makes publishing easier because the hard part, remembering what you did and why, is already captured before you sit down to write.

What This Proves

You don’t need to be a traditional engineer to operate at this layer.

But you do need a few things:

Systems thinking. Understanding how pieces connect, not just what each piece does in isolation. What does the code editor talk to? Where does the code go when you push it? What triggers the deployment? These connections are the architecture, and once you see them, software development stops feeling like magic and starts feeling like plumbing. (Good plumbing, but plumbing.)
Clear objectives. Knowing what you’re building and why, before you start building it.
Comfort with tradeoffs. Static vs dynamic. Speed vs features. Simplicity vs flexibility. These decisions shape everything.
Willingness to go deeper. Past the UI, past the abstractions, into the terminal and the code.

AI doesn’t remove the need for thinking. It amplifies it. The quality of what comes out depends entirely on the precision of what goes in. Your plan, your constraints, your workflow structure.

This site isn’t impressive because of the tools. It’s useful because I now understand how the tools fit together. And that understanding changes how I approach building everything else.

But here is the thing I keep coming back to. The tools are remarkable. They are also just tools. “Unless the Lord builds the house, those who build it labor in vain” (Psalm 127:1). I do not say that to be pious. I say it because I have watched people, myself included, get so absorbed in what AI can do that they forget to ask what it is for. The ability to build is a gift. What you build with it is the response to that gift.

If you’re a non-technical professional thinking about building something with AI tools, here’s the shortest version of what I learned:

Start fast. Scaffold quickly. That first dopamine hit of seeing something real is important. But don’t stop there. Peel back one more layer. That’s when this stops being a novelty and starts becoming a skill, a passion, a pathway to building whatever you want.

That’s where fluency begins. And once you have it, the real question is not “what can I build?” It is “what is worth building?” That question has an answer, but it does not come from the tools. It comes from the One who gave you the desire to create in the first place.

Want to understand the terms used in this post? Check out The Vibe-Coder’s Dictionary, a growing glossary built for non-technical builders.