How I Vibe Code Apps end-to-end in a week.

· Sumanth Damma

In the last 3 months, I’ve vibe coded 3 projects and completed each one within a week. The secret wasn’t prompting better - it was thinking more clearly before I prompted at all.

These are the recent projects I vibe coded:

  1. Mi Diario - A speech-to-text journaling tool where I record my daily activity. The voice is transcribed and stored in my Notion journaling database.
  2. Cricket Top Trumps - A 2-player turn-based cricket card game.
  3. Gita Kavach - An Android app that blocks apps until I read a Bhagavad Gita sloka.

My workflow has two phases: planning and development.

Planning Phase

I start by listing down the requirements, the problem I am solving and the features I want to build. I make the effort to clearly define the features upfront so I don’t keep changing them during development.

Once I finalize the features, I open Google AI Studio and have a focused conversation about the tech stack, architecture and system design of the app.

After this conversation, I ask the model to create a Software Design Document (SDD). The document covers:

  • Project introduction
  • Tech stack
  • Detailed feature descriptions
  • System architecture
  • Database design

Once the SDD is ready, I open a new chat and give it the document with one instruction: flag anything missing or ambiguous. A fresh context gives an unbiased review - the new thread has no attachment to the decisions made in the first one. I take these inputs back to the original thread and ask it to improve the SDD. I go back and forth between the two threads a few times before I finalize the document.

For Gita Kavach, since it is a mobile app, I first created the UI designs using Claude Sonnet - building artifacts for each screen in HTML and CSS. Then I worked on the architecture: a layered structure with Presentation, Service, Repository and Backend layers, with BLoC and Cubit for state management. All of this went into the design document before a single line of code was written.

Development Phase

I prompt Claude Opus 4.5 to build the project based on the SDD. In all 3 projects, the model built a working app in the first run - a direct result of having a clearly defined design document going in.

After the model generates the code, I thoroughly test it. I then take time to understand business logic and how each component works inside the app. I try get to a good idea of the models, business logic and app flow. This helps me to add new features to the application easily.

If I have to add a new feature, I ask the model to create an feature implementation plan. I review the plan carefully and push back if something feels off or over-engineered. It is important to not implement the model’s plan directly. Understanding the existing codebase helps you see how a new feature integrates with what’s already there - and that’s what gives you the right questions to ask.

In one instance during Gita Kavach, Claude suggested using a Drift database to store app data locally. After reviewing the plan, it felt over-engineered - app cache was sufficient for what I needed. Pushing back on this kept the app simple and easier to implement. Once I am satisfied with the plan, I ask the model to implement it.

I maintain the SDD and feature plan documents in a folder inside the project. I haven’t written formal documentation yet, but these docs are a solid foundation when I get to it.

I iterate on the above process to complete the full app development.

The models are exceptional at coding. For me, a well-structured SDD and a reviewed feature plan are what made shipping in a week consistently possible - not just prompting better, but thinking more clearly before you prompt at all.