Vibecoding A Production App

TL;DR I built and launched a recipe app with about 20 hours of work - recipeninja.ai

Background: I’m a startup founder turned investor. I taught myself (bad) PHP in 2000, and picked up Ruby on Rails in 2011. I’d guess 2015 was the last time I wrote a line of Ruby professionally. I’ve built small side projects over the years, but nothing with any significant usage. So it’s fair to say I’m a little rusty, and I never really bothered to learn front end code or design.

In my day job at Y Combinator, I’m around founders who are building amazing stuff with AI every day and I kept hearing about the advances in tools like Lovable, Cursor and Windsurf. I love building stuff and I’ve always got a list of little apps I want to build if I had more free time.

About a month ago, I started playing with Lovable to build a word game based on Articulate (it’s similar to Heads Up or Taboo). I got a working version, but I quickly ran into limitations - I found it very complicated to add a supabase backend, and it kept re-writing large parts of my app logic when I only wanted to make cosmetic changes. It felt like a toy - not ready to build real applications yet.

But I kept hearing great things about tools like Windsurf. A couple of weeks ago, I looked again at my list of app ideas to build and saw “Recipe App”. I’ve wanted to build a hands-free recipe app for years. I love to cook, but the problem with most recipe websites is that they’re optimized for SEO, not for humans. So you have pages and pages of descriptive crap to scroll through before you actually get to the recipe. I’ve used the recipe app Paprika to store my recipes in one place, but honestly it feels like it was built in 2009. The UI isn’t great for actually cooking. My hands are covered in food and I don’t really want to touch my phone or computer when I’m following a recipe.

So I set out to build what would become RecipeNinja.ai

For this project, I decided to use Windsurf. I wanted a Rails 8 API backend and React front-end app and Windsurf set this up for me in no time. Setting up homebrew on a new laptop, installing npm and making sure I’m on the right version of Ruby is always a pain. Windsurf did this for me step-by-step. I needed to set up SSH keys so I could push to GitHub and Heroku. Windsurf did this for me as well, in about 20% of the time it would have taken me to Google all of the relevant commands.

I was impressed that it started using the Rails conventions straight out of the box. For database migrations, it used the Rails command-line tool, which then generated the correct file names and used all the correct Rails conventions. I didn’t prompt this specifically - it just knew how to do it. It one-shotted pretty complex changes across the React front end and Rails backend to work seamlessly together.

To start with, the main piece of functionality was to generate a complete step-by-step recipe from a simple input (“Lasagne”), generate an image of the finished dish, and then allow the user to progress through the recipe step-by-step with voice narration of each step. I used OpenAI for the LLM and ElevenLabs for voice. “Grandpa Spuds Oxley” gave it a friendly southern accent.

Recipe summary:

And the recipe step-by-step view:

I was pretty astonished that Windsurf managed to integrate both the OpenAI and Elevenlabs APIs without me doing very much at all. After we had a couple of problems with the open AI Ruby library, it quickly fell back to a raw ruby HTTP client implementation, but I honestly didn’t care. As long as it worked, I didn’t really mind if it used 20 lines of code or two lines of code. And Windsurf was pretty good about enforcing reasonable security practices. I wanted to call Elevenlabs directly from the front end while I was still prototyping stuff, and Windsurf objected very strongly, telling me that I was risking exposing my private API credentials to the Internet. I promised I’d fix it before I deployed to production and it finally acquiesced.

I decided I wanted to add “Advanced Import” functionality where you could take a picture of a recipe (this could be a handwritten note or a picture from a favourite a recipe book) and RecipeNinja would import the recipe. This took a handful of minutes.

Pretty quickly, a pattern emerged; I would prompt for a feature. It would read relevant files and make changes for two or three minutes, and then I would test the backend and front end together. I could quickly see from the JavaScript console or the Rails logs if there was an error, and I would just copy paste this error straight back into Windsurf with little or no explanation. 80% of the time, Windsurf would correct the mistake and the site would work. Pretty quickly, I didn’t even look at the code it generated at all. I just accepted all changes and then checked if it worked in the front end.

After a couple of hours of work on the recipe generation, I decided to add the concept of “Users” and include Google Auth as a login option. This would require extensive changes across the front end and backend - a database migration, a new model, new controller and entirely new UI. Windsurf one-shotted the code. It didn’t actually work straight away because I had to configure Google Auth to add `localhost` as a valid origin domain, but Windsurf talked me through the changes I needed to make on the Google Auth website. I took a screenshot of the Google Auth config page and pasted it back into Windsurf and it caught an error I had made. I could login to my app immediately after I made this config change. Pretty mindblowing. You can now see who’s created each recipe, keep a list of your own recipes, and toggle each recipe to public or private visibility. When I needed to set up Heroku to host my app online, Windsurf generated a bunch of terminal commands to configure my Heroku apps correctly. It went slightly off track at one point because it was using old Heroku APIs, so I pointed it to the Heroku docs page and it fixed it up correctly.

