Turning your Claude project into a real SaaS: the full path
Your tool built with Claude or Lovable works and people use it. Turning it into a real SaaS takes seven building blocks the prototype lacks: accounts, data, permissions, payments, hosting, error tracking and legal. In what order, and at what cost.
Table of contents
One evening you opened Claude or Lovable, described the tool your company needed, and it works. Your team uses it every day, it may already replace software you were paying for, and a client asks whether they can have it too. Good news: the hardest part, finding a use, is done. What is left is turning that Claude project into a real SaaS, or at least a real tool: accounts, data that does not get lost, payments, and someone who answers when it breaks. Here is what is missing, in what order to add it, and what it costs.
What separates a Claude project from a real SaaS?
A Claude project is an application you had AI write for you: a shared artifact, an app generated with Claude Code, a prototype on Lovable or Bolt. A SaaS is software that customers pay for every month to use online. The difference is not on the screen. It is in everything that happens when strangers use it: their accounts, their data, their money, their mistakes.
| Topic | Claude project (prototype) | SaaS in production |
|---|---|---|
| Users | You and a few people you know | Strangers, who do things you did not plan for |
| Accounts | None, or one shared password | Sign up, log in, forgotten password, teams |
| Data | In the browser or a test database | A backed up database, each customer isolated |
| Payments | None | Subscription, invoices, dunning, cancellation |
| Going live | A demo link | A domain, emails that arrive, updates without downtime |
| When it breaks | You restart the conversation | An alert, a history, someone who fixes it |
Nothing in the right column is spectacular. That is exactly why AI skips it: when you ask for a quoting tool, it builds the quoting tool. It does not think on its own about the customer who forgets their password, or about the second customer who must not see the first one's quotes.
Which building blocks turn it into a SaaS?
Seven workstreams come up on almost every prototype we are shown. None is exotic. Each takes a few days when you know what to look for, and costs a lot when you discover it after an incident.
Accounts and organizations
Sign up, log in, forgotten password, invite a colleague. For a B2B SaaS, add the idea of an organization: a customer is a company with several users, not a single person. Start from a proven authentication library rather than letting AI hand write one.
A real database, backed up
Many artifacts keep data in the browser: it disappears when the user switches computers. You need a hosted database, automatic backups, and to have already tried restoring one. A backup you never tested is not a backup.
Permissions that isolate each customer
Every request must check who is asking and which organization the data belongs to. This is the block generated code misses most often: the screen hides the button, but the server still answers if you call it directly.
Payments and subscriptions
Stripe covers most of it: checkout page, monthly subscription, invoices, expired cards, cancellation. The trap is not the pay button. It is keeping your database in sync when Stripe tells you a payment failed or a customer left.
Hosting, domain and email
A domain of your own, hosting that allows commercial use, emails (confirmation, invoice, invitation) that land in the inbox and not in spam. And a separate test environment, so you never try a change on your customers' data.
Error tracking
When a customer sees a blank screen, they do not email you: they leave. An error tracking tool warns you before they do, with the context to fix it. Add readable logs on everything that runs without anyone watching (emails, payments, scheduled jobs).
The legal basics
Legal notice, terms of sale, privacy policy, a list of subprocessors for GDPR (your host, Stripe, your email tool, your AI provider if you call one). It is not code, but a business customer will ask for it before signing.
Block 3 deserves a closer look: it is the one behind data leaks. We list the checks in vibe coding: what to check before going to production.
In what order should you do it?
The classic mistake is to start with what shows (a new design, a landing page) and leave what protects for the end. The order that works is the opposite.
Phase 1: make the prototype safe
Put the code in a Git repository, move keys and passwords out of the code, connect a real database with backups, add accounts and isolation between customers. At this stage nothing changes for the user, and that is normal.
Phase 2: make it sellable
Payments, domain, emails, legal pages, error tracking. By the end of this phase, a stranger can sign up, pay and use the product without you stepping in.
Phase 3: make it grow
The real requests of your first customers, a dashboard to follow usage, the integrations people ask for. This is where the product gains value, and where delivery pace matters most.
To know where to stop before launching, we explain the difference between the two stages in MVP vs V1: what really changes.
How much does turning it into a SaaS cost?
The tools themselves cost little at first. The real cost is the time of someone who knows what to check.
On the tooling side: Stripe takes a fee per payment (around 1.5% + €0.25 for a standard European card, with no fixed subscription). Vercel's free plan excludes commercial use: count around $20 per month per member for the Pro plan. Add a hosted database, an email tool and a domain: a few dozen euros a month to start. Prices checked on October 23, 2026; they change, so check current terms.
On the work side, four ways to do it, with their real trade-offs:
| Option | What it costs | What works | What hurts |
|---|---|---|---|
| Keep going alone with Claude | Your evenings | Free or nearly, you learn | Nobody reviews security, and selling stalls |
| A freelancer | Daily rate or fixed price | Flexible, good for one clear job | Depends on one person, availability varies |
| An agency, per project | A quote, often five figures | Defined scope, full team | Every change after delivery is a new quote |
| A development subscription | A monthly fee (€1,990 excl. VAT per month at Figue) | Phases 1 to 3 move forward request by request, no quotes | One active request at a time: you have to prioritize |
To compare these amounts with a full build, we detailed the ranges in how much it costs to build a SaaS. Transparency: Figue sells the subscription option, so it is our preference. It does not suit everyone, see below.
Who is it the right time for?
Not every Claude project is meant to become a SaaS sold to others. But an internal tool that runs your business (your customers, your quotes, your official documents) deserves the same care: blocks 1 to 3 and 6 apply to it too.
If your tool is meant to replace software you pay for today, data migration and the switchover have their own traps: we cover them in replacing your business software with an AI-built tool. And for an honest comparison with going on alone, see Figue vs doing it yourself with AI.
FAQ
Frequently asked questions
What we are asked most when a founder arrives with a project built with Claude.
Can you sell an app coded with Claude?
Yes. The code AI produces for you is yours and can power a commercial product. What matters is not the tool that wrote it but what surrounds it: accounts, isolated and backed up data, payments, terms of sale and someone who fixes it when it breaks.
Do you have to rewrite everything to become a SaaS?
Rarely. In most cases the prototype gets hardened block by block: Git repository, database, accounts, permissions, payments. A rewrite is only justified when the structure prevents adding accounts and customer isolation cleanly, which a developer sees by reading the code.
How long does it take to go from prototype to SaaS?
For a simple prototype, the basic blocks (accounts, database, permissions, payments, going live) usually take a few weeks of work for an experienced person. The real timeline depends on the state of the code and on how many special cases your business has.
Can Claude add accounts and payments itself?
It can write the code. The risk lies elsewhere: it does not know what it forgot. A payment flow that works in test but ignores expired cards, or permissions checked on screen but not on the server, do not show up in a demo. You need someone who knows what to check, and who reviews.
What is the difference between an AI prototype and an MVP?
A prototype shows the idea works, for you. An MVP is the smallest version a customer can use alone and pay for: it therefore includes the accounts, data protection and payments the prototype lacks.
