From $0 Stack to AI-Driven MVP: How Claude Code + Get Things Done Changed My Workflow

I Build at $0

I’m a broke developer.

Most of my apps cost me nothing to build. I use free tools, free tiers of third-party services, and open-source software whenever possible. Even my hosting is free. The only thing I pay for consistently is my domains—and those are yearly.

The reason is simple: my side projects are for learning and improvement. Unless I’m building a serious SaaS product, I don’t want overhead. Learning should be accessible. So I’ve always made sure my hobby projects cost exactly $0.

That changed when I subscribed to Claude Pro.

Why I Subscribed to Claude Pro

In my workflow, I don’t rely heavily on AI for full implementation. I mainly use it for:

• Brainstorming
• Debugging
• Planning
  

Even then, I constantly hit the free-tier limit and had to switch back and forth between platforms.

Claude Pro gave me access to Claude Code, and I was genuinely hyped. I imagined a smoother workflow, tighter integration, and better planning directly from my laptop.

Then I realized something:

I had never vibe-coded an entire app from scratch.

Discovering Get Shxt Done (GSD)

I found a GitHub repository called Get Shxt Done, a lightweight, spec-driven development and context-engineering system built specifically for Claude Code.

It’s created by TÂCHES, a solo developer focused on execution over over-engineering. GSD is built for solo developers—the kind who just want to ship.

Some bold claims from the creator:

"If you know clearly what you want, this WILL build it for you. No bs."

"I've done SpecKit, OpenSpec and Taskmaster — this has produced the best results for me."

"By far the most powerful addition to my Claude Code. Nothing over-engineered. Literally just gets shxt done."

That sounded like gold to me.

I’m a developer. I know what I want. So I dove in.

Setup

Inside a fresh folder, I ran:

This generated the scripts and agents Claude needs.

Then I started Claude in that directory using:

This overrides permissions mode, as recommended in the documentation.

How GSD Works

The entire workflow revolves around this loop:

Discuss → Plan → Execute → Verify

1. Initialize Project

One command. One structured flow.

The system:

1. Questions – It keeps asking until it fully understands your idea: goals, constraints, tech stack, edge cases.
2. Research – Spawns parallel agents to investigate the domain (optional but recommended).
3. Requirements – Defines what’s V1, V2, and out of scope.
4. Roadmap – Creates phases mapped to requirements.
   

You approve the roadmap. Then you’re ready to build.

2. Discuss Phase

This is where you shape the implementation.

A roadmap phase usually contains just one or two sentences. That’s not enough context to build something the way _you_ imagine it. This step captures your preferences before planning begins.

The system analyzes gray areas depending on what you’re building:

• Visual features → layout, density, interactions, empty states
• APIs/CLIs → response format, flags, error handling
• Content systems → structure, tone, depth
• Organization tasks → grouping, naming, duplicates
  

This step ensures the build aligns with your vision—not just generic implementation.

3. Plan Phase

The system:

1. Researches– Investigates how to implement the phase based on your decisions.
2. Plans – Creates 2–3 atomic task plans in structured XML.
3. Verifies – Checks plans against requirements and loops until they pass.
   

Each plan is small enough to execute within a fresh context window. No degradation. No “I’ll be more concise now.”

4. Execute Phase

The system:

1. Runs plans in waves (parallel where possible, sequential when needed).
2. Uses a fresh context per plan—large token allocation dedicated purely to implementation.
3. Commits per task—each task becomes its own atomic Git commit.
4. Verifies against goals to ensure the phase delivers what was promised.
   

You can literally walk away and return to completed work with a clean Git history.

5. Verify Work (My Favorite Part)

This acts as a User Acceptance Testing (UAT) phase.

Automated verification ensures code exists and tests pass. But this step checks whether the feature behaves the way _you_ expect.

The system:

1. Extracts testable deliverables.
2. Walks you through them one by one (“Can you log in with email?”).
3. Diagnoses failures automatically by spawning debug agents.
4. Creates fix plans ready for re-execution.
   

If something breaks, you describe the issue or simply rerun execution with the generated fix plans.

It’s structured, iterative, and brutally systematic.

My Project Status

I used Claude Code + GSD to build a personal finance tracker app.

The roadmap included 8 phases. We’ve completed Phase 6, and it’s currently waiting for my command to proceed to Phase 7.

Ironically, I’m writing this blog because I’ve already hit my weekly usage limit. It resets in three days.

Pros & Cons of Claude Code + GSD

Pros

1. Levelled-up vibe coding
   I can focus on branding, marketing, and system design while the implementation runs.
2. Self-correcting execution
   If an implementation becomes too complex or incorrect, it adjusts. It genuinely feels like it’s reasoning through trade-offs.
3. Systematic workflow
   Every phase requires structured discussion and planning before execution.
4. Feels like a real coding partner
   This is the biggest shift. It doesn’t feel like autocomplete. It feels like working with an experienced developer.
   

Cons

1. Token-heavy
   I’m using Sonnet 4.6 under Pro, and planning phases consume tokens rapidly because of research agents. After Phase 3, I was already at 71% weekly usage. (To be fair, I didn’t start at 0%.)
2. Model lock-in (likely)
   I haven’t tested this fully, but it seems you can’t change the model mid-phase. Whatever you set during initialization may persist until the project ends.
   

Conclusion: Should You Use This?

For building MVPs fast? Yes.

It creates real opportunities to ship quickly. The workflow itself is impressive—I’m considering adopting the same structured process in my manual development work.

Would I use it again? Absolutely.
Would I recommend it? Yes—but not to beginners.

If you’re just starting out, this will do everything for you. You won’t struggle. You won’t debug deeply. You won’t build the mental models that make you a strong developer.

If your goal is to learn development, build projects yourself first. Use AI as support—not as the driver.

But if you already know what you’re doing and want to move fast?

This setup just gets it done.