App Builder: describe an app, Sovariq builds it on your backend

A frontend is a normal React + Vite project (TypeScript, Tailwind CSS v4, shadcn/ui-compatible components, react-router, @sovaria/sdk) kept with your project. Every save is a version you can restore, and Export downloads it to run anywhere with npm install && npm run dev. It can use any npm package you add to package.json whose licence is permissive (MIT, ISC, Apache-2.0, BSD…).

1. 1

   Create one

   Apps › New app, or ask on the Sovariq page, where the app opens beside the chat as it is built (Tutorial: build your first app with Sovariq): describe the app and Sovariq plans it (with a credit estimate), builds the backend first, then the pages while you watch; start from a template (see Frontend templates); or start from a blank React app.

2. 2

   Talk the idea through first

   Not sure yet what the app needs? Ask in Ideate ("I want an app for my business"): Sovariq asks a few sharp questions with options — who uses it, which roles, how people get accounts, the first modules, the look — then turns the answers into a plan card you approve or edit. For a whole app it works out the field itself, whatever it is, from your words: every role and what each does, how accounts are made and why (people sign up themselves for an open product; an organisation that keeps records about people creates or invites the accounts, with no public sign-up page), the modules, the pages each role needs, which data belongs in tables and which in document collections, the detail page every main record opens, and the photos and illustrations each page needs. Sovaria keeps no notes about particular fields, so a brand-new idea gets the same depth as a familiar one. Before the plan card appears, Sovariq checks it against your message: everything you named — each feature, page, role and piece of data — must be somewhere in the plan, or it plans again. Your own words always win: say "customers sign up themselves" and they will.

3. 3

   Plan first, then build in checkpoints

   For a whole app Sovariq first shows a plan card: a short brief (who it is for, the roles and what each does, how accounts are made, the modules, the key flows and the look), the open choices with the option it will use unless you pick another, pages and who can see them, tables with their access rules, sign-in, integrations, three design directions to pick from (type, colours, layout, motion level) and a credit estimate. Edit it as text, Ask for changes, or Approve & build. The approved plan is kept in the app as PLAN.md (and its design direction in DESIGN.md). The build runs in checkpoints (backend, pages, polish) with a card after each; tick Pause after each checkpoint to review and steer before it goes on, or Build without asking (also in the composer menu) to let it run to the end. The approved plan becomes a fixed task list (TASKS.md): the Tasks tab shows each task with what proves it done, tasks a reviewer added after a checkpoint say why, and only one task is in progress at a time. If a run stops with tasks open (a limit, an error, a closed tab, or Sovariq credits running out), Continue in the chat or the Tasks tab picks it up from the list; a build that stopped on its own carries on by itself and says *Sovariq is still building*. At the end a report card lists what was built, the test results and the next steps, with Deploy.

4. 4

   Show it a screenshot

   Paste, drop or attach up to four images (PNG, JPEG or WebP) with a message — “this button is tiny on my phone, fix this”. They are shrunk in your browser before sending, shown small in the chat (click to enlarge) and kept with the conversation. Models that can’t see images tell you so instead of guessing. After a build, quick actions offer Fix this…, Polish, Add a page…, Make mobile perfect, Add sign-in, Add payments and Safety check.

5. 5

   Connect data with dropdowns

   Connect data: pick a table, the columns, filters (a value, the signed-in user, or a URL parameter), the order and how many rows, and the page. The builder writes readable code (<DataList table="orders" …/>) you can change.

6. 6

   Describe it, watch it being built

   Apps asks *What do you want to build?* Describe the app and the studio opens with Sovariq on the left and your app on the right. Every step shows in the chat: what Sovariq is thinking, which file it changed with +added −removed counts, and the exact lines (folded groups total them). Changes that need your OK show a review card with Accept and Reject. The preview keeps showing your last working version with a small Building… pill, and swaps in the new one when the run ends, without a flash and keeping your scroll position.

