SpalaStart here
Bring an app idea, prototype, or frontend. Build one representative backend flow, inspect every resource, test the real API, and publish only what you reviewed.
The agent installs the public MCP, asks you to sign in only when needed, then creates or reuses the project and connects its project-scoped MCP automatically.
npx --yes @spala-ai/mcp-install@latest init --client codex --yes --json
pnpm dlx @spala-ai/mcp-install@latest init --client <other-client> --yes --json
Use the command for the current client and follow its JSON restart or resume steps exactly.
After restart or resume, the agent calls protected spala_start once. OAuth and any optional payment stay in the browser; terminal prompts collect missing account, company, and project details.
It creates the first organization when none exists, presents multiple choices, reuses a valid local binding or selects/creates a project, then connects, binds, and verifies its workspace-only project MCP.
A useful first build starts with who can do what, which records they touch, and what must never be exposed. You can refine the schema after the contract is clear.
List each user type and the actions each role may perform. Include the owner or tenant boundary.
Name the records the workflow creates, reads, updates, or deletes and how they relate.
Write one valid request, one invalid request, and one action that a different user must be denied.
This sequence keeps the AI useful without asking you to trust generated backend behavior blindly.
In agent mode, let Public MCP reuse or create the intended project. For manual evaluation, use the hosted dashboard and choose a low-risk project or staging workflow.
Tell Copilot the users, records, permissions, validation, and expected result. Avoid asking for the whole application in one prompt.
Review PostgreSQL tables, relationships, auth rules, REST routes, workflow steps, validation, and draft state in the project graph and focused tools.
Use API Playground for success, invalid data, missing auth, wrong-user access, CORS, and representative failure behavior.
Open publish review, select the intended changes, and confirm the published API behaves like the tested draft.
Use the exact API base URL, OpenAPI or SDK output, auth routes, token behavior, CORS origin, errors, and current publish state.
Public discovery and project work are different surfaces. This distinction prevents an agent from guessing a project endpoint or assuming anonymous write access.
Install the public endpoint through @spala-ai/mcp-install for discovery, protected startup, terminal-guided organization/project selection, and authenticated project handoff.
Reuse a valid local binding or present/select/create the intended project, then call project_connect once. project_select is only a compatibility alias; do not call both.
Execute only the exact workspace-local install plan returned by project_connect for inspection, changes, validation, publishing, and review.
Do not construct or guess project MCP URLs or expose the one-time bootstrap URL.
If any answer is unclear, the workflow is not ready to become a production dependency.
The authenticated success path works with expected inputs and output.
Ownership, role, and tenant boundaries are tested with separate accounts.
Validation rejects bad inputs without partial or hidden side effects.
The actual frontend can authenticate and call the published route using the handoff contract.
Tables, routes, workflow steps, logs, and publish state are understandable in the dashboard.
Backups, rollback, support, export, and incident ownership match the cost of failure.
Build it yourself in the dashboard, or scope a managed implementation and handoff with the Spala team.