This week I had the opportunity to build a complete navigable prototype of a SaaS system using Claude Code with an approach I want to share: specialized subagents. The system in question was a platform with multiple user profiles, personalized dashboards, service marketplace, and integrated payments. I can’t get into the business rules details for client confidentiality reasons, but I can share the process and especially the learnings I had.
To contextualize: we’re not talking about a functional system with a real backend, but rather a high-fidelity navigable prototype with structured mocked data in JSONs. Even being mock, the code quality and structure allowed validating the entire UX and system flows realistically. And the best part: all of this came out in exactly 3 hours of vibe coding.
The Winning Setup: 4 Subagents + PRD
The main trick that made all the difference was structuring development by simulating a real product team. Before writing any line of code, I asked Claude to create four specialized agents:
- Project Manager: Responsible for breaking requirements into actionable tasks and maintaining business vision
- Tech Lead: Defines technical standards, architecture, and validates solution feasibility
- Developer: Implements features following established standards
- QA: Validates if implementations meet acceptance criteria
Along with the agents, I requested the creation of a complete PRD from an initial input with the system scope. Claude generated a structured document with all modules, functional and non-functional requirements, user journeys, and even success metrics.
Most importantly: I customized each agent to follow the boilerplate I already had ready. This ensured all implementations followed project standards from the start.
The Workflow That Worked
With the agents created, I moved to incremental planning:
- Task Planning: Asked the PM agent to decompose the PRD into specific tasks with clear acceptance criteria
- Iterative Development: For each task, requested implementation following Tech Lead standards
- Continuous Validation: After each implementation, validated the result and requested corrections when necessary
- Automated Commits: Even commits were done by Claude Code, following message conventions
I did vibe coding from start to finish. Claude Code was responsible for writing code, creating components, structuring mocked data in JSONs, making commits, and even resolving conflicts. My role was mainly as reviewer and director, validating if implementations were on the right track.
The result in 3 hours was a high-fidelity navigable prototype with:
- Mocked multi-profile authentication system
- Personalized dashboards with JSON-structured data
- Functional marketplace with listing and filters
- Navigable scheduling and contracting flows
- Responsive and consistent interface
- Transitions and states that simulate a real system
The Mistakes That Cost Tokens
Now comes the important part: the mistakes I made that cost me unnecessary time and tokens.
1. Dark Mode with Hardcoded Colors
The first mistake was not specifying from the start how dark mode should be implemented. Since I didn’t make it explicit that CSS variables should be used, Claude created all styles with fixed colors in components. When I noticed and asked to refactor using CSS variables, I had to spend a significant amount of tokens to fix something that could have been done right from the beginning.
The lesson here: technical guardrails need to be specified before, not after. If you have a preference on how something should be implemented, put it in the agents’ prompts or at the start of development. It’s much cheaper to prevent than to fix.
2. Components Without Reusability
The second mistake was similar: I didn’t explicitly ask Claude to reuse components whenever possible. Result? Several duplicated components with small variations that could be a single parameterized component.
When I asked for refactoring to consolidate components, again I spent tokens that could have been saved if I had established this guideline in the Tech Lead from the beginning.
The Golden Rules I Learned
After this experience, I arrived at some practical rules for anyone wanting to use subagents with Claude Code:
-
Define all technical guardrails BEFORE: Style patterns, code conventions, implementation preferences. All of this should be in the agents’ prompts before starting implementation.
-
Be specific about reusability: If you want components to be reusable, say it explicitly. If you want to avoid code duplication, make it clear. Claude is great at following guidelines, but they need to exist.
-
Customize agents for your context: Don’t use generic agents. Adapt each one to your project’s boilerplate, stack, and standards.
-
Validate incrementally: Don’t let Claude implement 10 features to only review later. Validate task by task, this avoids error propagation.
-
Document technical decisions: When making a decision about how something should be implemented, document it in the agents’ prompts. This ensures consistency throughout the project.
Is It Worth It?
Absolutely. Even with the mistakes I made, productivity was absurdly higher than it would be in traditional development. A high-fidelity navigable prototype that would take weeks to build manually was ready in 3 hours, and with superior quality to what I could achieve alone in the same time.
It’s important to emphasize: we’re talking about a mocked prototype, not a functional system with backend. But the structure was so well done that the transition to real implementation would be direct. The JSONs follow the real data structure, components are ready to consume APIs, and flows reflect exactly how the final system should work.
The secret is not letting Claude Code do everything alone, but rather structuring work so it can operate with autonomy within well-defined guardrails. It’s like having a team of developers that executes perfectly what you specify, but needs clear specifications.
The subagents were fundamental in this dynamic. They created a mental structure that kept development organized and consistent. The PM ensured everything was aligned with business, the Tech Lead maintained technical quality, the Dev executed efficiently, and QA validated deliveries.
If you already use LLMs for development but haven’t experimented with working with specialized subagents, I strongly recommend it. The difference is tangible, especially in larger projects where consistency and organization make all the difference. And even for mocked prototypes, the speed and quality you achieve are impressive.
And remember: specify your guardrails BEFORE starting. Your future self will thank you.