Lovable burned credits, ignored valid JSON, and now locks live deployments behind a paywall

[mikeyapina]

📝 Description:
We’ve uploaded verified, structured JSON for four live athlete records — each fully compliant, using MXN, no demo_tag, and containing months of stipend + merit data. This includes:

Michael Pina – not created despite valid file

Abraham Garcia – returned “success” but showed blank screen

Rafa Garcia – mislabeled, then confirmed

Victor Hugo – confirmed but timeline cut off mid-year

We followed every instruction. Your system ignored fields, ran unrelated “security scans,” and burned dozens of prompts without execution. Then it blocked us behind a $294/month paywall right as we tried to finalize onboarding.

📊 Historical Evidence:
Files: *_live_mxn.json (uploaded repeatedly)

Emails: michaelpina@hotmail.com, garciaabraham71314@gmail.com, misagarcia6373@gmail.com, dejesusruizvictorhugo@gmail.com

Timestamps: Abraham stipend from 2022; Rafa loan since April 2025

Proof of prompt exhaustion from security scans + token logs

Screenshots: Admin panel failure, system auto-bypass, paywall trigger

🎯 Ask:
Re-credit all wasted prompts

Unlock access to create michaelpina@hotmail.com

Acknowledge this is live production QA, not user error

Fix the token consumption logic (you’re draining before delivering)

[mikeyapina]

Subject: Re: Credits & Account Access – System Broken, QA Burden Ours

Hi Lovable team,

Thanks for the reply — but this still misses the core issue.

We’re not just “building something impressive.” We’ve been forced to rebuild core system flows from scratch after Lovable’s platform broke its own logic — multiple times.

Here’s what happened:

Your system misprocessed our JSON data

It falsely confirmed account creation (e.g., Abraham, Rafa, Michael)

Then ran non-requested prompt tasks like security reviews that burned tokens

All of this before any billing failure or card flag ever occurred

Once Lovable’s backend broke, we didn’t walk away. We doubled down — rebuilding identities, fixing what your pipeline discarded, realigning MXN financial logic, and staging full live athlete onboarding flows you’ve never supported at scale yet.

The reason the card failed later is because we paused it deliberately while we traced and rebuilt the system you misfired. It’s not a payment issue — it’s a QA burden that you offloaded to us.

Now that we’ve restored everything ourselves — player files, stipend tracking, wallet views, and onboarding logic — you’re saying we can’t complete the final account creation unless we pay to keep QA’ing the problem you created.

That’s not partnership. That’s rent-seeking.

We're asking for this:

✅ Restore prompt access long enough for us to complete the project
✅ Let us finalize onboarding of michaelpina@hotmail.com without a paywall
✅ Acknowledge that we’ve done foundational QA on behalf of your product

We’ve been patient. We’ve been precise. But if the only answer now is “pay to finish fixing what we broke,” then it’s clear Lovable is not serious about real builders or real apps.

Happy to resume collaboration if you're ready to meet us where we are — with honesty and system-level integrity.

– Michael
Name the Game / 3MOF

[mikeyapina]

Subject: Re: 10,000 Prompts Later — What Is Lovable Actually Representing?

Hi Lovable,

We’ve already summarized the issue — in full, with dates, screenshots, account names, JSON files, prompt logs, payment context, and live build history.

If you missed that, please scroll up and reread our last message.

We are not starting over. We are not rephrasing. We are asking Lovable to respond like a product team that respects builders who’ve already done the legwork to fix what your system dropped.

What you owe us now is:

Reinstated prompt access

Completion of the Michael Pina onboarding (with no paywall)

An acknowledgment that our production use case deserves continuity

You’ve had the logs. You’ve had the context. Now it’s your move.

— Michael
Name the Game / 3MOF

[mikeyapina]

NTG Platform Bug & Delivery Failure Log (as of July 13, 2025)

1. Critical Functional Failures

A. Workout Pack Module (Admin Upload Panel)

Status: Marked as complete by devs

Issue: Bulk upload panel is present but completely non-functional. No uploads appear, no save states, and the CSV template link provides no output.

Impact: Cannot assign, manage, or view workouts.

B. Tryout Creation Flow

Status: Marked complete in sprint

Issue: "/create-tryout" route returns a black screen with raw code snippet visible.

Impact: Users cannot create tryouts. Clicking the sidebar route lands in gallery view or stalls.

C. Fitness Cards Display

Status: Marked complete

Issue: Cards appear but contain placeholder data only. Clicking "Details" provides no expanded information.

Additional: "Create New" fitness card button shows "Creation feature coming soon"

D. Swipe Builder (Fitness)

