# Why we build StellarFirm, and why Lovable is part of it

> Lessons from how Lovable was built, why StellarFirm connects to Lovable instead of building its own app builder, and how to grow a Lovable app with a team.

By StellarFirm team. Published 2026-11-04. 7 min read.

Keywords: lovable, ai app builder, vibe coding, ai agent team, stellarfirm coder, approvals, launch an app
Tools covered: StellarFirm, Lovable

## Key takeaways

- Lovable's own story says the hard part was never the first app: it was narrowing the problem, matching an agent's freedom to what models can do, and learning from every failure.
- StellarFirm does not build another app builder. Our Coder signs in to your own Lovable account, writes one clear prompt at a time, follows the build and checks it against your brief.
- Every step that spends your Lovable credits or publishes waits for your Approve. Deleting, unpublishing and changing who can see a project are not offered at all.
- Once the app exists, the rest of the company is the work: a landing page, legal pages, payments, launch posts and support. That is what a team of StellarFirm assistants is for.

Lovable's co-founder Anton Osika just wrote down how Lovable was built and why the team keeps rebuilding it. It is one of the most honest accounts of building with AI agents we have read, and it explains a lot about why StellarFirm exists and why our Coder works with Lovable instead of trying to be Lovable. This post pulls out the ideas we think matter most, then shows how we use them and how you can take a Lovable app further with a team of StellarFirm assistants.

## What did Lovable learn on the way?

Osika started from a plan in 2023: people who cannot code would create, deploy and improve software through chat and see the result at once. The plan held up. The way of getting there changed many times. Lovable now reports more than 70 million projects created and over 100,000 pull requests to its own code. Five lessons stand out.

### 1. Narrow the problem to get a head start

The team worked only on new apps, with one opinionated stack, and dropped an early screen that let people pick a frontend framework. Owning the libraries, the structure and the runtime meant every failure could be studied and every fix could reach many projects at once. Their rule: constrain the problem, control the execution, learn from the results.

### 2. Give an agent only as much freedom as the model can handle

Lovable built a sophisticated system of autonomous agents that planned tasks and handed them to subagents. It got stuck in rabbit holes and finished at unpredictable times. More freedom made the product less dependable. So they deleted most of it and went back to a predictable chain: one answer with the file changes, retries and error handling, and a live preview the person checks and steers. The person stays in control of each change.

### 3. Short notes beat training a model

The 2023 plan expected fine-tuned models. What worked was simpler. Engineers read the chats behind broken apps and wrote short notes on recurring mistakes, such as only using icons that really exist in the icon library. A retrieval step added the right notes to each request. Osika calls it a kind of scaling law: every note made the agent more reliable, with no training run. A later tool that handed the agent known problems and their fixes cut the rate at which people got stuck by 5%.

### 4. Speed comes from the feedback loop

A coding agent is only as fast as it can check and fix its own work. Lovable keeps a sandbox running per project, updates the preview without a full build and runs incremental type checks, so the agent sees an error and fixes it straight away.

### 5. Keep the whole computer, not just the files

Lovable's sandboxes now save memory, CPU state and disk, and come back in seconds days later. They can fork a running app, its database included, so agents try different approaches from the same starting point.

And the open problems Osika names are the ones we think about every day: putting the drudgery of running software on autopilot, where trust is the hardest part and a misunderstood request must never delete data, and becoming "a platform people run entire businesses on".

## Why do we build StellarFirm?

Because a working app is the start of a business, not the end of it. Most people who ship their first app on Lovable meet the same wall the next morning: the landing page, the terms and privacy pages, taking payments, the launch posts, the first support emails, the bookkeeping. Each is a job someone used to hire for.

StellarFirm is a company of AI Agent Assistants for that work. You are the CEO. The Coder, Marketing, Legal, the Accountant, Sales, Support, the Executive assistant and the others each do their own job, in their own computer, and you approve what goes out. We took the same lessons Lovable describes and applied them to the whole company instead of one codebase:

- **Narrow each job.** Every assistant has one role, its own skills and its own tools, instead of one agent that tries to do everything.
- **Match freedom to what is safe.** Reads, drafts and the things you asked to be made run on their own. Sending to people, publishing, deploying, deleting and spending your money wait for your Approve, and once you approve a kind of action the same assistant stops asking for it.
- **Write knowledge down.** Assistants load skills only when a task needs them, and your playbooks tell them how your company does things. It is the same idea as Lovable's notes: written lessons that make the next run better without training a model.
- **Keep the loop short.** The Coder runs your tests and reads what changed before it shows you anything.

## Why does our Coder work with Lovable?

Lesson one says it plainly: a tool gets good by owning a narrow problem and learning from millions of runs. Lovable has done that for new web apps. Building a second app builder inside StellarFirm would mean starting that learning again from zero. So we connect to it instead.