I always dreaded adding custom domains to my projects - I hate dealing with Registrars and configuring DNS to point at the right nameservers. But Windsurf told me how to configure my GoDaddy domain name DNS to work with Heroku, telling me exactly what buttons to press and what values to paste into the DNS config page. I pointed it at the Heroku docs again and Windsurf used the Heroku command line tool to add the “Custom Domain” add-ons I needed and fetch the right Heroku nameservers. I took a screenshot of the GoDaddy DNS settings and it confirmed it was right.

I can see very soon that tools like Cursor & Windsurf will integrate something like Browser Use so that an AI agent will do all this browser-based configuration work with zero user input.

I’m also impressed that Windsurf will sometimes start up a Rails server and use curl commands to check that an API is working correctly, or start my React project and load up a web preview and check the front end works. This functionality didn’t always seem to work consistently, and so I fell back to testing it manually myself most of the time.

When I was happy with the code, it wrote git commits for me and pushed code to Heroku from the in-built command line terminal. Pretty cool!

I do have a few niggles still. Sometimes it’s a little over-eager - it will make more changes than I want, without checking with me that I’m happy or the code works. For example, it might try to commit code and deploy to production, and I need to press “Stop” and actually test the app myself. When I asked it to add analytics, it went overboard and added 100 different analytics events in pretty insignificant places. When it got trigger-happy like this, I reverted the changes and gave it more precise commands to follow one by one.

The one thing I haven’t got working yet is automated testing that’s executed by the agent before it decides a task is complete; there’s probably a way to do it with custom rules (I have spent zero time investigating this). It feels like I should be able to have an integration test suite that is run automatically after every code change, and then any test failures should be rectified automatically by the AI before it says it’s finished.

Also, the AI should be able to tail my Rails logs to look for errors. It should spot things like database queries and automatically optimize my Active Record queries to make my app perform better. At the moment I’m copy-pasting in excerpts of the Rails logs, and then Windsurf quickly figures out that I’ve got an N+1 query problem and fixes it. Pretty cool.

Refactoring is also kind of painful. I’ve ended up with several files that are 700-900 lines long and contain duplicate functionality. For example, list recipes by tag and list recipes by user are basically the same.

Recipes by user:

This should really be identical to list recipes by tag, but Windsurf has implemented them separately.

Recipes by tag:

If I ask Windsurf to refactor these two pages, it randomly changes stuff like renaming analytics events, rewriting user-facing alerts, and changing random little UX stuff, when I really want to keep the functionality exactly the same and only move duplicate code into shared modules. Instead, to successfully refactor, I had to ask Windsurf to list out ideas for refactoring, then prompt it specifically to refactor these things one by one, touching nothing else. That worked a little better, but it still wasn’t perfect

Sometimes, adding minor functionality to the Rails API will often change the entire API response, rather just adding a couple of fields. Eg It will occasionally change Index Recipes to nest responses in an object { “recipes”: [ ] }, versus just returning an array, which breaks the frontend. And then another minor change will revert it. This is where adding tests to identify and prevent these kinds of API changes would be really useful. When I ask Windsurf to fix these API changes, it will instead change the front end to accept the new API json format and also leave the old implementation in for “backwards compatibility”. This ends up with a tangled mess of code that isn’t really necessary. But I’m vibecoding so I didn’t bother to fix it.

Then there was some changes that just didn’t work at all. Trying to implement Posthog analytics in the front end seemed to break my entire app multiple times. I tried to add user voice commands (“Go to the next step”), but this conflicted with the eleven labs voice recordings. Having really good git discipline makes vibe coding much easier and less stressful. If something doesn’t work after 10 minutes, I can just git reset head –hard. I’ve not lost very much time, and it frees me up to try more ambitious prompts to see what the AI can do. Less technical users who aren’t familiar with git have lost months of work when the AI goes off on a vision quest and the inbuilt revert functionality doesn’t work properly. It seems like adding more native support for version control could be a massive win for these AI coding tools.

Another complaint I’ve heard is that the AI coding tools don’t write “production” code that can scale. So I decided to put this to the test by asking Windsurf for some tips on how to make the application more performant. It identified I was downloading 3 MB image files for each recipe, and suggested a Rails feature for adding lower resolution image variants automatically. Two minutes later, I had thumbnail and midsize variants that decrease the loading time of each page by 80%. Similarly, it identified inefficient N+1 active record queries and rewrote them to be more efficient. There are a ton more performance features that come built into Rails - caching would be the next thing I’d probably add if usage really ballooned.

