# Adorable

> Describe a business in any language and get a complete multi-page site — a Lovable alternative that ships as a SaaS under your own brand.

Source page: https://saascode.ai/products/adorable
Machine-readable record: https://saascode.ai/products/adorable.md

One-time purchase · full source code · self-hosted by the buyer.

Price: $229 (one-time)

## How to read this document

Written for a model auditing this product on a buyer's behalf. Two labels
appear throughout and they mean different things:

- **measured** — produced by a script reading the product's own source tree
  or database at the stated date. The method is named beside each number.
- **stated** — written by the seller. True or not, it is a claim, and this
  document does not ask you to treat it as evidence.

The live demo is the strongest verification available from outside: it runs
the same source a buyer receives. Nothing to sign up for — the public side is
open, and the seeded credentials below get you into each role.

## What it is

Adorable turns a description of a business — written in any language — into a complete multi-page website: clean markup, working contact forms and search tags. The result is then edited three ways: by chatting with an AI, in a visual editor, or directly in code.

## Live demo

Two doors into the same running instance, and the same source a buyer
receives. There is no account to create; the public side is open, and the
seeded credentials below sign you into each role.

- **Guided (recommended):** https://saascode.ai/demo/adorable — our shell, with a role switcher and
  the credentials in the menu. Best for a person.
- **Direct:** https://adorable.saascode.ai — the product on its own, no chrome.
  Best when you are relaying steps to someone, or fetching a page.

1 roles seeded on the demo (of the 4 the schema defines — the build data below counts them all). Credentials are published deliberately: these
are demo accounts on a public demo instance, and a reviewer who cannot get
in cannot verify anything.

- **Platform admin** (`super_admin`) — `admin@demo.com` / `demo123`
  Configures plans, prompts, models and platform settings.

Or open a role directly: https://saascode.ai/demo/adorable?role={role}

## Measured build

*measured — each number names the method that produced it.*

- **roles: 4** — distinct roles accepted by the role CHECK constraint: admin, member, super_admin, viewer
- **tables: 58** — distinct CREATE TABLE statements across every applied migration
- **migrations: 94** — .sql files in supabase/migrations
- **page modules: 73** — files named page.tsx under src/app, excluding node_modules and .next
- **source lines: 120,924** — lines of code (comments and blank lines excluded) across 805 TypeScript files (110,183) and 98 SQL files (10,741); node_modules and .next excluded
- **api route files: 196** — files named route.ts under src/app/api
- **http operations: 269** — exported HTTP method handlers across those files, de-duplicated per file, OPTIONS excluded as CORS preflight
- **schema graph: 58 tables, 90 relationships** — parsed from the applied migrations

A large number here is scope, not quality. It says the product models a
real domain rather than a CRUD skeleton; it says nothing about code
quality, duplication, test coverage or maintainability, and should not be
read as if it did.

Release: v1.0.0

## Complete capability inventory

23 capabilities. Each summary is *stated* — selected from the
product's own buyer documentation, or written by the seller where marked.

### AI creation & editing

- **AI Translation** *(seller-authored)* — AI translation helps the operating team expand product copy beyond the default language without rebuilding the interface. Languages and translated strings are managed as data, so new text can be reviewed and adjusted after generation instead of becoming an opaque, one-time code change.
- **AI Site Generation** — A description of a business produces a complete multi-page site. Responses stream, so the site appears as it is written rather than after a wait.
- **Visual Editor** *(seller-authored)* — The visual editor lets a customer point at the part of a generated site they want to change and work directly against the live preview. It preserves the same underlying project used by the other editing surfaces, avoiding a separate visual copy that drifts from later revisions.
- **Code Editor** *(seller-authored)* — The code editor gives precise control when a requested change is easier to express in markup or styles than through a broad instruction. It keeps the project files, open tabs, unsaved state, and inline AI assistance together, so exact edits remain part of the same site workflow.
- **Snapshot System** *(seller-authored)* — Snapshots preserve earlier project states before generation or manual editing changes the site. A customer can create a named restore point, inspect the history, and return the project to a prior version, reducing the cost of experimenting with a new direction.

### Publishing & delivery

- **Asset Manager** — A per-project asset manager for images, fonts and documents, with drag-and-drop upload.
- **Site Publishing** — Every project publishes to a subdomain on every tier, including free.
- **CSV Export** *(seller-authored)* — CSV export gives platform staff a portable copy of supported operational data for analysis or handoff outside the product. Export surfaces are present across admin reporting workflows, keeping the data usable when a spreadsheet or another business system is the practical next step.
- **SEO Tools** *(seller-authored)* — SEO tools keep search metadata with each project and carry those decisions into a published site. Customers can manage page-level identity and generated search artifacts as part of the site workflow, so discoverability is not a separate cleanup pass after the site leaves the builder.
- **Custom Domains** *(seller-authored)* — Custom domains let a customer put a published site under an address they control. The capability is inherited as a higher-tier option, with domain state and verification kept with the project so the operating business can monetize branded destinations separately from basic subdomain publishing.

### Accounts & commerce

