How to hire a Lovable agency: 7 questions to ask first

What a Lovable agency actually does

Lovable removes the setup cost of software: no scaffolding, no CI pipeline, no infrastructure decisions before you have a working screen. That means the value an agency adds shifts. It is no longer "we can write the code and you can't." It is judgment about what to build, and the discipline to finish.

In practice a good Lovable engagement looks like: a discovery pass on how your team actually works, a working prototype inside the first week, then iteration against real data and real users until people use it without being told to. The build is the easy half.

Which means the differences between agencies show up in places that have nothing to do with prompting.

Partner status: what Select and Certified actually mean

Lovable runs a partner program and publishes a directory of vetted builders at lovable.dev/experts, headed "Our Expert Partners". Listings show how many times a partner has been hired ("100x hired"), how long they have been a partner ("Partner since Apr 25"), their hourly rate, and their minimum budget.

Many agencies advertising "official Lovable partner" are not in that directory. The phrase is unregulated on someone's own website. The directory is not. Before you sign anything, search the directory for the agency's name. It takes ten seconds and it is the single highest-signal check available to you.

The seven questions

1. Are you in the Lovable partner directory, and at what tier?

Ask for the listing, not a badge image. Badges are files anyone can put on a page. A directory entry has a partner-since date and a hire count attached to it.

2. Do we own the code, and can we export it?

The platform is not the constraint here, the contract is. Lovable's own documentation is unambiguous: projects sync to GitHub or GitLab, applications are "standard Vite + React projects", and you can "clone your repository, modify it outside Lovable, deploy it on your own infrastructure, or fully self-host without restriction."

So if an agency is vague about ownership, that is a choice they are making, not a limitation they inherited. Get it in writing that you receive the repository, that it transfers to your GitHub organisation, and that nothing critical lives in an account only the agency can access. An agency that gets vague here is planning to rent your own product back to you.

3. What happens when we outgrow the prompt?

There is a ceiling to what you should build conversationally: deep refactors, unusual integrations, and performance work want an engineer in a real codebase. The honest answer is "at that point we export and continue in the repo with engineering tools." An agency that claims no ceiling exists has not hit it yet, which tells you something about the size of what they have shipped. We wrote up where that line falls in Lovable vs Claude Code.

4. Who designs auth, roles, and permissions?

This is where fast builds quietly fail. If five district managers should each see only their own stores, that is a data-model and row-level-security question, not a UI question. Ask specifically how they scope data per user, and ask what happens when someone changes teams.

5. Show me a build that is still in daily use after six months.

Not a portfolio thumbnail. A tool with a named team using it every week, and a number attached to what changed. Most portfolio pages in this category are screenshots of demos. Anything that survived six months of real users has been through the unglamorous work: edge cases, permission changes, data that arrived in the wrong format.

6. Who drives adoption after launch?

Shipping is half the job. Tools die in month three because nobody owned rollout, nobody watched usage, and nobody fixed the two things that annoyed people on day one. Ask what their involvement looks like in weeks 3 through 12, and whether they instrument usage at all. If the engagement ends at handover, budget internally for the half of the work that is left.

7. What exactly is the handover?

Repository access, environment variables and secrets, a written data model, admin credentials, and a named person who can change the thing after the agency leaves. Ask for that list explicitly. "We'll send everything over" is not a list.

Red flags

• Per-seat pricing on a custom build. You are buying a tool, not renting a platform. Seat pricing on bespoke software means the incentives are pointed away from you.
• No discovery. If nobody asks how your team works before quoting, you will receive a generic app with your logo on it.
• Estimates in months for a first working version. On this stack, a working first version is weeks. Months usually signals a traditional process wearing a new label.
• Portfolio with no named clients or numbers. Anonymity is sometimes legitimate. Total anonymity across every project is not.
• Vagueness about code ownership. Covered above, and worth repeating: this is the one that costs the most later.

What it costs

Rates in the Lovable partner directory commonly sit around the $100/hour mark with project minimums from roughly $1,000, though both vary widely by partner and region. For a single internal tool with real data and auth, expect a project fee in the low five figures rather than the high five figures a traditional dev shop would quote for the same scope.

Two commercial models are common, and the difference matters more than the headline number:

Neither is a trap. Choosing the first when you have nobody to maintain the result is the trap.

The question behind all seven

Every question above is really asking one thing: does this agency understand the work your team does, or only the tool they build with? A Lovable specialist who has never sat in a pipeline review will hand you a beautiful dashboard that answers the wrong question. Domain knowledge is the part that cannot be prompted.

If you are building for a revenue team specifically, our guide to custom GTM tools covers what sales, account management, and customer success teams actually ask for.