Five days, not five months: what building with Lovable actually costs

Everything in the Building section of this site was made without me writing code as a profession: PriceCopilot, Private Vault, Ecosystem Navigator, a few internal tools for programs. I am a Lovable Certified Partner, which mostly means I have hit the limits often enough to know where they are. This post is the cost accounting, because the demos you see online skip it.

What genuinely takes days now. A working interface with real navigation, a database behind it, sign-in, a form that stores something, email going out, and a deployed URL you can send to a stranger. In 2021 that was a contract, a developer, a designer, six weeks and a budget conversation. Today it is an afternoon and an evening, and the second version arrives the same week. That compression is not marketing. It is the single biggest change in how I work.

What still takes weeks, and always will. Deciding what the product is. Finding the ten people who will open it more than once. Writing copy that a specific person recognises as being about them. Handling the case where the output is wrong and someone has already acted on it. Permissions, meaning who can see whose data and what happens when that assumption breaks. And the unglamorous maintenance question: when this breaks in four months, who gets the email.

So the cost did not disappear, it moved. It moved from build to judgement and from budget to attention. That is a good trade if you have judgement and a bad trade if your previous constraint was that building was hard enough to stop you from shipping things nobody wanted.

Three practical habits that came out of this, all learned the expensive way. First, one page before any project starts: who the first user is, what they do today instead, what would make them stop, and what I will consider a failure. If I cannot fill that in, the project does not exist. Second, ship the ugliest useful version, in front of a real person, within the first week. Not a waitlist. The thing. Third, decide early whether it is a prototype, a product, or a spreadsheet pretending to be a product. Most of what founders describe to me is a spreadsheet, and calling it that saves everyone a month.

The honest failure list matters more than the ship list. Several of my own builds are quietly dead. Not because the tooling failed but because I built them for an audience I had assumed rather than met, or because I solved a problem that was annoying rather than expensive. Cheap building makes that mistake easier to make and much cheaper to recover from, which is the actual benefit: the loss is a weekend, not a funding round.

There is also a real boundary I respect. Some problems still want an engineering team: heavy data, strict compliance, hard performance requirements, anything where a subtle wrong answer costs money or safety. I would rather say that in a first meeting than discover it in month three with someone else's budget. Knowing the boundary is most of what the certification is worth.

For founders and for the programs I work with, the useful version of all this is simple. Stop budgeting for a prototype. Start budgeting for the ten conversations that tell you which prototype. The build is no longer the scarce thing, and pretending otherwise is now the most expensive mistake available.