How I (A Non-Coder) Found My Vibe Coding Stack. And Why You Probably Shouldn't Copy It?

How I (A Non-Coder) Found My Vibe Coding Stack

And Why You Probably Shouldn’t Copy It

A story about overcomplicating things, breaking stuff, and accidentally finding what works

Everyone Told Me I Needed a Stack

Before I wrote a single prompt, I was already overwhelmed.

I’d been lurking on Twitter, watching people build apps over weekends. I wanted in. So I did what any reasonable person does , I asked the internet where to start.

Big mistake.

The internet had opinions. Strong ones. You need Cursor. No wait, use Windsurf. Actually Bolt is better for beginners. Have you tried Lovable? Replit is underrated. Just use Claude. No, ChatGPT is better for code. Don’t forget GitHub Copilot.

I had a spreadsheet of tools before I had a single idea built.

I was treating finding a stack like a research project. Like there was a correct answer out there and I just needed to find it before I could start. This is, I now know, completely the wrong way to think about it. But it felt very responsible at the time.

So I Just Started Wandering

I didn’t pick my first tool scientifically. I picked it because someone mentioned it in a Reddit thread I was reading at 11pm.

That’s how this actually starts, by the way. Not with a plan. With curiosity and a tab open.

The first few tools felt wrong in ways I couldn’t fully articulate. Some felt like they were built for developers who already knew what a terminal was and were comfortable talking to it. Others felt like a maze, layers of options with no clear path for someone who just had an idea and wanted to build it.

I kept switching. I kept starting over. I kept wondering if I was too stupid for this or if I was just using the wrong tools.

The turning point came quietly. No dramatic moment. I just noticed one day that I’d stopped switching tools and started actually building things. Something had clicked , not because I’d found the perfect stack, but because I’d stopped looking for one.

The Thing I Got Wrong From the Start

I assumed the stack was the thing. That once I had the right combination of tools, building would feel natural.

What I actually needed to learn had nothing to do with tools.

It was how to think with AI. How to describe an idea clearly enough that something could be built from it. How to break a problem into pieces small enough to hand off one at a time. How to read an output and know whether it was right or just looked right.

Those are communication skills. Problem-definition skills. Marketing skills, honestly.

The tools are almost beside the point. Once you know how to think this way, you can pick up most tools in an afternoon. The thinking is the hard part. The stack is just furniture.

Fine. Here’s What I Actually Use

Since you’re going to ask: my stack emerged through experimentation and it’s embarrassingly simple. Six layers. Nothing exotic.

Idea Generation

Where the ideas come from before I write a single prompt. For me this is personal notes and Reddit, reading real conversations about real problems and noticing what keeps coming up.

AI Model , The Thinking Partner

The core of everything. This is what generates the code, explains what’s happening, and troubleshoots when things break. I use ChatGPT, Gemini, Claude, and NotebookLM depending on the task. No single one does everything best.

Editor / Environment , Where the Code Lives

The place where I actually interact with what’s being built. VS Code for most things, Antigravity when I want something lighter. Think of it as your workbench.

Where Things Run

How the thing actually becomes a thing you can open and use. Locally on my machine for experiments, Live Server for quick previews, GitHub for anything I want to keep or share, Vercel when I need it live on the internet fast.

Database , Where Information Gets Stored

Only needed when your tool has to remember something. Pocketbase for simpler projects, Firebase when things get more complex. I ignored this layer completely until I actually needed it.

That’s it. A typical session looks like this: I write out what I’m trying to build in plain language. The AI helps me generate a starting point. I test it. Something breaks. I describe what broke. We fix it. Repeat until it works or until I understand why it can’t.

It’s less like engineering and more like a conversation with a very patient collaborator who never judges you for not knowing what a dependency is.

Ok Then, Why You Shouldn’t Copy It?

My stack works for me because of how I think. I came from marketing. I’m comfortable with ambiguity, with testing, with not knowing the right answer before I start. I like breaking things and seeing what happens. I evaluate tools the way I evaluate campaigns, does this actually produce results, or does it just feel productive?

If you’re a different kind of thinker , someone who needs structure before they can move, someone who gets frustrated by things not working as expected, someone who wants to understand how something works before they use it , my stack might feel like chaos to you.

And there’s a practical problem too. The AI ecosystem is moving so fast that whatever I’m using today might be obsolete in six months. New tools appear constantly. The specific combination I’m recommending could be the wrong recommendation by the time you read this.

So copying my stack gets you my tools. It doesn’t get you the process I used to find them.

Steal This Instead

Before you pick any tools, ask yourself three questions.

• First: how comfortable are you with breaking things? If the answer is “not very,” you probably want a more guided, visual environment to start. If you don’t mind chaos, something with more control and flexibility will serve you better.
• Second: what are you actually trying to build? A quick prototype to test an idea is a different job to a full application with real users. Match the tool to the scope, not to what someone on Twitter says is best.
• Third: what’s your budget for exploration? Most tools have free tiers. Start there. Don’t pay for anything until you’ve broken the free version.

But underneath all three questions is a more important one: how clearly can you describe what you want to build?

Because that’s the real barrier now. Not the tools. Not the code. Not the stack.

The barrier is your own clarity. Your ability to take a fuzzy idea and make it specific enough to build. Everything else is just furniture you can rearrange.

The Accidental Architecture

Nobody plans their first stack. You stumble into it. You try things, break things, abandon things, and one day you notice that something is working.

My stack isn’t a recommendation. It’s a record of what survived my experimentation. The tools that made it through are the ones that fit the way my brain works , a curiosity-driven, break-it-and-see-what-happens, marketing-brain way of building things.

Your stack will look different. It should.

The goal isn’t to find the right tools. The goal is to start building something and let the right tools find you.

What’s the first tool you’re going to try?