RumataBuild a full-stack app
The end-to-end order of work for a persisted app with a frontend, a managed backend, a database, and optional accounts, files and AI.
Step-by-step guidance.
Before you start
- A factory. Native agents already run inside one; external clients resolve it with `list_factories`.
- Tool names are in the Tool catalog. Names below are native; the catalog gives the public MCP equivalent.
Before you build
- Ask the deployment intent: keep in development, or deploy after verification. A production-ready brief does not answer this. See Deployment.
- Explicit persistence means real backend storage, not browser-only data. For ordinary persisted CRUD, do not add login or block on a privacy question unless accounts or ownership were requested. Explicit logged-in users and save-to-account requirements already settle authenticated access. Reuse existing authentication or enable native accounts without blocking on sign-in preferences. Ask about authorization only when the intended users or data sensitivity leave a real product decision unresolved.
- For a generic gallery, clarify whether it should show sample images, an existing API, or real persistent uploads. Receive that answer before implementing the data path.
- For a frontend-only request, ask whether to use sample data or an existing API before adding a backend.
- Call `getFactoryBuilderContext` and `listBackendServices`. Reuse what exists; discover connectors, secrets, queries and workflows before creating new ones.
Choose the architecture
| The app needs | Use | Guide |
|---|---|---|
| API, CRUD, authorization | A managed backend from the `node-api` starter | Backends |
| Records and relationships | The factory PostgreSQL database | Database |
| Uploaded or generated files | Managed storage with signed addresses | File storage |
| Sign-up and sign-in | Native accounts, or a custom method when the product needs one | Accounts |
| AI behavior | A workflow with a native agent step | AI steps |
| Cron, ETL, heavy pipelines, delegated jobs | A workflow | Workflows |
| A visible interface | A registered frontend, separate from the backend | Frontend |
Explicit user requirements win. Preserve an existing stack or a requested architecture, including a combined server-rendered app or Git-backed content.
Build order
- Scaffold the backend: read `.rumata/PLAYBOOK.md` for the starter path, run `node <cli-path> verify node-api`, then create `node-api` in the sibling backend folder. Read its README.
- Register the starter’s generated Dockerfile configuration with `configureBackendService`, with `database:true` in both environments when the app needs PostgreSQL, then start it with `runBackendServiceAction` action `ensureDevelopment`.
- Create only the tables the first route needs. Use `executeSql` or idempotent migrations.
- Build one critical route and prove it with `debugBackendRequest`. Do not build the whole API first.
- Call `enableFrontend` before writing UI files, and work in the directory it returns.
- Copy `getBackendService.frontendBinding` into `rumata.backends.json` and call the API from a typed client. See Frontend.
- Build the smallest UI for that route, then complete create, list, update and delete.
- For a logged-in AI app, first prove native login, authenticated generation, persisted output and reopening the saved project. Use the starter workflow client and account module; add dashboard styling only after that full path works. Keep the workflow private and use owner billing for application users.
- Verify. See Verification protocol.
- If the user chose deployment, show the concrete release, get approval, then publish. See Deployment.