By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.

Tooling

How I Build with Lovable and Claude Code Without Burning Through Credits

Lovable credits go fastest on the boring front-end stuff — nudging buttons, rewording headlines, fixing layouts. Here's the workflow I use to save them for the back-end work they're actually for.

Joshua McSorley4 min readMay 2026

The first time I built a project in Lovable, I watched my credits drain in an afternoon. Not on the hard stuff. On nudging a button two pixels left, rewording a headline, fixing a layout. The boring front-end edits ate the budget I needed for the work only Lovable can actually do.

So I changed how I work. Now I do my thinking in Claude chat, my front-end edits in Claude Code against local files, and I save Lovable credits for the back end. Same project, same result, a fraction of the spend.

Here is the exact workflow, step by step.

Step 1: Do all your thinking in Claude chat first

Before I touch Lovable, I open Claude chat and explain the project in as much detail as I can. This is the part people skip, and it is the part that saves the most money. Every assumption you leave unspoken now becomes a paid revision later.

I cover:

  • Every step the user is going to take through the product
  • Every page or screen we need to produce
  • The technologies we are likely to need
  • The visual identity of the brand, where it fits, the brand archetype, and the tone of voice

Then I ask Claude to turn all of that into written documentation a creative developer could actually build from.

Step 2: Produce your project documents as markdown

Depending on the scope, I usually end up with three markdown files:

  1. The project brief. Written for a creative developer. This holds the user flows, the page list, and the technical direction. I review it carefully and confirm the user flow information is accurate before moving on.
  2. The brand document. Visual identity, brand archetype, and tone of voice. Sometimes this lives inside the project brief, but on bigger projects I keep it separate so it is easy to reference.
  3. The agent instructions. The file that tells your coding agent how Lovable projects are built: React, a specific CSS framework, Supabase, and the rest of the stack. This is what keeps Claude Code editing in a way that matches what Lovable expects.

Review each one before you go further. A wrong assumption caught here costs nothing. The same assumption caught after the build costs credits.

Step 3: Write your initial Lovable prompt and let it run

Once the documents are solid, have Claude produce an initial Lovable prompt to start the project. Drop it into Lovable and let it do its thing for a minute. Say yes to pretty much everything it asks during this first pass.

If you are not already on the twenty dollar plan, get on it now. You need it to host the project, and you want hosting in place before the next steps.

Step 4: Connect GitHub and pull the project local

This is the step that unlocks the whole system, so do not skip it.

Once Lovable has the initial project set up, create a GitHub connection from inside Lovable. Then connect that repository to your local machine. I use HTTPS for the GitHub connection. It is the easiest and fastest way to get set up and connected to Claude Code without fighting with SSH keys.

Now Claude Code is looking at local files you can run on your own machine, and those files mirror what you see in Lovable. Your coding agent can read and edit the real project. That is the door this whole approach walks through.

Step 5: Split the work by where it is cheapest

Here is the rule that saves the money. Once you internalize it, the rest is automatic.

Front-end work goes to your coding agent. Layout, styling, components, copy, page structure, anything visual. Claude Code, OpenAI Codex, Alibaba's Qwen, whichever agent you like. You edit the local files, push, and the changes flow back into your Lovable project. None of this spends Lovable credits.

Back-end work stays in Lovable. This is what Lovable credits are actually for:

  • Setting up user login and authentication
  • Sending emails
  • Anything API-related
  • Extending capabilities through Supabase

If you need to wire up an integration or push the back end further, that is a Lovable job, and it is worth the credits.

Why this works

Think back to that first afternoon I described, the one where the credits vanished into pixel tweaks. The reason it happened is that Lovable was doing everything, front end and back end, and both were billed the same way.

The split fixes that. Your coding agent handles the front-end edits for the cost of your existing Claude or Codex usage. Your Lovable credits go only toward the back-end work that genuinely needs them. You stop paying premium rates to move a button.

That is the whole system. Think in Claude chat, document in markdown, build the shell in Lovable, pull it local through GitHub, edit the front end with your coding agent, and save Lovable for the back end. Do it once and you will never go back to letting Lovable do all of it.

JM
Joshua McSorley

Marketing Systems Consultant. I help service businesses find and fix the gaps between their website, leads, and sales.

Ready to dig in?

Most service businesses have three or four of these gaps at once.

Run the free website assessment to see which ones are costing you leads right now. Takes about 60 seconds. No email required to see your results.

Run the assessment