How a product manager without a technical background built two pilots in a week with Claude and Kiro

A non-technical product manager without practical development experience described a case in which he assembled and deployed two working pilots in one week using Claude, Kiro, Figma Make and MCP servers. The story is interesting not only for the result itself, but also for how it changes the barrier to entry for launching first versions of a product without a full engineering team.

What the stack consists of

At the core of the flow is a division of roles between several AI tools. The author used Claude Sonnet 4.5 for discovery: audience, pain points, jobs-to-be-done, constraints and business value were uploaded there. The output included analytics, content and prompts for subsequent stages. Figma Make was responsible for frontend generation, while Kiro from Amazon handled assembly, architectural decisions and deployment. Supabase was used for the database, GitHub Pages for hosting, and MCP servers for context and tests.

• Claude Sonnet 4.5 — discovery, analytics, content and system prompt
• Figma Make — frontend generation for the pilot version
• Kiro — project assembly, decision documentation and deployment
• Supabase and GitHub Pages — database and publishing
• Context7 and Playwright via MCP — memory between sessions and basic e2e checks

This set is interesting because it doesn't attempt to force one tool to do everything at once. The author distributed tasks according to the strengths of each service, thereby reducing the amount of manual edits. By his estimate, the analytics and design phase alone saved about 40 hours — precisely because artifacts from discovery transferred to interface generation and then to assembly with minimal losses.

Flow step by step

The process began not with code, but with problem definition. For each product, a separate assistant in Claude was created, given full context: who the user is, what problem the service solves, what counts as value and what constraints cannot be violated. After this, the materials were transferred to Figma Make, where a frontend was generated without manual refinement. In the case, it was about two projects: a personal website for product consulting and a free agile tool that the author considers as an early alternative to Jira for startups.

The next step was passing the frontend and analytics to Kiro. The author highlights this tool as the center of the entire pipeline, because Kiro first formulates solutions in writing, and then implements them without jumping straight into code. After that, three MCP servers were connected: Context7 to maintain context between sessions, Supabase MCP for database schema and migrations, Playwright MCP to check critical user scenarios.

The final stage looked maximally practical: registering with GitHub and Supabase, creating a database, deploying to GitHub Pages and instructions for domain binding.

Where the bottlenecks are

The author states the main limitation directly: this flow works well for pilots and MVPs, but doesn't resolve quality issues on the path to full production. If the product is designed for high load, complex integrations or long-term support, the architecture still needs to be reviewed by a person. This especially applies to decisions that Kiro can make automatically: the article notes that some of them look questionable without basic technical review.

The same applies to context windows: Context7 helps not lose the thread of the project, but doesn't make the memory problem completely disappear.

"Vibe-coding is not a replacement for developers."

Another risk is related to testing. Playwright MCP, by the author's observation, confidently covers the happy path, that is basic scenarios, but doesn't eliminate the need to separately check edge cases. Therefore, the described stack looks like a tool for quick verification of a hypothesis and a predictable process for a non-technical product manager; its weakness is the need to bring in an engineer on time when the pilot starts turning into a real product.

What this means

The case demonstrates a shift in launch economics: today a product manager or founder can assemble a working pilot without hiring a team and weeks of preparation if they can clearly formulate requirements and assemble tools into a consistent flow. But that's also where the approach's limits lie: AI accelerates the first release, not the engineering discipline, when a product starts to grow.