Before going to production, I kept my promise to move my Elevenlabs API keys to the backend. Almost as an afterthought, I asked asked Windsurf to cache the voice responses so that I’d only make an Elevenlabs API call once for each recipe step; after that, the audio file was stored in S3 using Rails ActiveStorage and served without costing me more credits. Two minutes later, it was done. Awesome.

At the end of a vibecoding session, I’d write a list of 10 or 15 new ideas for functionality that I wanted to add the next time I came back to the project. In the past, these lists would’ve built up over time and never gotten done. Each task might’ve taken me five minutes to an hour to complete manually. With Windsurf, I was astonished how quickly I could work through these lists. Changes took one or two minutes each, and within 30 minutes I’d completed my entire to do list from the day before. It was astonishing how productive I felt. I can create the features faster than I can come up with ideas.

Before launching, I wanted to improve the design, so I took a quick look at a couple of recipe sites. They were much more visual than my site, and so I simply told Windsurf to make my design more visual, emphasizing photos of food. Its first try was great. I showed it to a couple of friends and they suggested I should add recipe categories - “Thai” or “Mexican” or “Pizza” for example. They showed me the DoorDash app, so I took a screenshot of it and pasted it into Windsurf. My prompt was “Give me a carousel of food icons that look like this”. Again, this worked in one shot. I think my version actually looks better than Doordash 🤷‍♂️

Doordash:

My carousel:

I also saw I was getting a console error from missing Favicon. I always struggle to make Favicon for previous sites because I could never figure out where they were supposed to go or what file format they needed. I got OpenAI to generate me a little recipe ninja icon with a transparent background and I saved it into my project directory. I asked Windsurf what file format I need and it listed out nine different sizes and file formats. Seems annoying. I wondered if Windsurf could just do it all for me. It quickly wrote a series of Bash commands to create a temporary folder, resize the image and create the nine variants I needed. It put them into the right directory and then cleaned up the temporary directory. I laughed in amazement. I’ve never been good at bash scripting and I didn’t know if it was even possible to do what I was asking via the command line. I guess it is possible.

After launching and posting on Twitter, a few hundred users visited the site and generated about 1000 recipes. I was pretty happy! Unfortunately, the next day I woke up and saw that I had a $700 OpenAI bill. Someone had been abusing the site and costing me a lot of OpenAI credits by creating a single recipe over and over again - “Pasta with Shallots and Pineapple”. They did this 12,000 times. Obviously, I had not put any rate limiting in.

Still, I was determined not to write any code. I explained the problem and asked Windsurf to come up with solutions. Seconds later, I had 15 pretty good suggestions. I implemented several (but not all) of the ideas in about 10 minutes and the abuse stopped dead in its tracks. I won’t tell you which ones I chose in case Mr Shallots and Pineapple is reading. The app’s security is not perfect, but I’m pretty happy with it for the scale I’m at. If I continue to grow and get more abuse, I’ll implement more robust measures.

Overall, I am astonished how productive Windsurf has made me in the last two weeks. I’m not a good designer or frontend developer, and I’m a very rusty rails dev. I got this project into production 5 to 10 times faster than it would’ve taken me manually, and the level of polish on the front end is much higher than I could’ve achieved on my own.  Over and over again, I would ask for a change and be astonished at the speed and quality with which Windsurf implemented it. I just sat laughing as the computer wrote code.

The next thing I want to change is making the recipe generation process much more immediate and responsive. Right now, it takes about 20 seconds to generate a recipe and for a new user it feels like maybe the app just isn’t doing anything.

Instead, I’m experimenting with using Websockets to show a streaming response as the recipe is created. This gives the user immediate feedback that something is happening. It would also make editing the recipe really fun - you could ask it to “add nuts” to the recipe, and see as the recipe dynamically updates 2-3 seconds later. You could also say “Increase the quantities to cook for 8 people” or “Change from imperial to metric measurements”.

I have a basic implementation working, but there are still some rough edges. I might actually go and read the code this time to figure out what it’s doing!

I also want to add a full voice agent interface so that you don’t have to touch the screen at all. Halfway through cooking a recipe, you might ask “I don’t have cilantro - what could I use instead?” or say “Set a timer for 30 minutes”. That would be my dream recipe app!

Tools like Windsurf or Cursor aren’t yet as useful for non-technical users - they’re extremely powerful and there are still too many ways to blow your own face off. I have a fairly good idea of the architecture that I want Windsurf to implement, and I could quickly spot when it was going off track or choosing a solution that was inappropriately complicated for the feature I was building. At the moment, a technical background is a massive advantage for using Windsurf. As a rusty developer, it made me feel like I had superpowers.