7. 7

   Lay out the studio

   The studio has three panes, like a desktop app: Chat (Sovariq), the Workspace (tabs for Preview, Code, Plan, Tasks, Tests and Data) and the Inspector (the design, data and layer panels for what you select). Drag the line between two panes to resize them (double-click resets, arrow keys work when it has focus); every pane folds to a thin rail, and the chat can float as a small window over the preview. Layouts: Chat + Preview, Code + Preview, Preview only and Review (tasks and tests beside the app). Tasks ticks off Sovariq's steps while it builds, with a progress line at the top ("Backend 4/5 · Pages 2/7"). Shortcuts (Ctrl on Windows and Linux): ⌘B chat, ⌘⌥B inspector, ⌘⇧B float the chat, ⌘J next tab, ⌘\ swap sides, ⌘. compact mode, ⌘⇧↩ full-screen preview (Esc returns), ⌘K commands, ⌘↩ send, and ? lists them all. Sizes are remembered per app in your browser.

8. 8

   Arrange

   Layers lists the page's sections: drag to reorder, or move, duplicate and delete them — the code is rewritten to match, and Undo is one click.

9. 9

   Point and change

   Edit text (T) changes copy right in the preview, free and instantly. Select (S) any element: describe the change and Sovariq makes it; on a Sovaria data block the inspector connects it with dropdowns (source, columns, filters, sort, live updates, actions, who can see it) and checks your access rules live. Add brings in components from shadcn/ui, Magic UI, Kibo UI or your library; Data drags a table, bucket, function or agent onto the page.

10. 10

    Design like in Figma

    Select anything and a toolbar floats above it: drag the grip to move it anywhere on the page (a line shows where it lands; hold Alt, or use the arrow keys, to nudge it freely), move up or down, duplicate, delete (Del), and for text: smaller, bigger, bold, italic, alignment. Eight handles resize it like a window. The panel on the right holds the rest — size, layout, spacing, text, colour (one swatch with your recent colours and the full palette behind it), border and shadow — and Animate: entrances (fade, fade up, slide, zoom, blur, spin) on load or as it scrolls into view, hover effects, loops, and text effects such as typewriter or rotating words that Sovariq adds. Changes show in the preview at once and collect as unsaved edits: Save (Ctrl+S) writes them all as one version, Discard drops them, Undo steps back. While Sovariq is building, editing is locked and the preview renders once when it finishes.

11. 11

    The default look

    Ask for an app without saying how it should look and it comes out clean black and white, Apple-like, with the device's own font (nothing to download), a light and a pure black dark mode and a switch between them. Name a mood, brand or colours and Sovariq applies one of its design presets instead.

12. 12

    Preview

    The preview runs on a separate preview domain, against your project's API (or the environment you pick) with its public anon key, and updates as you or Sovariq change files. The studio adds the app's preview address and its published address to your project's Allowed origins for you (Project Settings › Allowed origins lists them), and the preview can call any HTTPS API and load Google Fonts, like the published site. Open in a tab shows it full size. If the preview can't run in your browser, the studio shows your published site instead, labelled Live. Published apps are served gzipped (a compressed copy of every large file ships with each deploy).

13. 13

    Finished, not generic

    Before Sovariq calls an app done it runs a free finish check on the files: a design preset applied, real pages and a 404, a phone menu, no placeholder or starter text, theme colours instead of raw ones, image alt text, a title, description and favicon, a sign-in page for private pages, and every page the plan promised. It fixes what the check names.

14. 14

    Problems

    When the running app logs something wrong (a console error, a crash, a failed request with its status and error code such as 403 ORIGIN_NOT_ALLOWED or 42P01, a blocked connection, or a build error), a red N errors button appears in the preview bar. It lists them, de-duplicated with counts, and Ask Sovariq to fix hands them over. Sovariq reads the same list itself (fe_preview_logs) after every build and whenever you say something doesn't work, straight from your browser: nothing is sent to a server, and tokens and keys are removed from the lines.

15. 15

    Fixes its own errors

    When a build changed your app, Sovariq checks it before it stops: if the last build failed, the preview logged an error, or files changed since the last check, it starts an Auto-fix round by itself (build, read the errors, fix the first at its source, build again). At most two rounds per message by default, each within a small cost cap, never while it is waiting for your answer, and only fixes: no new features. A card in the chat shows each round and how it ended (How Sovariq keeps builds fast and cheap).

