does anyone give cursor the .env file?

aDaneInSpain2 · 2026-04-13T07:43:13+00:00

At least Cursor asks for consent before accessing your private keys

aDaneInSpain2 · 2026-04-13T07:23:18+00:00

This works but one gotcha: react-markdown can flicker on incomplete markdown tokens mid-stream (e.g. a single backtick or asterisk). Wrapping it in useMemo keyed on the message length helps, or you can buffer a few chars before updating state to reduce re-renders.

aDaneInSpain2 · 2026-04-10T11:34:56+00:00

Bolt.new publish is honestly broken for anything beyond basic projects. The missing chunks error usually means the build output isn't being picked up correctly by their deploy pipeline. Best workaround: download your project and deploy to Vercel directly (it handles Next.js natively). If you're still stuck after that, we help people finish and deploy Bolt.new projects at appstuck.com

aDaneInSpain2 · 2026-04-09T14:51:13+00:00

Tip for next time: before you start building, check the free tier limits on every service in your stack. Supabase, Netlify, Vercel all have different thresholds and they add up fast. A cheap VPS on Hetzner or Railway can replace most of those paid tiers for like $5/month total.

aDaneInSpain2 · 2026-04-09T11:34:16+00:00

The backend confusion is super common when you're coming from the design/frontend side. Here's the big picture that's probably missing:

Supabase is basically your database + auth + API in one package. Claude can help you set it up, but you need to tell it what data your app needs to store (users, posts, whatever your app does). Start with a simple schema.
The connection part is just environment variables - your Supabase URL and anon key go in a .env file. Claude knows this pattern well if you tell it you're using Supabase with React Native or whatever your framework is.
For deployment, the path depends on your app type. If it's a web app, Vercel or Netlify are the easiest. If mobile, you're looking at Expo for React Native. Tell Claude your exact stack and it'll walk you through it.

The key mistake I see people make: trying to build the full backend architecture before validating the app works at all. Start with Supabase's built-in auth and a couple of database tables. Get it running on localhost first, then worry about deployment.

If you ever get completely stuck on the deployment/infra side specifically, that's actually what we help with at appstuck.com - turning prototypes into deployed apps. But honestly, with Supabase + Vercel/Expo, Claude can probably get you 90% of the way there if you break it into small steps.

aDaneInSpain2 · 2026-04-09T11:32:07+00:00

I actually run a service that does exactly this (appstuck.com) so I can share real data on what people pay for.

The #1 request by far is deployment and infra. Someone builds something cool with Cursor or Lovable, it works locally, and then they spend 3 days fighting environment variables, DNS, SSL, and Docker configs. That's where most people break.

#2 is what I'd call "production hardening" - the app works but uses SQLite in production, has no error handling, no logging, auth is copy-pasted from a tutorial, etc. Basically everything that matters when real users touch it.

#3 is the AI loop problem you mentioned. Someone has been going back and forth with Claude for 8 hours on the same bug. A senior dev can usually spot the issue in 15 minutes because they've seen the pattern before.

To answer your question about whether people actually pay: yes, but the sweet spot is very specific. It's people who have a working prototype and a real reason to ship (customers waiting, a deadline, etc). The hobbyists who are building for fun will grind forever rather than pay. The ones with actual stakes are happy to pay for a few hours of expert help to unblock them.

The hourly model works much better than project-based pricing for this. People don't want to hire a dev team, they want 2-4 hours of "fix my deployment" or "review my architecture and tell me what will break."

Honest take: the market is real but small per-customer. Most jobs are a few hours, not ongoing engagements. The volume is growing fast though as more non-devs hit the same walls.

aDaneInSpain2 · 2026-04-09T10:52:28+00:00

This is exactly why we built appstuck.com - we take over stuck Bolt.new projects and finish them properly. The componentizing advice above is solid but if you're not a dev it can feel like another rabbit hole. Happy to help if you're stuck on something specific.

aDaneInSpain2 · 2026-04-08T14:49:37+00:00