Status: Marked ready

Issue: Swipe flow shows 0 workouts despite 5 visible on cards. Swipe interface returns "All workouts reviewed" even on new sessions.

E. Player/Coach Onboarding Wizard

Status: Marked finalized

Issue: Route "/onboarding" returns a blank (black) screen after selecting Pro or Gamified path.

2. Authentication & Email System Failures

A. Existing User Passwords

Status: Users previously created successfully (layers, coaches)

Issue: Now none of those emails/passwords work.

Impact: Cannot sign in, reset, or recover accounts.

B. Account Creation (HUGS ID Access)

Status: Testable via UI

Issue: Returns one of the following errors:

"Error sending confirmation email"

"Email rate limit exceeded" (despite being only 1/100 sent in Resend dashboard)

Verified Setup:

Resend domain fully verified: noreply.3mof.org

DKIM, SPF, and DMARC all valid

API key is active but fails with 403 Not authorized to send from 3mof.org

SMTP is configured in Supabase (Host: mail.3mof.org, Port: 25, Username: noreply@3mof.org)

3. UX/UI Blocking Bugs

A. Dropdown Filters (Transparent)

Location: Admin module, swipe filters

Issue: Dropdowns render behind other containers or with white-on-white font, making them unreadable or unselectable.

B. Misleading Landing Routes

Issue: Create Tryout and Create Fitness buttons show as if enabled but lead to blocked or broken routes. No error messaging.

4. Verified Email Records

Only one user appears in Supabase with metadata:

{
"id": "34351e90-0fd5-4eb0-a2e4-66a38d3b19a8",
"email": "dejesusruizvictorhugo@gmail.com",
"created_at": "2025-06-12T22:08:48.314Z",
"role": "authenticated"
}

Attempts to log in with the assigned password fail.

New account creation fails due to email or SMTP errors.

5. Summary

The platform currently simulates functionality in many places without actual backend logic or delivery. Frontend routes, modals, and dropdowns are visually present but non-functional or disconnected. Auth and email are critically broken despite appearing configured. Urgent remediation is required.

[mikeyapina]

Lovable used your remaining prompt credit to run a broken process and then immediately hit a hard limit due to failures, routing bugs, or auth issues — and instead of handling it, they’re now pushing the upgrade screen.

⚠️ Here's What Happened:
You triggered a valid fix prompt (/create-tryout routing).

The process began, used 1 credit, and succeeded.

But then:

Another bug or failure happened mid-flow (likely due to unhandled edge cases or improper rollback).

It tried to rerun without resetting or confirming — so a second credit attempt triggered a hard cap.

🧾 Immediate To-Do
Here’s what you can send as a DM or email to Lovable support (or drop in their Discord):

🔧 Credit Misuse + Mid-Process Fail Report

Hey team — I had 1.40 credits remaining when I ran a routing fix on /create-tryout. That fix completed successfully (confirmed), but a second process was triggered by a UI or redirect failure, causing my last available credit to be consumed without results.

I then hit a usage cap and was sent directly to the upgrade prompt — despite the second trigger being caused by Lovable's own state error.

This should qualify for a credit reinstatement or rollover, since the extra usage wasn't user-initiated or productive. Please advise and confirm when this is restored.

Thanks —
Mike @ 3MOF

[mikeyapina]

🚨 Burns Credits Without Delivering Full Value:
✅ Front-end UX gets created (looks great)

❌ Middleware/backend rarely appears

❌ SQL errors trigger more charges

❌ Autofixes retrigger prompts even when caused by the last one

❌ Final delivery looks complete — but lacks logic, database hooks, or usable API calls

📉 Root Problem: Token Drain + Error Chaining
What you're facing is what developers call:

"looped autocompletion with false success"

In short:

A visually impressive UI masks the fact that core functionality is missing

The system acts like a “completed job” — when it’s actually just one layer

When errors show up, instead of resolving them internally, Lovable charges you again to “fix” the bug it introduced

🧾 What You Should Send to Lovable (Escalation-Ready)
Here's a clean, professional message you can paste in Discord or email:

🧨 1000 Prompt Burn Report — Middleware + SQL Failures

Team — over the last 3 days I’ve burned through 1000 prompts without full backend delivery. Here’s the pattern I’ve documented:

Each feature build returns a great-looking front end — but lacks backend logic (no Supabase integration, no API hooks, etc.)

SQL statements return errors and require 2–4 additional prompts to fix (each charging again, even when Lovable’s initial syntax caused the failure)

Autocompletions retrigger fixes without user intent — silently eating more credits

