When people ask me how I build apps at RatataLabs, they usually expect me to name a single tool — some magic IDE or framework that does everything. The reality is that building production-quality vibecoded apps is not about one tool. It is about a workflow — a sequence of stages where different tools excel at different jobs. Trying to do everything in one place leads to compromises at every stage. Prototyping in a full IDE is overkill. Writing production code in a playground is reckless. The trick is knowing when to switch.
Over the past year of building HevyDuty AI, Plokk, SimplBiz, and EdImport, the workflow has evolved into three stages that balance speed with quality: prototype in Google AI Studio, manage everything through GitHub, and build production code with Codex. Earlier RatataLabs sessions leaned heavily on Claude-based coding flows; the current workflow has moved to Codex for codebase inspection, implementation, testing, and release preparation. Each stage has a clear purpose and a clear exit point.
Every project at RatataLabs starts in Google AI Studio. Not in a code editor, not in Figma, not with a requirements document — in Google AI Studio. The reason is simple: AI Studio lets me have a conversation with Gemini about what I want to build and immediately see whether the AI can handle the core logic. Before I write a single line of code, I need to know if the AI piece of the puzzle actually works.
For HevyDuty AI, that meant testing whether Gemini could generate a structured workout program from a natural language description of someone's fitness goals, experience level, and available equipment. I spent about two hours in AI Studio crafting prompts, testing edge cases, and refining the output format. By the end of that session, I had a working prompt that reliably produced JSON workout data with exercises, sets, reps, and rest periods. I also discovered several failure modes — like the model suggesting exercises that require equipment the user said they do not have — and built guardrails directly into the prompt.
For SimplBiz, the AI Studio phase focused on receipt scanning. I uploaded photos of actual receipts — crumpled ones, faded ones, receipts in Slovenian and English — and tested whether Gemini Vision could extract the merchant name, date, total amount, and tax breakdown. Some receipts worked perfectly. Others needed prompt adjustments to handle unusual layouts. This prototyping phase saved me from discovering these issues deep into the codebase where they would have been much harder to fix.
The key insight is that AI Studio is not a code editor — it is a validation environment. You are not building the app here. You are answering the question: "Can the AI do what I need it to do?" If the answer is yes, you move on. If it is no, you either adjust your approach or pick a different project. This saves enormous amounts of time compared to discovering AI limitations after you have already built the UI, the database layer, and the deployment pipeline.
Once I have validated the AI component, I create a GitHub repository. Every RatataLabs project lives on GitHub from day one — no exceptions. Even if the project is a rough prototype, it gets a repo. The reason is not just version control (although that matters). It is that GitHub is the bridge between prototyping and production. It is where the project gets a name, a structure, and a history.
My initial commit is usually minimal: a README describing what the project does, the AI Studio prompts that worked (saved as markdown or a JSON file), and a basic project scaffold. For web apps, that scaffold is typically a Vite + React + TypeScript template with Tailwind CSS pre-configured. I have a template repo that I clone for every new project, which gives me a consistent starting point with my preferred directory structure, ESLint config, and Tailwind theme.
GitHub also serves as the coordination layer when I switch between machines or between development environments. I work on a desktop and a laptop, and sometimes I prototype on a different machine than where I do production development. Git push, git pull — the project is always in sync. Pull requests are overkill for solo development, but I still use branches for major features. If something goes wrong, I can always roll back. This discipline has saved me multiple times when a vibecoded refactor went sideways.
One habit I strongly recommend: commit early and commit often. When you are vibecoding, the AI sometimes makes sweeping changes across multiple files. If those changes break something, you want a recent commit to fall back to. I typically commit after every working feature addition — not at the end of the day, not when I "feel like it," but immediately after each thing works. A commit every 15-30 minutes during active development is normal for me.
- Create the GitHub repo immediately — even before writing real code
- Include your validated AI Studio prompts in the first commit
- Use a consistent project template (Vite + React + TypeScript + Tailwind)
- Commit after every working feature, not at the end of the session
- Use branches for experimental features so you can roll back cleanly
This is where the real development happens. Codex is now the main RatataLabs coding partner for production work. It reads the repository, follows the local patterns, writes focused patches, runs tests, checks browser behavior, and keeps the work tied to git. That full loop matters more than raw generation because most production work is not a blank page; it is a careful change inside an existing system.
What makes the current workflow work is the division of labor. Google AI Studio validates the core AI feature. GitHub gives the project history and rollback points. Codex handles implementation inside the real codebase, where it can inspect components, scripts, tests, routes, deploy config, and static output before changing anything. Instead of pasting context into a chat window, I let Codex read the project and make the smallest useful change.
The workflow looks like this: I open the project, describe the goal in natural language, and Codex investigates before editing. For simple changes — fixing a bug, adjusting a style, adding a field, or updating content — it can patch the right files quickly. For complex work, such as adding static prerendering or hardening AdSense content pages, Codex proposes a path, implements it, runs the local build, checks the browser, and iterates when the evidence says something is still weak.
The biggest advantage is the tight feedback loop. When a rendered page looks wrong, Codex can inspect the route, compare static HTML against hydrated React, update the source, rebuild, and test again. That is the workflow RatataLabs now uses: describe, inspect, implement, verify, commit, and deploy.
A concrete example is this RatataLabs site itself. When the site needed stronger AdSense readiness, the first version looked fine in Lighthouse but several non-homepage routes were still thin if a crawler read the static HTML before JavaScript ran. Codex inspected the build scripts, found the mismatch, and turned that into a build-time SEO gate instead of treating it as a one-off content edit.
The implementation happened in stages. Codex added static content for the homepage, Plokk guides, policy pages, app pages, and blog index. Then it expanded the check script so all sitemap URLs must have a real H1, H2 sections, canonical tags, and minimum crawler-visible word counts. When the first pass exposed `/explore` as too thin, Codex fixed the app parser, rebuilt, re-counted, and kept going until the whole sitemap passed.
Each iteration was tied to evidence: local tests, Vite build output, static word counts, browser checks, and console errors. Without that loop, it would be easy to ship a page that looks good to a human but still looks empty to a crawler. The AI compressed the investigation, but the decision-making still came from the actual site behavior.
After the build is clean, I commit to GitHub and deploy. The cycle is the same as before — describe, implement, test, commit, deploy — but Codex makes it easier to keep the implementation, verification, and release steps in one reliable flow.
After building four production apps with this workflow, here are the patterns that make the biggest difference. First, be specific in your prompts. "Add a blog section" is vague. "Add a /blog page that lists articles from a data file, with category filtering, following the same MPA pattern as the /explore page" gives Codex much more to work with. The more context you provide upfront, the fewer iterations you need.
Second, let the AI read before it writes. Before asking for a new feature, make sure Codex has inspected the relevant existing files. If it understands your patterns, naming conventions, and component structure, the generated code will be consistent with your codebase. Nothing is worse than AI-generated code that technically works but looks like it was written by a different developer with different conventions.
Third, do not fight the tools. If you find yourself constantly overriding the AI or rewriting its output, either your prompts are unclear or the task is not well-suited to vibecoding. Some things — complex state machines, intricate algorithms, performance-critical paths — are still better written by hand. Use vibecoding for the 80% of development that is standard CRUD, UI components, API integration, and boilerplate. Write the remaining 20% yourself.
Finally, deploy frequently. Firebase Hosting deployments take about 10 seconds. There is no reason to batch up changes. Deploy after every meaningful feature, test it live, and commit. This tight feedback loop is what makes vibecoding feel productive — you see your work in production within minutes of writing it, not days or weeks.
- Be specific in prompts — include file names, patterns to follow, and expected behavior
- Let Codex read existing files before generating new code
- Use vibecoding for the 80% (CRUD, UI, integration) and hand-write the 20% (algorithms, perf-critical code)
- Deploy after every working feature — tight feedback loops compound productivity
- Commit early and often — AI refactors can be sweeping, and you want rollback points
The reason Google AI Studio + GitHub + Codex works so well together is that each tool handles a different phase of the development lifecycle without overlap or friction. AI Studio validates feasibility before you invest effort. GitHub provides the backbone of version control and collaboration. Codex gives you an AI collaborator that understands your project, can run the local toolchain, and can verify the result before a deploy. No single tool tries to do everything, and switching between phases is clear.
This workflow is how RatataLabs is moving forward. HevyDuty AI, Plokk, SimplBiz, and EdImport were built through earlier AI-assisted iterations, and the public site now documents the current shift to Codex for ongoing development. The common thread is not any individual tool — it is the workflow that connects them. If you are starting your vibecoding journey, use a similar staged approach: validate with AI, scaffold on GitHub, build with an AI coding agent, and deploy continuously. The specific tools may change as the ecosystem evolves, but the principles of staged development with rapid iteration will remain.