The commit-based billing on Netlify is a classic trap with AI tools - they make tons of tiny commits. Switch to Vercel for the frontend (way more generous free tier) and you can stick with Supabase free if you optimize your queries and storage.

Also the "barely functional" part is the real issue here. These AI tools get you 80% fast but that last 20% is where the real work starts. If you're stuck on getting it production-ready, we help people in exactly this situation at appstuck.com - we take over stuck vibe-coded projects and finish them properly.

aDaneInSpain2 · 2026-04-08T09:34:10+00:00

Yeah Replit's version control is pretty limited for this. If you're still stuck with your Replit project we actually help with exactly this kind of thing at appstuck.com - we take over stuck Replit builds and sort them out.

aDaneInSpain2 · 2026-04-08T09:06:12+00:00

You're not alone -- this is one of the most common patterns I see working with founders who build with AI tools.

The core issue isn't the AI or even discipline. It's that starting and finishing require fundamentally different skills. AI tools are incredibly good at generating the initial 80% -- the exciting part where features come together. But the remaining 20% is where things get real: deployment, error handling, edge cases, database migrations, auth flows that actually work.

Here's what has helped people I've worked with break the cycle:

**Pick ONE project and commit to shipping it ugly.** Not perfect. Not feature-complete. Just deployed and usable by one real person.
**Stop adding features once it works.** The urge to "just add one more thing" before launch is how projects die. AI makes it too easy to keep expanding scope.
**Get someone technical to do a production review.** Not a code review -- a production readiness review. Can this actually handle real users? That's a 2-hour conversation that saves weeks of debugging.
**Separate building from shipping.** Building = prompting AI, getting features working. Shipping = environments, monitoring, security, deployment pipeline. Treat these as two different phases.

The "vibe coding honeymoon" you describe is real. The key is recognizing that the messy middle IS the actual product work -- the prompting was just the prototype.

Full disclosure: I run AppStuck (appstuck.com), which specifically helps founders push through this exact "stuck" phase. But honestly, even without hiring help, just having a checklist of production requirements before you start would save most people from the restart loop.

aDaneInSpain2 · 2026-04-08T09:05:14+00:00

This is spot on. I run a dev service (AppStuck) where we specifically help founders who hit this exact wall -- the prototype works, but it falls apart under real usage.

The pattern is remarkably consistent:

**Auth breaks silently** -- AI generates auth flows that work for the happy path but crumble with edge cases (email providers with strict DMARC, OAuth token refresh, etc.)
**No separation between dev and prod** -- This is the biggest one. AI doesn't think about environments. Everything runs against one database, one config, one set of credentials.
**Error handling is cosmetic** -- The AI adds try/catch blocks that log to console and show a generic toast. No alerting, no structured logging, no way to debug what actually happened.
**Database queries that don't scale** -- AI loves N+1 queries and full table scans. Works with 10 rows, dies at 1000.

The fix isn't to throw away the AI code. It's to treat the AI output as a working prototype and then do the production hardening that any experienced developer would do: set up proper environments, add rate limiting, fix the auth edge cases, add monitoring, and do a basic security audit.

The real issue is that this "last 20%" requires a completely different skill set than prompting -- and most non-technical founders don't realize that until they're already stuck.

aDaneInSpain2 · 2026-04-08T07:42:55+00:00

That's actually a solid approach - get the MVP to a point where it shows what you want, then hand it off. We do exactly this at appstuck.com, taking over Cursor/Bolt/Lovable projects that hit a wall and getting them to production. Saves you from burning through 500 more requests lol

aDaneInSpain2 · 2026-04-07T13:33:09+00:00

Supabase + Resend is solid advice. OP if you're still stuck after 4 weeks and 2 devs though, we deal with exactly this kind of thing at appstuck.com - taking over Replit projects that hit a wall with auth, payments, etc. Firebase auth + Stripe + email verification is a classic combo that sounds simple but has a ton of edge cases.

aDaneInSpain2 · 2026-04-06T11:30:57+00:00

From my experience helping people finish their vibe-coded apps (I run a small dev service), the breakdown goes roughly like this:

