Known limitations

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.
• Built-in user accounts with email and social sign-in (add sign-in).
• A global edge network serving the published app over SSL at your subdomain or custom 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.

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. 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.
• 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.
• 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.
• Connect your own Supabase project to read data you already have.

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.