But I believe within a couple of months, when things like log tailing and automated testing and native version control get implemented, it will be an extremely powerful tool for even non-technical people to write production-quality apps. The AI will be able to make complex changes and then verify those changes are actually working. At the moment, it feels like it’s making a best guess at what will work and then leaving the user to test it. Implementing better feedback loops will enable a truly agentic, recursive, self-healing development flow. It doesn’t feel like it needs any breakthrough in technology to enable this. It’s just about adding a few tool calls to the existing LLMs. My mind races as I try to think through the implications for professional software developers.

Meanwhile, the LLMs aren’t going to sit still. They’re getting better at a frightening rate. I spoke to several very capable software engineers who are Y Combinator founders in the last week. About a quarter of them told me that 95% of their code is written by AI. In six or twelve months, I just don’t think software engineering is going exist in the same way as it does today. The cost of creating high-quality, custom software is quickly trending towards zero.

You can try the site yourself at recipeninja.ai

Here’s a complete list of functionality. Of course, Windsurf just generated this list for me 🫠

RecipeNinja: Comprehensive Functionality Overview

Core Concept: the app appears to be a cooking assistant application that provides voice-guided recipe instructions, allowing users to cook hands-free while following step-by-step recipe guidance.

Backend (Rails API) Functionality

User Authentication & Authorization

• Google OAuth integration for user authentication
• User account management with secure authentication flows
• Authorization system ensuring users can only access their own private recipes or public recipes

Recipe Management

1. Recipe Model Features:

• Unique public IDs (format: “r_” + 14 random alphanumeric characters) for security
• User ownership (user_id field with NOT NULL constraint)
• Public/private visibility toggle (default: private)
• Comprehensive recipe data storage (title, ingredients, steps, cooking time, etc.)
• Image attachment capability using Active Storage with S3 storage in production

1. Recipe Tagging System:

• Many-to-many relationship between recipes and tags
• Tag model with unique name attribute
• RecipeTag join model for the relationship
• Helper methods for adding/removing tags from recipes

1. Recipe API Endpoints:

• CRUD operations for recipes
• Pagination support with metadata (current_page, per_page, total_pages, total_count)
• Default sorting by newest first (created_at DESC)
• Filtering recipes by tags
• Different serializers for list view (RecipeSummarySerializer) and detail view (RecipeSerializer)

Voice Generation

1. Voice Recording System:

• VoiceRecording model linked to recipes
• Integration with Eleven Labs API for text-to-speech conversion
• Caching of voice recordings in S3 to reduce API calls
• Unique identifiers combining recipe_id, step_id, and voice_id
• Force regeneration option for refreshing recordings

1. Audio Processing:

• Using streamio-ffmpeg gem for audio file analysis
• Active Storage integration for audio file management
• S3 storage for audio files in production

Recipe Import & Generation

1. RecipeImporter Service:

• OpenAI integration for recipe generation
• Conversion of text recipes into structured format
• Parsing and normalization of recipe data
• Import from photos functionality

Frontend (React) Functionality

User Interface Components

1. Recipe Selection & Browsing:

• Recipe listing with pagination
• Real-time updates with 10-second polling mechanism
• Tag filtering functionality
• Recipe cards showing summary information (without images)
• “View Details” and “Start Cooking” buttons for each recipe

1. Recipe Detail View:

• Complete recipe information display
• Recipe image display
• Tag display with clickable tags
• Option to start cooking from this view

1. Cooking Experience:

• Step-by-step recipe navigation
• Voice guidance for each step
• Keyboard shortcuts for hands-free control:
• Arrow keys for step navigation
• Space for play/pause audio
• Escape to return to recipe selection
• URL-based step tracking (e.g., /recipe/r_xlxG4bcTLs9jbM/classic-lasagna/steps/1)

State Management & Data Flow

1. Recipe Service:

• API integration for fetching recipes
• Support for pagination parameters
• Tag-based filtering
• Caching mechanisms for recipe data
• Image URL handling for detailed views

1. Authentication Flow:

• Google OAuth integration using environment variables
• User session management
• Authorization header management for API requests

Progressive Web App Features

• PWA capabilities for installation on devices
• Responsive design for various screen sizes
• Favicon and app icon support

Deployment Architecture

1. Two-App Structure:

• cook-voice-api: Rails backend on Heroku
• cook-voice-wizard: React frontend/PWA on Heroku

1. Backend Infrastructure:

• Ruby 3.2.2
• PostgreSQL database (Heroku PostgreSQL addon)
• Amazon S3 for file storage
• Environment variables for configuration

1. Frontend Infrastructure:

• React application
• Environment variable configuration
• Static buildpack on Heroku
• SPA routing configuration

1. Security Measures:

• HTTPS enforcement
• Rails credentials system
• Environment variables for sensitive information
• Public ID system to mask database IDs

This comprehensive overview covers the major functionality of the Cook Voice application based on the available information. The application appears to be a sophisticated cooking assistant that combines recipe management with voice guidance to create a hands-free cooking experience.