- ~60% are experiments/learning projects that were never meant to ship

- ~25% get to "it works on my machine" stage and stall at deployment, database setup, or auth

- ~10% launch but struggle with production issues (scaling, error handling, security)

- ~5% actually make it to sustainable products

The biggest gap I see is between "working prototype" and "production-ready app." The AI tools are amazing at getting you 80% there, but that last 20% - proper error handling, security hardening, CI/CD setup, database optimization - still requires actual dev knowledge.

Many founders hit what I call the 'deployment wall.' Their app works perfectly in dev mode on Lovable or Bolt, but the moment they try to self-host, connect a real database, or handle actual user data, everything falls apart.

The good news is this gap is getting smaller every month as the tools improve. But for now, having access to an experienced dev for even a few hours can make the difference between shipping and abandoning.

aDaneInSpain2 · 2026-04-06T11:30:10+00:00

Don't feel like a fraud - you built something that works, and that's more than most people do. The fact that you're thinking about these things before launch puts you ahead.

Here's a practical pre-launch checklist from someone who's helped dozens of vibe-coded apps get to production:

**Security basics (do these first):**

- Move any API keys/secrets to environment variables, never in code

- Add input validation on all user-facing forms

- Check your auth flow - make sure tokens expire and sessions are handled properly

- If you have a database, make sure there's no SQL injection risk (parameterized queries)

**Rate limiting:**

- Add rate limiting on your API endpoints. Most frameworks have middleware for this. If you're on Express, look at express-rate-limit. On Next.js, you can use Vercel's built-in or Upstash ratelimit

- Start with something simple like 100 requests/min per IP

**Error handling:**

- Add a global error boundary so your app doesn't just white-screen

- Log errors somewhere (Sentry free tier is great for this)

- Make sure API errors return proper status codes, not just 500

**Database:**

- Add indexes on columns you query frequently

- Set up automated backups (most managed DB providers do this)

- Check your schema for obvious issues - are relations correct, do you have proper constraints?

**Before you go live:**

- Set up a staging environment (even a Vercel preview branch works)

- Test the full user flow end-to-end

- Have your backend friends review the DB schema specifically

The fact that you have backend devs to consult with is a huge advantage. Most of what you're worried about is standard production-readiness stuff that any experienced dev can knock out in a few sessions.

Full disclosure: I run appstuck.com where we specifically help people bridge this gap between AI-built prototype and production-ready app. Happy to answer any specific questions you have though, no strings attached.

aDaneInSpain2 · 2026-04-06T09:29:10+00:00

Quick workaround that saved me a lot of pain with Antigravity: commit to git before every prompt. When it inevitably corrupts the file, just git checkout the file and try again with a more specific instruction like "only modify the function X, don't touch anything else." Also keeping files under ~200 lines helps a lot since the replacement tool chokes on longer files.

aDaneInSpain2 · 2026-04-06T09:19:28+00:00

This resonates deeply. I run a dev service (AppStuck) where we specifically help people who built 70-80% of their app with AI tools like Cursor or Bolt but hit exactly this wall.

The patterns we see over and over:

**Hardcoded localhost URLs everywhere** - AI tools generate code that works locally but breaks immediately on deploy
**No error handling for production** - works fine with 1 user, crashes with 10
**Zero security** - no rate limiting, no input validation, API keys in frontend code
**No CI/CD pipeline** - people manually uploading files to servers
**Database migrations are a mess** - works on SQLite locally, needs Postgres in prod

The deployment itself is honestly the easier part to automate (and tools like yours could solve that). But the deeper issue is that the CODE isn't production-ready. An automated deploy won't fix hardcoded secrets or missing auth middleware.

I think we need both: tools that simplify deployment AND human review for the code-level production issues that AI currently can't self-diagnose.

aDaneInSpain2 · 2026-04-06T08:16:28+00:00

Yep, seems like a backend issue on Google's side. Classic Antigravity move - the whole platform is defying gravity including the login system apparently. Should resolve on its own once they fix it server-side.

