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

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#

Coder, build this in Lovable: [brief]. Start with the home page, show me the preview, and do not publish until I Approve.

Coder, in the [project] project in Lovable, [change]. Keep everything else as it is, and show me what changed.

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, connect Lovable from Integrations, and give the Coder your first brief.