16. 16

    Tested like a person would

    Before Sovariq calls an app done it uses it in your preview, with a cursor and a step log you can watch: every page loads with no console errors and fits a phone, forms save good input and refuse bad input, rows are created, shown, edited and deleted, a test user signs up, in and out, and another user can't see or change the first user's rows. Security probes run too: a script typed into a field must show as text, no service key may be in the app's code, visitors can't add rows, private pages send visitors to sign in, and uploads follow the bucket's rules. The Tests tab shows pass or fail per check with a picture of each failure, Run tests runs them again, and Fix with Sovariq fixes one. Anything that signs up users or writes rows runs only when the app's backend is a branch environment, never production; test users are made on the branch (sv-test-…@example.com). Failed tests hold Publish until they pass or you choose Publish anyway.

17. 17

    Full test

    Pick Full test in the Tests tab (Sovariq runs it as fe_test_drive with mode: "full") for a deeper pass on a branch environment: the checks, then every page in the app's routes file and the pages its links lead to, as a visitor, test user A and test user B. Every form is filled with realistic values its fields and table rules accept (choices from CHECK rules, lengths, ranges, dates), every button is clicked, and after each action the test records the requests and their answers, console errors, and whether what was saved can be found again. Then user B and a visitor try to read and change user A's rows. Buttons that delete, pay, send or sign out are skipped unless they act on the test's own rows. Results are counts plus each failing (✗) or suspicious (?) item with its evidence; Sovariq fixes the failures and checks the suspicious ones against your plan. Test users are made on the branch with a password only your browser knows (project secret SOVARIA_TEST_USER_PASSWORD); Sovariq can type them in its own steps as {{test_user.email}} and {{test_user.password}} without seeing the password. On production the full test only opens pages and follows links.