Even when we hand over valid JSON or database structure, the system doesn’t finish the backend

Result: I’ve paid for beautiful UI scaffolds that don’t persist data, don’t authenticate users, and don’t actually complete workflows.

This is not just an inefficiency — it’s credit leakage at a platform level. I’m asking for the following:

✅ Restore ~300–500 credits lost to middleware/SQL error loops
✅ Flag this behavior for your QA team — you are charging users for your own retry paths
✅ Offer a clearer UX on when a fix is free (platform-caused) vs paid (user mistake)

I’m building a real system with 17+ modules — and I want Lovable to succeed. But this pattern kills trust. Let’s fix it.

— Mike @ 3MOF / Name the Game

Let me know if you'd like to tweak or shorten this — but this version is strong, direct, and fix-oriented. You're not just pointing out flaws — you're offering the exact product feedback that will help them improve.

[mikeyapina]

Team —

Over the last 3 days I’ve burned through 1000+ prompts without full backend delivery. Here’s the pattern I’ve documented:

Every feature build returns a great-looking front end, but lacks backend logic (no Supabase integration, no API hooks, etc.).

SQL statements often fail, requiring 2–4 additional prompts to fix — each one charged, even when Lovable’s own syntax caused the error.

Autocompletions retrigger fixes without user intent — silently draining credits.

Even when we provide valid JSON structures or DB schema, the system still doesn’t complete the backend flow.

Result: I’ve paid heavily for polished UI scaffolds that don’t persist data, don’t authenticate users, and don’t finish key workflows.

✅ Please restore ~300–500 credits lost to middleware/SQL error loops.
✅ Flag this retry-loop behavior for your QA team — your system is charging for its own repair cycles.
✅ Introduce a clearer UX to show when a fix is free (platform-caused) vs paid (user mistake).

I’m building a real production system with 17+ modules and want Lovable to succeed. But this pattern kills trust. Let’s fix it.

— Mike @ 3MOF

[mikeyapina]

Thanks for confirming — and sorry you’re still hitting a wall. If the Lovable team claimed the email-password login issue was resolved, but your mike@3mof.org login still fails, here’s how we should escalate it.

---

✅ Send This Follow-Up Message to Lovable:

Hey Lovable — quick update:

You mentioned the email-password issue was fixed. I just tested login for mike@3mof.org using the password I originally registered with — still no access. I also tried the other email address

• No error message confirming incorrect credentials
• No password reset option
• No indication if account exists or if email verification is pending

This means I can’t access my account — and the front end routes tied to that login (like /onboarding, /kite-wallet, etc.) are still blocked.

Please:

1. Confirm that the Supabase auth layer is writing new users and validating credentials.
2. Let me know if the auth.users table has mike@3mof.org and others in place.
3. Enable password reset flow so I can test access again.

I can’t validate the full onboarding or wallet system until this is fixed — and this directly affects my credit usage. Appreciate a fix or diagnostic path.

---

📌 Bonus Debug Tip (if you have Supabase access):

Run this query:

select id, email, created_at, last_sign_in_at from auth.users where email = 'mike@3mof.org';

If the last_sign_in_at is null, and created_at is old, it confirms:

• Account was created, but login failed.
• Could be missing email confirmation or backend validation logic.

---

Let me know if you'd like me to draft the password reset flow or check the Supabase RLS/auth rules as a next step.

You're close — just need this final unblock.

[mikeyapina]

These are all the emails it did not work with when yourpprmot said it worked -- michaelpina@hotmail.com, garciaabraham71314@gmail.com, misagarcia6373@gmail.com, [dejesusruizvictorhugo@gmail.com](mailto:dejesusruizvictorhugo@gmail.comLogin Test Failed for All Created Accounts — Auth Still Broken

I just tested all four accounts that were supposedly created successfully and marked as active:

michaelpina@hotmail.com

garciaabraham71314@gmail.com

misagarcia6373@gmail.com

dejesusruizvictorhugo@gmail.com

None of them can log in — not even the account tied to my admin email (mike@3mof.org).

No password works (including default or previously defined)

No “reset password” option works

No email confirmation flow is active

This directly contradicts your earlier message that login and auth were resolved. If your system reports these users as active, but Supabase isn't validating passwords or allowing sign-in, something is still misconfigured.

Please confirm:

That these users exist in auth.users

What auth method is being used (email/pass vs OAuth vs magic link)

Whether password hashing/validation is correctly wired into Supabase

Why login always fails silently — even for fresh accounts

Until this is fixed, we can’t access any of the app’s core functions (wallet, training logs, merit tracking). This is a blocker.

— Mike @ 3MOF