The popular advice says you need a bigger spec system. More templates. More markdown. More agent roles. I think that's backwards for most solo builders.
The May 2026 backlash against spec-driven development didn't come out of nowhere. Critics called it “waterfall with markdown,” “productivity trap,” “spec drift,” “frozen specs,” and “token-burning ceremony.” Those critiques land when the workflow turns into ritual and the code lags behind. Simon Willison has pushed hard on the risks of over-structuring AI coding. Birgitta Böckeler's taxonomy matters here too. Spec-first, spec-anchored, and spec-as-source are not the same thing. Addy Osmani's canonical 6-section spec format is useful, but a template alone doesn't save you from bloat. Thoughtworks Tech Radar, GitHub Spec Kit, Kiro, OpenSpec, Traycer, Vibe Kanban, and BMAD all sit somewhere on this spectrum.
A key question isn't whether specs are good. It's whether the workflow helps you ship when you're building mostly alone.
That's why this comparison matters. If you're looking for something lighter than Spec Kit, these three represent three very different answers. BMAD is community-driven and pattern-heavy. Get Shit Done (GSD) is a lean execution workflow with a strong Claude Code following. Tekk.coach is the odd one out: its loops find the work in your codebase and write the spec, and any coding agent builds it. Same broad category. Very different bets.
Table of Contents
- The Spec-Driven Backlash and the Search for What Works
- Tekk vs BMAD vs GSD A Side-by-Side Comparison
- When BMAD Wins The Community-First Approach
- When GSD Wins The Lean Claude Code Workflow
- When Tekk coach Wins The Integrated Platform for Solo Founders
- The Verdict How to Choose Your Workflow
The Spec-Driven Backlash and the Search for What Works
The backlash is real
The backlash is easy to understand. A lot of builders tried spec-driven workflows, then found themselves writing documents the model could admire but not execute cleanly. That's where the “waterfall with markdown” label comes from.
The hard part is that critics and advocates are often talking about different things. A bloated framework with too many gates is not the same as a lean planning habit. A static requirements doc isn't the same as spec-as-source, where the spec is the only artifact humans edit and code is generated from it, which makes drift visible instead of hidden, as described in this spec-as-source paper.
One of the clearest signs that this market is sorting itself out is adoption divergence. During the backlash period, one spec-driven framework grew 863% in six months while a competitor in the same category grew only 18%, according to this May 2026 YouTube analysis. That gap matters. It suggests builders are not rejecting structure outright. They're rejecting bad execution mechanics.
Practical rule: If your spec workflow burns more tokens explaining the process than building the feature, the workflow is the problem.
What builders actually need
Solo founders usually don't need more ceremony. You need one of three things.
- A thinking system: something that forces better requirements and catches architectural mistakes early.
- An execution habit: something that keeps the agent sharp over long sessions.
- A source of work: something that reads the codebase, finds what needs doing, and keeps it organized.
That's the lens I'd use for BMAD, GSD, and Tekk.coach.
The broader conversation in this Reddit thread on spec-driven development replacing vibe coding shows why lighter alternatives keep coming up. Builders want more reliability than raw vibe coding gives them, but many don't want the overhead of a heavyweight framework either.
So the better question isn't “Which framework is best?” It's this. What kind of failure are you trying to avoid? Wrong design. Rotten context. Or the work nobody noticed.
Tekk vs BMAD vs GSD A Side-by-Side Comparison
Comparison of Tekk.coach vs BMAD vs GSD
| Criterion | BMAD | Get Shit Done (GSD) | Tekk.coach |
|---|---|---|---|
| Integration scope | Framework and method | Workflow layer for AI coding execution | Loops that find the work and write the spec, on a board |
| Agent lock-in | More flexible, multi-agent patterns | Best fit if you live in Claude Code, though broader runtime support exists | Agent-agnostic: Claude Code, Codex, or Cursor builds the spec via the Tekk MCP server |
| Spec format weight | Heavier in full mode, lighter in BMAD Quick | Lean and operational | Short specs with acceptance criteria and a checklist; loops write them, or you write one by hand |
| Community model | Discord-first, community-led learning | Open-source, niche but active interest in Claude Code circles | Product-led experience |
| Codebase awareness | Depends on how you feed context | Not the main differentiator | Loops read what changed in your GitHub repo and follow it to what it touches |
| Learning curve | Higher if you use the full method | Lower if you want a disciplined execution pattern | Lower on methodology, different trade-off because it's a hosted platform |
| Kanban and workspace | Not the core value | Not the core value | Built-in board; a merged PR that says Closes TEK-123 closes the spec |
| Who it's for | Builders who want planning depth and community patterns | Claude Code pragmatists who want minimal framework | Solo founders who want the work found for them and every spec closed by a merge |
How to read the table
The biggest difference here is philosophical.
BMAD treats development like a coordinated team sport, even if the team is mostly synthetic. It's about roles, review, structure, and catching mistakes before they harden. That makes it attractive if architecture errors are what usually hurt you.
GSD treats the core problem as context degradation. That's a smart bet. Long AI coding sessions degrade imperceptibly. The agent starts strong, then gets fuzzy. GSD is built to stop that slide by keeping work broken into phases and fresh windows.
Tekk.coach sits in a different bucket. It's not a framework to memorize. Its loops find the work and write the spec. That matters if your problem isn't “how do I write a better spec template?” but “what in this codebase needs work next, while I'm shipping alone?”
A lot of confusion in this category comes from comparing a methodology, a workflow layer, and a platform as if they were the same product type. They're not.
A final nuance matters. There's a big difference between spec-anchored work and strict spec-as-source work. Most solo builders won't live in pure spec-as-source mode full time. They still need room for iteration and judgment. So don't choose based on ideology. Choose based on where your workflow currently breaks.
When BMAD Wins The Community-First Approach
BMAD is strongest when design mistakes are expensive
BMAD wins when you care more about getting the design right than getting to code fast.
That's not hand-wavy. In a comparative analysis, BMAD orchestrates over 12 specialized AI agents and scored 3.65 out of 4.00 overall, with 4 out of 4 in specification quality, which put it ahead of Spec-Kit on that dimension, according to this hands-on BMAD comparison. That tells you what BMAD is optimizing for. Better planning quality. More review. More chances to catch a bad call before it spreads through the repo.
That's why BMAD Full makes sense for complex work. If a wrong architectural choice will be painful to reverse, extra planning isn't waste. It's insurance.
A few BMAD traits stand out:
- Multi-agent team patterns: planner, dev, QA, and review roles make the process feel like a staffed project, not a single long chat.
- Adversarial review: this is one of BMAD's most useful ideas. It assumes the first answer may be wrong.
- BMAD Quick: a lighter path for smaller features. Same basic elicitation philosophy, less ceremony.
You can see the method's open-source base in the BMAD-METHOD GitHub repository, and the fact that a BMAD-SPEC-KIT integration repo exists says something important too. BMAD users are not dogmatic about one exact setup. They experiment.
Its real moat is the community
BMAD's biggest strength isn't just the prompt structure. It's that the method lives socially.
The BMAD Discord community is the clearest signal. BMAD is one of those frameworks where docs matter, but conversation matters more. If you learn best by watching other builders share prompts, argue over patterns, and debug weird edge cases together, this model fits.
That community-first shape is not trivial. Solo founders usually don't need another PDF. You need somewhere to ask, “Why did this architecture doc go sideways?” and get a useful answer. That's where BMAD often beats cleaner-looking tools with weaker user communities.
What works: BMAD is a strong fit if you want other builders around you while you learn the method.
There's a founder lesson in that too. Good systems spread through trust and repeated interaction, not just documentation. If you care about that dynamic outside tooling, Founder Connects' networking insights are worth reading because the same principle applies here. Strong builder networks reduce dumb mistakes.
BMAD isn't for everyone though.
- You may bounce off the weight: Full BMAD can feel like a lot if your project is small.
- The Discord-first model is a real trade-off: some builders want docs and deterministic flows, not community interpretation.
- It can tempt over-design: if you already know the feature is straightforward, deep planning can become delay.
If you want a broader look at lighter alternatives, this lightweight SDD frameworks comparison is a good companion read.
When GSD Wins The Lean Claude Code Workflow
GSD is built around context discipline
GSD wins when your main enemy is not bad product thinking. It's session decay.
That's why GSD has real traction. Get Shit Done has 58,900 GitHub stars, supports Claude Code plus 13 other runtimes like Cursor, Codex, and Gemini, and its latest stable release is v1.38.5 with an April 25, 2026 deployment date, as covered in this GSD overview on Augment Code. That level of adoption and active maintenance signals that this is not a toy workflow.
What makes GSD distinct is the execution model. It breaks work into atomic plans and pushes implementation into fresh context windows. The point is simple. Keep the main session clean. Push heavy lifting out. Don't let one giant conversation poison itself.
The practical appeal is obvious if you've ever watched a long Claude Code session slowly lose the thread. GSD treats that as the central design problem.
A useful practitioner view comes from this two-month Reddit retrospective on using GSD for spec-driven work. That thread is why I'd call GSD niche but real. It isn't just starred on GitHub. Builders are trying to live inside it.
Where it fits and where it does not
GSD is strongest for a specific builder profile.
- You already work in Claude Code or adjacent agent tooling
- You want a lean habit, not a heavy framework
- You care about clean execution history
- You're building something non-trivial, but still want low overhead
Its workflow has a sharp edge to it. The process is structured enough to keep you honest, but not so ornate that the process becomes the project.
The trade-offs matter too.
First, GSD is best understood as a workflow layer, not a full planning environment. If you want a built-in workspace, project board, or a persistent planning surface, that's not really its lane.
Second, while the ecosystem has widened, the center of gravity is still Claude Code culture. That's a strength if you're committed to that world. It's a limitation if you want a more neutral planning home.
GSD feels less like “adopt this methodology” and more like “stop letting your AI coding sessions rot.”
That's why I'd recommend it to pragmatists. Not framework hobbyists. Not people who want a big philosophy. People who want the agent to stay sharp and the git history to stay clean.
If Claude Code is your main environment, this guide to a planning tool for Claude Code is worth pairing with the GSD approach.
When Tekk coach Wins The Integrated Platform for Solo Founders
This is a platform, not a prompt framework
Tekk.coach wins when you don't want to assemble a workflow from prompts, docs, chat threads, and memory, or decide alone what needs doing. Its loops find the work and write the spec.
That distinction matters. BMAD and GSD are frameworks in different forms. Tekk.coach isn't a framework at all. The spec is its unit of work, not its category. The center of gravity is not “which slash command do I run next?” It's “what in this repository needs work, and who writes it down?”
The strongest differentiator is that loops write the spec from your code. Twelve loops (Security, Payments, Reliability, Testing and more) wake when your code changes, read what changed, and bring a proposal. Greenlight it and it becomes a spec on your board; decline it with a reason and the loops learn. Instead of asking the model to infer the system from your description, you start from the code that already exists.
That makes it especially useful for brownfield work. Most solo founders are not starting from a blank folder. They're adding a billing edge case, replacing a flaky auth flow, or untangling a half-working onboarding path.
What that means in practice
Tekk.coach fits a specific operating style.
- You connect GitHub, not a blank prompt: the loops start from the repo.
- You decide what gets built: each finding arrives as a proposal you greenlight or decline. You can also write a spec by hand on the same board.
- You keep your agent freedom: Claude Code, Codex, or Cursor builds the spec through the Tekk MCP server.
- Done means merged: a PR that says
Closes TEK-123completes the spec once its checklist is ticked, and that merge is the next change the loops read.
Those last two points need blunt clarity. Tekk never writes or ships code. Your coding agent does. PR linking is built for GitHub. If you want a framework that runs the whole build inside your agent session, or repo automation across multiple git hosts, that's not what this product is.
That honesty is important because otherwise the comparison gets muddy. Tekk is not trying to be BMAD's community engine or GSD's context-engineering layer. It's trying to find the work worth doing in your codebase and hand it to whatever agent you already use, for builders without senior engineering backup.
Boundary to remember: Tekk finds the work and writes the spec. You decide what gets built, and your coding agent builds it.
That makes it a better fit for solo founders who don't want to become framework operators. You want the work found for you, a board, and specs grounded in the repo. You do not want another methodology to babysit.
If your bottleneck is roadmap clarity rather than prompt mechanics, this piece on an AI product development roadmap aligns well with that mode of working.
The Verdict How to Choose Your Workflow
Pick based on your bottleneck
If you compare Tekk.coach vs BMAD vs Get Shit Done (GSD) as if one is universally better, you'll pick badly.
These tools answer different pain points.
BMAD is the right pick when you want a method that thinks like a staffed engineering process. It's strongest when architectural correctness matters, when you value adversarial review, and when you like learning inside a community. If you want the most help thinking through complexity, BMAD is hard to ignore.
GSD is the right pick when your agent works well at first, then falls apart halfway through the feature. It explicitly engineers context reliability through discrete phases in fresh 200K-token windows while the main session stays at 30 to 40% usage, which is what enables atomic git commits and cleaner execution flow, as detailed in this GSD workflow breakdown. If you're a Claude Code-heavy builder who wants a lean system that fights context rot directly, this is the cleanest answer here.
Tekk.coach is the right pick when knowing what to build is the bottleneck. You want loops reading your codebase and writing the spec. You want a board where a merge closes the spec. And you don't want to lock yourself into one coding agent.
A simple decision tree
Start here.
Do you want a live community and a method that pushes planning depth?
Pick BMAD.Do you mostly live in Claude Code and want the lightest workflow that still imposes discipline?
Pick GSD.Do you want loops that find the work in your codebase and write the spec, and prefer to choose your coding agent yourself?
Pick Tekk.coach.
A few sharper calls help.
- Choose BMAD if your biggest fear is making the wrong system decision early.
- Choose GSD if your biggest fear is losing quality over long AI coding sessions.
- Choose Tekk.coach if your biggest fear is the work you never noticed: the auth gap, the retry that charges twice, the changed code with no tests.
There isn't a clean winner because there isn't one job to be done.
If you're still sorting through the broader market, these companion reads help:
- the spec-driven development landscape
- the Spec Kit vs Tekk vs ChatPRD comparison
- the Tekk vs Traycer vs OpenSpec comparison
- the framework decision tree
My blunt take is this. Most solo builders don't fail because they lacked one more prompt template. They fail because their process breaks in one of three places. Thinking. Execution. Finding the work.
Pick the workflow that fixes the break you already have. Not the one that looks smartest on GitHub.
Tekk.coach is for the third camp. Connect your repo. The loops start on your next change.
Part of the Spec-Driven Development pillar — an honest playbook on shipping with AI coding agents. Its other half is loop engineering: a spec is how a loop knows it's done.