Lovable runs its own AI, so our Coder does not need to write the app itself. Its job is the one lesson two describes: write one clear, complete prompt, read what Lovable did, check it against your brief, and steer with small follow-ups. Because the hard work happens in Lovable, StellarFirm runs a single Coder on a light model for these chats, which keeps the StellarFirm side of a build cheap.

Lovable registered StellarFirm's app on its MCP server, so you sign in with your own Lovable account, approve StellarFirm on Lovable's page, and your sign-in is stored encrypted in StellarFirm cloud. Here is how a build goes:

1. You give the Coder a brief, or ask the CEO assistant to hand one over: who the site is for, what a visitor should do, the pages, the real copy, your colors and logo, and what must not change.
2. The Coder turns it into a first prompt for one key screen. A long brief goes into the project's instructions in Lovable, so each prompt stays short.
3. You see the exact prompt on the Approve card and approve it. The Coder creates the project and shares the preview and editor links.
4. The Coder follows the build, reads the diff and checks it against your brief, then sends small follow-up prompts, each after your Approve.
5. When you ask to publish, you approve that too.

The rules follow Osika's point about trust. Creating a project, sending a prompt, answering Lovable when it pauses and publishing all wait for your Approve, because they run on your own Lovable account and use your Lovable credits. Nothing is sent twice: if a send looks stuck, the Coder checks the result instead of resending. If Lovable pauses for a decision, the Coder tells you what it wants to do and passes on your answer; it never decides for you. And deleting, unpublishing or changing who can see a project is simply not offered. You do those in Lovable.

## How do you grow a Lovable app with StellarFirm?

Once the app is live, the rest of the team takes over the work around it. A good first week looks like this:

| Job | Who does it | What you approve |
| --- | --- | --- |
| Change the app | The Coder, through Lovable | Each prompt and the publish |
| Landing page copy, launch posts, SEO | Marketing | Anything posted or sent |
| Terms and privacy pages | Legal | Nothing until you publish them |
| Payments and the books | The Accountant, with Stripe connected | Any money that moves |
| First customers | Sales | Every email that goes out |
| Questions from users | Support | Every reply that goes out |

A few habits help:

- **Write the brief once.** Put who the app is for, the tone and the rules in your company brief, so every assistant starts from the same facts.
- **Ask in plain words.** "Coder, in the booking project in Lovable, add a waitlist form to the home page and show me what changed" is enough.
- **Keep prompts small.** Lovable's own lesson applies here: one key change per prompt is easier to check and cheaper to fix.
- **Follow the launch guide.** In StellarFirm, the launch guide walks you from something built to something live, with one task per assistant.

## Prompts to start with

```prompt title="Build from a brief"
Coder, build this in Lovable: [brief]. Start with the home page, show me the preview, and do not publish until I Approve.
```

```prompt title="Change a Lovable project"
Coder, in the [project] project in Lovable, [change]. Keep everything else as it is, and show me what changed.
```

```prompt title="Launch what you built"
CEO, my app [project] is live at [address]. Have Marketing draft the landing page copy and three launch posts, have Legal draft the terms and privacy pages, and show me each draft before anything is published or sent.
```

Lovable makes the app. StellarFirm gives it a company. Start at [stellarfirm.ai](https://stellarfirm.ai), connect Lovable from Integrations, and give the Coder your first brief.

## Frequently asked questions

### Does StellarFirm replace Lovable?

No. Lovable builds the app with its own AI. StellarFirm's Coder works with you on your Lovable projects from your own account, and the other assistants take on the work around the app: marketing, legal pages, payments, sales and support.

### Which Lovable steps ask for my Approve?

Creating a project, sending a prompt, answering Lovable when it pauses and publishing. Reading your workspaces, projects, messages, files and changes runs on its own.

### Whose credits does a Lovable build use?

Creating a project, sending a prompt and answering a pause use your own Lovable credits, not StellarFirm credits. The Coder's own work in StellarFirm, such as writing the prompt and checking the result, uses StellarFirm credits.

### How do I connect Lovable?

Open Integrations in StellarFirm, pick Lovable, press Sign in with Lovable and approve StellarFirm on Lovable's page. The page then says it is connected and lists your recent Lovable apps.

### Can StellarFirm delete or unpublish my Lovable project?

No. Deleting, unpublishing, changing who can see a project and editing your workspace instructions are not offered. You do those in Lovable.

## Sources

- [Lovable blog: How we built Lovable, and why we keep rebuilding it](https://lovable.dev/blog/how-we-built-lovable-and-why-we-keep-rebuilding-it)
- [StellarFirm docs: Lovable](https://stellarfirm.ai/docs/integrations/lovable)
- [StellarFirm docs: The Coder](https://stellarfirm.ai/docs/personas/coder)

---

Source: https://stellarfirm.ai/blog/why-we-build-stellarfirm-with-lovable