18. 18

    Check

    The safety check (Data › Safety, and before every publish) scans for secrets (your service key must never reach a browser) and every npm package (a permissive licence, no known vulnerability or malware at that version on OSV.dev, no look-alike of a popular name, an exact version, a note for deprecated ones), then tries every table, bucket, function and document collection your pages use as a visitor, as a signed-in user and as another user: visitors who can write, or users who can read or change someone else's rows, fail it. It reads each table's real row policies, so user_id = auth.uid() on USING and WITH CHECK counts as owner-only and auth.has_role('admin') as admins only. Collections are found from useDocuments, collection() and doc() in your pages (users/${id}/notes counts as each user's own); each one is asked doc:read, doc:write and doc:delete through your access rules, then the documents table's row policies for that collection (an owner_id = auth.uid() policy keeps each user to their own documents). Visitors who can write or delete documents fail the check; so do signed-in users who can change, or anyone who can read, documents that belong to users. An app that was already live before collections were checked sees these as warnings that say they will block, for a grace period; fix them now. Your project's security advisor runs too. Each problem comes with a fix: the exact change (owner-only rows, or SQL with its undo), and Fix with Sovariq applies it in a branch.

19. 19

    Meant to be public

    A catalog everyone may browse or reviews everyone may read are public on purpose. When a table's rows belong to users but a policy lets everyone read them, the check asks; click It's meant to be public, say why, and it stops blocking (your name, the time and the reason are kept, shown in Safety and audited; Take back undoes it). Sovariq can do the same only after you say yes. It works only for reading tables with nothing personal in them (no email, phone, address, token…): public writes and other users' private rows always need a fix. If the table's read rules or columns change, the check asks again. A table with no owner and an explicit public read policy is simply noted as a public catalog. The same goes for a top-level document collection a page shows per user (public posts, say): it can be marked intended unless its name says it's personal (messages, orders…); a per-user subcollection (users/{id}/notes) never can, and a new access rule or row policy for it makes the check ask again.

With Sovariq in Build mode, its page edits are saved as versions without a confirmation each time (undo is one click in History); it builds the app in your browser, fixes errors (at most three tries) and runs the checks. Changes to your database and rules still ask first.

Shell commands (fe_shell)

For changes across many files — rename a brand everywhere, move pages into a folder, count or find usages — Sovariq runs a shell command on a throwaway copy of the app instead of rewriting files: sed, grep, awk, find, mv, cp, rm, mkdir, sort, uniq, wc, diff, head, tail, cut, tr, cat, echo, printf, plus rg and jq. The step in the chat shows the command ($ sed -i …) and the files it changed with their lines.

• Whatever one command changes is saved as one version with the command as its message (undo it from History). Commands that only read (grep, ls, wc) save nothing.
• All or nothing: a command that fails (non-zero exit), times out or hits a limit saves nothing, and so does one that would touch a hidden file (.env), node_modules, a licence or lock file, a binary or a file over 256 KB, a symlink, a secret (API key, token, private key), or package.json's dependencies (those change with a normal edit, where the dependency checks run).
• It runs in the same sandbox as Edge Functions: no network, no access to anything but the copy, an empty environment, its own user, and caps on time (10 s by default, 20 s at most), memory (256 MB), output (16 KB of each stream kept) and processes. Package managers, Node, Python, git and network tools aren't available; builds stay in the builder.
• Each project runs at most 20 commands a minute, and a plan's daily number (below). Every command is recorded: the app's shell history is in the audit log (frontends.shell) and at GET /api/v1/fn/hosting/frontends/<id>/shell/runs.

Over the API (permission to deploy functions): POST /api/v1/fn/hosting/frontends/<id>/shell with {"command": "sed -i 's/Acme/Brewly/g' src/brand.ts", "cwd": "", "timeout_s": 10} answers exit_code, stdout, stderr, changed (path, added/modified/removed, short diff), refused (path and why), and commit and version when something was saved.

A command's answer to Sovariq carries at most 2,000 characters of output (the first and last lines, error lines and counts); the full output is kept for 7 days and read in ranges with fe_output, or at GET /api/v1/fn/hosting/frontends/<id>/outputs/<run_id>?lines=1-200.

Scripts and checks (fe_run, fe_check)

For work that repeats — a page, route and nav entry for every entity of the plan, fixtures, translation keys, a rename with its imports — Sovariq writes one short Node script and runs it once on a throwaway copy of the app, instead of one step per file. Then it checks the app with the same commands a developer runs (tsc and the app check, optionally vite build) in the sandbox.

• fe_run: one script (an ES module, at most 400 lines) sees the app as its folder and three read-only files: the app's plan (spec.json), the kit's manifest and the design look. It writes only under src/, public/ and docs/; everything it changes is one version (undo it from History). Its answer is a report — files added, changed and removed, line counts, the first error with its line — never the files themselves.
• All or nothing: a script that throws, times out, or writes anywhere else (package.json, config, lock files, hidden files, a secret) saves nothing. Scripts can't install packages, reach the network, read your data or call Sovaria: migrations, access rules, users, deploys and dependencies stay with their own steps and approvals.
• fe_check: tsc --noEmit and scripts/check-app.mjs (what npm run check runs), plus vite build when asked, against a pinned toolchain (TypeScript, Vite and the kit's exact packages, checked against its manifest before each use; nothing is installed). It answers pass or fail and at most 30 errors as file:line:col CODE message, and saves nothing.
• The sandbox is the shell's, with Node locked down further: no child processes, workers, eval, WebAssembly or network, reads limited to the copy. Text in your files or in output that looks like instructions is treated as data; after it, Sovariq asks before writing again.
• Limits: scripts run up to 30 s (Control Center, at most 120 s) with 512 MB; checks up to 120 s. Each project runs at most 10 scripts and checks a minute and a plan's daily number (below); Sovariq runs a few per message. Runs are in the audit log (frontends.run, frontends.check) and at GET /api/v1/fn/hosting/frontends/<id>/runs.

Over the API (permission to deploy functions): POST /api/v1/fn/hosting/frontends/<id>/run with {"script": "for (const p of sv.spec.pages) sv.write(src/app/${p.id}/page.tsx, …)", "message": "pages from the plan"}, and POST /api/v1/fn/hosting/frontends/<id>/check with {"build": false}.

Sovariq sets up each group of tables as one migration: the tables, their indexes, row-level security with its policies (each user sees only their own rows, admins read all) and the access rule that lets signed-in users reach them. You approve it once, on a card that shows the whole SQL, instead of one approval per table and rule. It checks the result by reading the policies back and runs the security scan once at the end, not after every change.

#Deploy

1. 1

   Pick your address

   Deploys: type a name and your app goes live at https://<name>.sovarias.in. If the name is taken, you get the same name with a few extra characters instead.

2. 2

   Deploy

   Deploy to production builds the app in your browser (packages bundled in, Tailwind compiled, assets hashed and cached) and releases it in one step: visitors see the old version or the new one, never a mix. Deploy a preview gives a separate address for 30 days. While it runs, Publish shows a deployment log: Prepare, Safety check, Build, Upload and Release, each with its time and output, and a failure is marked at the stage where it happened.

3. 3

   Roll back

   History lists every deploy (an upload that stopped half-way shows Didn't finish and is cleared after a day); Make live puts any earlier one back, and Roll back returns to the previous release. Roll back to last safe version (Publish, or Data › Safety) restores the newest version that passed the safety check and was published: its files and its live deploy, in one step.

4. 4

   Safe by default

   Publishing to production runs the safety check first. If it fails, nothing goes live: you see the problems, ask Sovariq to fix them, or tick “I understand the risk” and Publish anyway (recorded). Sovariq keeps its database and rule changes in a branch environment until the check passes there, and it never rolls back or publishes without asking you.

Sovariq can deploy too (fe_deploy): previews right away, production only after you confirm. The deployed app talks to the environment and API version set in Backend.

Every publish first makes the app search-ready and branded, free and without AI: a favicon from your logo (or a mark from the name and brand colour), the icons phones and browsers ask for (favicon.ico, apple-touch-icon, 192 and 512 px), a 1200×630 link-preview picture, a web app manifest with your theme colour, a title, description, canonical address and social tags for every page, structured data (JSON-LD) for the kind of site it is, robots.txt (private and sign-in pages stay out of search) and a sitemap. Public pages are prerendered, so search engines and link previews see the real content. Every build also checks one h1 per page, image alt text and broken internal links, and warns when the JavaScript grows past 1500 KB. Settings › Brand shows the logo, favicon, phone icon and link preview: replace any of them, or use your home page's hero as the link preview. While building, Sovariq looks at the preview (a screenshot it shows you small in the chat) to check its work, and you can keep typing: messages wait and go in order.

#Your own domain and HTTPS

Every address is HTTPS only: https://<name>.sovarias.in and preview addresses (<name>--<preview>.sovarias.in) are covered by Sovaria's certificate, plain HTTP redirects to HTTPS, and every page is sent with HSTS.

1. 1

   Connect

   Settings › Domains: type your domain (for example www.example.com) and Connect domain.

2. 2

   Add two DNS records

   A TXT record _sovaria-verify.<your domain> with the value shown (proves the domain is yours) and a CNAME from your domain to custom.sovaria.in (sends visitors to Sovaria). For a bare domain like example.com, use your DNS provider's ALIAS or CNAME flattening, or connect www instead.

3. 3

   Check DNS

   Once the TXT record is visible the domain shows Verified. A Let's Encrypt certificate is then issued automatically, usually within a few minutes, and the domain shows Secure with its expiry. It renews by itself about a month before it expires.

#Visitors and page views

A published app counts the visitors and page views of its live pages (HTML pages from the live address; assets, previews, bots, uptime monitors and prefetches don't count). The app's card on the Apps page shows the last 7 days; Sovaria Workspace shows them per day; Sovariq answers "how many visitors did my site get this week?" (site_visitors). Counts are approximate (about 1 %). No address or browser is stored: a visitor is a hash of a random daily salt with them, so nobody can be followed from one day to the next.

GET /api/v1/fn/hosting/sites/<name>/visitors?days=7     # 1–30 days, today included

{ "site": "<name>", "days": 7, "visitors": 1240, "page_views": 3810,
  "by_day": [{ "date": "2026-11-01", "visitors": 160, "page_views": 480 }, …],
  "approximate": true, "available": true, "counting": true }

• available: false: the counter couldn't be read right now. That isn't zero visitors; the card says Visitors unavailable.
• counting: false: Sovaria staff turned visitor counting off (Control Center › Hosting, audited with a reason); nothing is recorded while it's off.
• Who: members who can read functions. Another project's site answers 404.

#Take an app offline or delete it

Both are in the app's ⋯ menu on the Apps page and in Settings › Danger zone, and both ask first. Neither touches your tables, data, storage or functions: those belong to the project, not the app.

Sovariq can do either when you ask (fe_unpublish, fe_delete_app); both show an approval card first, and Delete needs the app's name as you confirmed it. Over the API: POST /api/v1/fn/hosting/frontends/<id>/unpublish and DELETE /api/v1/fn/hosting/frontends/<id>?confirm=<name> (permission to deploy functions).