All posts
Workflow

How to enable GitHub sync on your vibe-coded app (and why you should)

Connecting a Lovable or Bolt project to GitHub gives you a copy of the code you own, a full history you can roll back to, and the route onto real hosting later. Here is how to turn it on.

Eve Anderson

3 min read

If you’ve built something in Lovable, Bolt or a similar tool and haven’t connected it to GitHub yet, do that next. It costs nothing on a personal account, and it’s the step that most of the other advice on this blog assumes you have already done.

What syncing actually does

GitHub is where code is stored. When you turn syncing on, the builder pushes a copy of your app’s code into a repository on your GitHub account and keeps pushing as you make changes. Lovable and Bolt both make this two-way, so edits committed on GitHub come back into the builder as well.

Until you do it, your code exists in exactly one place, inside the tool that generated it. Afterwards there’s a second complete copy on an account that belongs to you, and it stays there whatever happens to your subscription.

Why it is worth doing early

  • You own the work. If you stop paying for the builder, get locked out of it, or outgrow it, the code is safe and complete somewhere else. Private repositories are free on personal accounts, so there’s no cost to this.
  • You get an undo that goes back further than the last session. GitHub keeps every version of every file. When a productive afternoon turns into a broken app, you can look at exactly which lines changed and restore the last version that worked, instead of asking the builder to undo its own work and hoping.
  • It’s how you get onto real hosting. Vercel, Netlify, Railway and the rest deploy from a repository. Without one there’s no move to make, which makes this step one of getting off the builder’s platform.
  • It’s how you bring in help. The first thing any developer you hire will ask for is the repository link. With sync on you add them as a collaborator in two clicks rather than trying to export a copy of the project by hand.

Turning it on

The exact buttons move around as these tools ship updates, so treat this as the shape rather than a precise map. It’s the same three steps almost everywhere:

  1. Create a free GitHub account at github.com if you don’t have one. A personal account is plenty.
  2. Find the GitHub option in your builder, usually near the project or export settings. You will be asked to authorise the builder to access your account, and you can restrict that access to a single repository rather than everything you own.
  3. Let it create the repository and push. The builder makes a new repository and sends the code up. Changes sync from then on, usually within a few seconds of each edit.

When it finishes, open the repository on GitHub and check that you can see your app’s files and that the commit list is filling up as you work. If the repository is empty or the commits stopped days ago, the connection has dropped, which happens occasionally after a builder update and is worth catching early rather than the day you need the history.

One habit worth having

You don’t need to learn Git or the command line for any of this. The one thing worth knowing is that every version is kept, so when a session goes badly you can open the repository, find the commit from before it went wrong, and restore the app to that state rather than trying to prompt your way back.

Turning on sync won’t make the app faster or more secure by itself. It gives you a copy of your work that nobody can take away, a history you can rewind, and the thing every host and every developer will ask for first. Nothing else on this blog does as much to keep your options open.

Keep reading

The opening slide of the AI under the hood talk, reading "AI under the hood: not magic, just unimaginable scale".
AI

How does AI work under the hood?

A talk I gave on what’s actually happening inside modern AI. No magic, just patterns learned from data at a scale that’s hard to picture, from a single Titanic passenger list to large language models.

Eve Anderson

1 min read
Read
Launch

The launch checklist for an AI-built app

Everything I check before an AI-built app meets real users: security, data protection, reliability, performance, scaling, deployment, code quality and accessibility, with the concrete points under each and how to prioritise them.

Eve Anderson

10 min read
Read
Privacy

What GDPR actually asks of your AI-built app

A practical, engineer-not-lawyer walk through the GDPR basics an AI-built app needs to get right, and the two things to fix before you launch.

Eve Anderson

6 min read
Read