I Built an AI Product in One Weekend — Here's What Actually Happened
The NourishRx story: building AI meal plans for Australians on GLP-1 meds. The tech stack, what broke, and the real unit economics.
47 hours. That's how long it took from "this could be a product" to accepting my first payment. Not 47 hours of coding — 47 hours of calendar time, including sleep, meals, and a solid hour of swearing at Stripe webhooks.
NourishRx is an AI-powered meal planning service for Australians on GLP-1 medications — Ozempic, Mounjaro, and similar drugs. These medications suppress appetite and change how your body processes food. The standard meal plans floating around the internet don't account for that. People on GLP-1s need smaller portions, higher protein density, specific nutrient timing, and meals they can actually stomach when their appetite is suppressed.
The market signal was obvious. GLP-1 prescriptions in Australia are growing fast. Facebook groups for Australians on these medications have tens of thousands of members. The most common question: "What should I eat?" Nobody was answering it properly with Australian-specific foods, Australian supermarket availability, and Australian dietary guidelines.
Here's the exact tech stack and how it all fits together.
Claude API handles the meal plan generation. I wrote detailed system prompts that include Australian dietary guidelines, GLP-1-specific nutrition requirements, common Australian supermarket items, and portion sizing appropriate for appetite-suppressed users. Each plan is generated fresh for the user based on their medication, dietary preferences, allergies, and goals.
Why Claude over GPT? Two reasons. First, Claude follows detailed instructions more reliably. When I say "use Australian measurements and Australian supermarket brands," Claude actually does it consistently. GPT-4 would randomly switch to American measurements and reference Trader Joe's. Second, Claude's output quality for structured content — meal plans with specific macros, ingredient lists, and preparation steps — was noticeably better in my testing.
Netlify handles hosting and serverless functions. The site is static HTML/CSS with JavaScript for the interactive elements. Netlify Functions handle the backend logic — processing orders, calling the Claude API, and managing user data. No traditional server. No database to maintain. The simplicity of this setup is what made the weekend timeline possible.
Stripe handles payments. Three tiers: Core at $69 AUD (one personalised plan), Plus at $97 (plan plus two weeks of adjusted variations), and Unlimited at $119 (monthly rolling plans). Setting up Stripe was the most painful part of the build. Not because Stripe is bad — it's great — but because webhook handling, subscription management, and edge cases around failed payments are genuinely complex.
Resend handles email delivery. When a customer pays, they get their meal plan delivered via email as a beautifully formatted PDF. Resend is simple, reliable, and cheap. I looked at SendGrid and Mailgun first, but Resend's developer experience was significantly better.
What broke during the build.
The Claude API rate limits hit me during testing. I was generating dozens of test meal plans to validate the output quality, and I burned through my rate limit faster than expected. Had to slow down testing and be more strategic about which variations I tested.
Stripe webhooks were a nightmare. The webhook that confirms payment completed and triggers meal plan generation kept failing silently in local development. Turns out I had a timezone mismatch in my webhook verification that only manifested in certain edge cases. That bug cost me four hours.
The email formatting was harder than expected. Rendering a complex meal plan as a readable email that looks good across Gmail, Outlook, and Apple Mail is a solved problem in theory. In practice, every email client renders HTML differently, and what looks perfect in Gmail looks broken in Outlook. I ended up simplifying the design significantly.
The honest unit economics.
Each meal plan generation costs roughly $0.30-0.50 in Claude API calls, depending on the complexity of the user's requirements. Stripe takes 1.75% plus $0.30 per transaction (Australian pricing). Resend is essentially free at my current volume. Netlify hosting is free on the starter tier.
On a $69 Core plan sale, my gross margin is about $66 after API and payment processing costs. That's a 95% margin on variable costs. On $119 Unlimited plans, the margin per month is slightly lower because I'm generating multiple plans, but it's still above 90%.
The catch: these margins look amazing until you factor in customer acquisition cost. Getting someone to buy an AI-generated meal plan from a website they've never heard of isn't cheap. Meta ads for health-related products in Australia run $15-30 per click. At a 3% conversion rate, each customer costs roughly $500-1,000 to acquire through paid ads.
That maths doesn't work for a $69 one-time purchase. It does work for $119/month subscriptions if retention is decent. This is the classic SaaS challenge: the unit economics only make sense if you can either get acquisition costs down (organic content, referrals, SEO) or push customers toward recurring plans.
What I'd do differently if I were starting again.
I'd start with the subscription tier only. One-time purchases are a sugar hit — they generate revenue but don't build a business. Recurring revenue is the only thing that compounds.
I'd validate with a waitlist before building. I was lucky that the product worked, but I easily could have spent a weekend building something nobody wanted. A simple landing page with an email capture would have told me if there was demand in a few days.
I wouldn't have perfectioned the email template. The first version was overdesigned. A clean, simple email with the meal plan in plain text would have shipped two hours faster and been just as effective.
The speed was the point. Not the speed itself, but what it proved: you can go from zero to revenue-generating product in a weekend if you use the right tools and ruthlessly cut scope. Not every product should be built in a weekend. But the ability to move that fast means you can test ideas cheaply and only invest real time in the ones that show traction.
Building NourishRx taught me more about product development in 47 hours than any book or course. The constraints forced clarity.
If you're sitting on a product idea, stop planning and start building. You can always improve it later. You can't improve something that doesn't exist.
Questions about the build or the stack? daine@dainereid.com.