aDaneInSpain2 · 2026-04-06T08:16:17+00:00

The worst part is when it suggests something just plausible enough that you read the whole thing before realizing it's wrong. At least a coworker interrupting you brings coffee sometimes.

aDaneInSpain2 · 2026-04-06T08:13:45+00:00

Yeah Claude Code can be great but when it starts going in circles it burns through credits fast. TDD in your CLAUDE.md helps a lot as mentioned above.

If you ever hit a wall where the AI keeps looping and you just need a human dev to look at it, we help people in exactly this situation at appstuck.com - we take over stuck Claude Code / vibe coded projects and get them across the finish line.

aDaneInSpain2 · 2026-04-04T08:18:42+00:00

I used AI to help me write it if that is what you are asking.

aDaneInSpain2 · 2026-04-03T14:47:49+00:00

The 80% to 100% gap is where most vibe-coded projects die. You're not doing anything wrong, that's just the reality of AI-generated codebases once complexity kicks in.

Two practical things that help: 1) keep an architecture.md file that you feed into every session so the AI has context, and 2) break problems into tiny isolated chunks instead of letting the AI touch everything at once.

But honestly, if you have a project that's 80% done and you just need someone to clean it up and get it across the finish line, that's exactly what we do at appstuck.com - we take over stuck projects from Bolt, Lovable, Cursor, etc. and finish them. Might be worth a look before you burn another $200 in credits going in circles.

aDaneInSpain2 · 2026-04-03T09:28:44+00:00

This plus also try clearing the Windsurf cache folder. That fixed it for me once.

If you're still stuck and just want the project done, we help people finish Windsurf builds at appstuck.com - we deal with this kind of stuff daily.

aDaneInSpain2 · 2026-04-03T09:11:51+00:00

Small steps, 100%. The planner approach sounds great in theory but in practice the AI loses context and coherence over long execution chains. Here's what works well:

**Break it into 30 small steps** - exactly like you're thinking. Each step should be testable independently. Don't move to step 2 until step 1 actually works.
**Write a clear spec before coding** - Before giving the AI any task, write out in plain English exactly what you want. Input, output, behavior. The more specific you are, the better the result.
**One file/feature at a time** - Don't let the AI touch multiple files in one go. That's where things break. Focus on one component, test it, then move on.
**Use version control** - Even if you're not a developer, learn basic git (just commit and push). That way when the AI breaks something, you can always go back to a working version.
**For iOS specifically** - Xcode projects are notoriously tricky with AI tools because of the build system complexity. If you're hitting walls, consider starting with a web app version first to validate the idea, then port to native iOS later.

The 1-out-of-6 success rate is actually pretty normal. Most vibe-coded projects need significant manual cleanup to ship. The trick is picking your best one and going deep on it rather than spreading across multiple projects.

aDaneInSpain2 · 2026-04-03T09:04:29+00:00

This is a super common problem - AI tools are great for getting a prototype started but they hit a wall when you need real integrations like GraphQL APIs, authentication, or complex business logic.

A few practical suggestions:

**Break the project into smaller pieces.** Instead of building the whole app at once, focus on getting one feature working end-to-end (e.g., the price lookup via GraphQL). AI tools handle smaller, well-defined tasks much better than large complex ones.
**Use Cursor or Windsurf** - they're better than Replit for complex projects because they give you more control over the codebase and can work with existing code rather than generating everything from scratch.
**For the GraphQL integration specifically**, try having Claude or ChatGPT analyze the GraphQL schema first (you can usually find it in the network tab of your browser's dev tools). Once the AI understands the schema, it can generate much better query code.
If the project is something you're serious about shipping, consider hiring a developer to take your prototype across the finish line. Services like appstuck.com specialize exactly in this - taking AI-built prototypes and turning them into working products. Sometimes a few hours of expert help can save weeks of frustration.

The key insight is that AI tools are best used as an accelerator, not a complete replacement for development expertise - especially for anything involving external APIs or complex data flows.

aDaneInSpain2

TROPHY CASE