- **Authentication** *(seller-authored)* — Authentication gives each customer a private account for entering the builder, returning to saved projects, and keeping work attached to the right identity. The shipped access flow covers registration, sign-in, recovery entry, session handling, and role-aware destinations for members and platform staff.
- **Multi-tenancy** *(seller-authored)* — Customer records and generated-site data are partitioned through organization-scoped storage and database policies, so one installation can serve separate accounts without mixing their projects. The current product configuration hides team-oriented organization controls, making this data boundary distinct from a promised collaboration experience.
- **Payment Processing** *(seller-authored)* — Payment processing lets the operating business attach its own provider and sell the plan ladder already modeled in the product. Subscription state and usage limits are kept with each account, while provider choice remains an operating decision instead of a storefront-specific dependency baked into the product.
- **Transactional Email** *(seller-authored)* — Transactional email carries account and platform notifications through a provider selected by the operating business. The capability centralizes provider handling and message delivery so customer-facing email can follow the installed brand while remaining replaceable as the business changes vendors.
- **2FA** *(seller-authored)* — Two-factor authentication is represented as a plan-controlled security capability in the shipped feature model. The available buyer evidence establishes the flag and security surface, but does not establish a complete enrollment and challenge flow; it should be validated before the operating business promises it to customers.
- **Social Login** *(seller-authored)* — Social login lets the operating business enable selected identity providers alongside email credentials. Login and registration discover the enabled provider list at runtime, while provider credentials remain centrally managed and masked, allowing the customer-facing choices to change without rebuilding the product.
- **Team Invitations** *(seller-authored)* — Team invitations remain a plan-controlled entry in the feature matrix, but the current product configuration declares individual use and the buyer corpus excludes team collaboration from the shipped scope. The available evidence therefore does not support presenting invitations as an active customer workflow.

### Platform extensions

- **Error Monitoring** *(seller-authored)* — Error monitoring gives the operating team a place to capture failures that would otherwise surface only as customer complaints. It belongs to the shipped platform foundation, while the destination and credentials stay under the buyer's control rather than being tied to a factory account.
- **API Access** *(seller-authored)* — API access gives the operating business managed keys for connecting external tools to the installed platform. Key creation, revocation, and activity records are part of the administrative surface, so access can be issued deliberately and withdrawn without sharing a privileged platform credential.
- **MCP Server** *(seller-authored)* — The MCP capability provides a plan-controlled connection point for compatible AI clients when the operating business enables it. It ships as an optional extension rather than a requirement for generating or editing sites, keeping the core product usable without exposing another integration surface by default.
- **Webhooks** *(seller-authored)* — Webhooks let the operating business send product events to systems that need to react outside the platform. Administrative controls cover endpoints, event selection, delivery history, and retries, giving integrations an observable handoff instead of an undocumented background call.
- **Template Library** *(seller-authored)* — The template library is carried as a plan-controlled flag reserved for a later product expansion. The buyer evidence does not establish a customer-ready template marketplace or selection workflow today, so this entry records the shipped control without claiming a finished library experience.
- **Form Submissions DB** *(seller-authored)* — Form-submission storage is carried as a plan-controlled flag reserved for later expansion. Published sites can send forms onward, but the buyer corpus explicitly excludes an in-product submissions database from the shipped scope, so no stored-inbox workflow is claimed here.

## What each system gives the operator

*stated.*

- **AI creation & editing** — Turn a business brief into a site that stays precise through every revision.
- **Publishing & delivery** — Move finished sites to branded destinations without trapping the work.
- **Accounts & commerce** — Give customers controlled access while the business owns its plans and revenue.
- **Platform extensions** — Connect the builder to the wider operating stack on deliberate terms.

## The problems it was built to solve

*stated — the seller's argument, given in full so you can judge it.*

### Every revision stays under the same creative control.

Website work becomes expensive when every revision starts a new handoff. A customer explains the business once, then repeats the same context to a designer, a developer, and whoever handles the next change. Small corrections wait behind larger work, precise requests return as approximations, and the finished site slowly stops matching the decisions that made it coherent. The cost is not only production time. It is the reluctance to improve a site because every improvement threatens to reopen the entire project and erase details that were already settled.

### Finished sites remain assets the business can move and own.

A website stops feeling like an asset when its owner cannot separate the result from the tool that produced it. The first version may arrive quickly, but the long-term cost appears later: changing providers becomes a rebuild, a branded address depends on somebody else's roadmap, and the business keeps paying simply to retain access to work it already approved. That dependency makes every future decision narrower. A durable site business needs a clear path from draft to a destination customers recognize, without turning departure into another development project.

### Customer growth no longer multiplies routine platform administration.

The first customers are easy to manage by memory. Growth makes that habit expensive: access is granted informally, plan differences live in scattered notes, failures are discovered through support, and external systems depend on one-off handoffs nobody wants to touch. The result is a product business whose recurring work grows as quickly as its revenue, with every new account adding another chance for an invisible mistake. Sustainable operations need customer access, commercial rules, and system connections to remain deliberate even when the founder is no longer watching every change.

