# Known limitations

> What Vaulter apps are made of, what they are great at, and where the edges are today.

Vaulter is honest software, and this page is the honest map of it: what your apps are made of, what that makes them great at, and where the edges are today. Knowing the edges up front saves you from discovering them mid-project.

## What a Vaulter app is

Every Vaulter app is a real, modern web app with a standard, well-chosen stack:

- **React 18 + TypeScript** for the interface, as a single-page app with client-side routing.
- **Tailwind CSS and the shadcn/ui component library** for styling and UI components.
- **A built-in Postgres database** with row-level security enforcing [data privacy](/docs/data/data-privacy).
- **Built-in user accounts** with email and social sign-in ([add sign-in](/docs/auth/add-sign-in)).
- **A global edge network** serving the published app over SSL at your subdomain or [custom domain](/docs/publish/connect-domain).

This is not a toy format. It is the same stack many professional teams choose by hand, and you can [read and edit all of the code](/docs/your-app/code-editor).

## Great fits

The stack above makes Vaulter excellent for the large middle of the web:

- Dashboards, admin panels, and internal tools
- Booking, scheduling, and directory apps
- SaaS products with accounts, plans, and data per user
- Marketing sites, landing pages, and portfolios
- Community apps: boards, lists, votes, submissions
- Storefront-style catalogs with checkout through the Stripe connector

## The edges

### One framework, on purpose

Apps are React single-page applications. Vaulter does not generate Vue, Angular, Svelte, Next.js, or plain-HTML projects, and it does not do server-side rendering. If you need to bring an existing codebase written in another framework, Vaulter cannot import it; describing the app and rebuilding it in Vaulter is the path.

### The browser is the runtime

Your app's logic runs in the visitor's browser and talks to the built-in database and to [connectors](/docs/integrations/connectors). There is no custom server process to write:

- **No long-running background jobs or scheduled tasks.** Work happens when a user is in the app.
- **No custom server endpoints.** Third-party services are reached through connectors, which proxy your calls securely, rather than through server code you write.
- **Real-time collaboration** (several people editing the same thing and seeing keystrokes live) is not a built-in primitive today. Apps share data through the database, and see each other's changes on refresh or re-query.

### Packages: yes, within reason

The agent can add packages from npm beyond the built-in set (charts, date handling, forms, and a broad set of UI libraries are already included). Packages that assume a Node server, a build plugin, or filesystem access will not work, because there is no server or build config to modify.

### Web apps, not app stores

Vaulter builds web apps. There are no iOS or Android binaries and no app-store submissions. Published apps work well in mobile browsers, and on Pro they can be installed to the home screen as a PWA, which covers most "I want it on my phone" needs without a store.

### Sign-in is the gate to personal data

Per-user privacy works by knowing who the user is, so reading personal or shared data requires being signed in. Public pages and public tables work for signed-out visitors, but there is no anonymous write path: a visitor must have an account before your app can save things for them.

### Scale and size

- File uploads are capped per plan: 10 MB on Free, 50 MB on Starter, 100 MB on Pro and Teams.
- Free apps support up to 20 signed-in users; paid plans lift this.
- Very large apps (hundreds of screens) push against what the agent can hold in one view. Vaulter handles substantial apps well, but it is a builder for products, not for monoliths.

## Where AI itself has edges

Separate from the platform, the agent has the strengths and weaknesses of AI:

- **It is excellent at** building screens, forms, data models, flows, and integrations from a clear description.
- **It can misread vague requests.** "Make it better" produces a guess; "make the cards bigger and move the filter above the list" produces the change you meant. See the [prompting guide](/docs/building/better-results).
- **Complex algorithmic logic** (custom pricing engines, intricate scheduling constraints) may take a few rounds of testing and refinement. Describe the rules precisely, with examples, and verify with real cases in the preview.

## Your escape hatches

The edges above are softer than they sound, because nothing about Vaulter locks you in:

- **The code is yours and it is standard.** Edit any file in the [code editor](/docs/your-app/code-editor).
- **Export or sync to GitHub** on Pro, so the project lives in your own repository too.
- **The Custom API connector** reaches any HTTP service that is not in the [connector catalog](/docs/integrations/catalog).
- **Connect your own Supabase project** to [read data you already have](/docs/data/connecting-supabase).

If you are unsure whether your idea fits, the quickest test is the honest one: describe it in a new project and see how far the first build gets. It costs a few minutes, and the first 80 percent is usually the answer.