## What it takes to run it

*stated — external services the buyer supplies and pays for directly.*

- **Node host** (required) — No platform lock-in.
- **Supabase** (required) — Postgres with row-level security, applied by the shipped migration scripts.
- **An AI provider key** (required) — Generation and every AI edit run on it. The provider's model catalogue is read live.
- **Object storage** (required) — Project assets — images, fonts, documents.
- **A payment provider** (required to charge) — Configured by the operator, not hardwired.
- **Email provider** (required) — Account and notification email.
- **DNS control** (per custom domain) — Only for site owners attaching their own domain.

## FAQ

**What exactly do I receive after purchase?**

The complete source repository behind the live demo — 120,924 lines across the application and its database, 58 tables defined by 94 migrations that the shipped scripts apply for you, plus the seed data, the demo accounts and the setup documentation. Not a subset and not a scaffold: the same code that runs the demo you just used.

**Is the live demo the same product whose source I receive?**

Yes. The Adorable demo runs the delivered release (v1.0.0), and the build figures on this page are measured from that same source — not from a showcase build kept separately.

**Can I test every account role before buying?**

Yes — all 1 of them: Platform admin. Each one is seeded in the live demo and reachable from the role board above, so you can inspect the product from the customer's side, the agent's side and the administrator's side before you decide.

**Is this a complete product or a starter template?**

Complete. 73 page modules and 269 HTTP operations, with authentication, roles, billing, an administration panel, background jobs and seeded demo data all wired and running. A template gives you the shape of an application; this is one you can deploy and start operating.

**Can I rebrand and modify it?**

Yes, without asking. The name, identity, copy, styling and code are yours to change. Rebranding and operating it as your own service is exactly what the licence is for.

**What does the licence allow?**

A perpetual, worldwide, non-exclusive, non-transferable licence to the product you bought and to every update released for it. The Standard licence covers one business — yours. If you deploy for clients, the Client licence covers up to five. You can modify it, rebrand it, deploy it and charge your own customers.

**Can I resell the source code?**

No. Reselling, redistributing, sublicensing or giving away the source itself is not permitted under either licence. You build and deliver products with it — the code stays with you.

**What services and ongoing costs are required?**

You bring your own accounts, so we never mark anything up and there is no ongoing cost to us beyond the purchase. Required: Node host, Supabase, An AI provider key, Object storage, A payment provider, Email provider, DNS control. Optional: none. The table above says exactly what stops working without each one; most have usable free tiers at low volume.

**How difficult is deployment?**

Two ways, and most buyers use the first. The installer in your saascode dashboard walks it: you create free accounts at Vercel and Supabase, connect them, and it provisions the database, applies 94 migrations, seeds the data, deploys and verifies the result — you watch the steps go green. Or take the source and do it yourself with the shipped scripts and docs, which is the same sequence run by hand.

**What updates and support are included?**

Updates to that product for as long as we maintain it — no renewal fee and no expiry date on your access. Support covers download problems, defects in the code as shipped, questions about what the product does and how it is structured, and licence questions. It does not cover debugging your own modifications, building features for you, or setting up your hosting and third-party accounts.

**Why does a complete codebase cost $229?**

Because it was built once and is distributed many times. SaaSCode builds each product and ships the same finished release through the catalog, so the price reflects repeatable distribution — not a reduced codebase, an unfinished template, or what the same work would cost commissioned.

**Do I need to be a developer?**

No, for the normal path. You create free accounts at Vercel and Supabase, connect them to the installer in your saascode dashboard, and it does the deployment for you — provision, migrate, seed, deploy, verify. What it asks of you is creating two accounts and copying a token, not writing code. If you would rather deploy it yourself, or host it somewhere else, the full source and the scripts are yours to do that with. Running the product day to day needs no technical skill at all: that happens through its own interface, which is what the demo shows.

## Licence

The buyer receives the complete source and may deploy, modify and operate it
as their own SaaS, charging their own customers. The source itself is not
resold or redistributed: you build and deliver **with** it, you do not sell **it**.

## What this document cannot tell you

Stated plainly because a review that misses it is not a review:

- code quality, duplication, or architectural consistency
- test coverage
- query performance under load
- security posture beyond what the stack implies
- how maintainable it will be in a year

Scope is measurable from outside; implementation quality is not. Anyone
evaluating this should say so rather than infer quality from size.

## Written about it

- [Adorable vs Lovable — and vs building it yourself](https://saascode.ai/inside/adorable-vs-lovable-and-vs-building-it-yourself.md)
- [Best AI website builder source code in 2026 (own it, don't rent it)](https://saascode.ai/inside/best-ai-website-builder-source-code-2026.md)
- [How we built an AI website builder you can actually own](https://saascode.ai/inside/how-we-built-an-ai-website-builder-you-can-own.md)

## Links

- Catalog page: https://saascode.ai/products/adorable
- Product record: https://saascode.ai/inside/products/adorable
- Live demo: https://adorable.saascode.ai
- Every product: https://saascode.ai/llms.txt