You build the interface and the workflow — the part that makes your app yours. Piezas runs, secures, and supports everything underneath: your data, integrations, access controls, and jobs. 15 managed service APIs plus an admin control plane your AI coding agent already knows how to use.

Teams often use a small slice of a large product, then work around the rest. The software becomes the process instead of supporting it.
Per-seat tools can make internal workflows expensive to share broadly, especially when every small app needs another vendor and another contract.
Their pipeline stages. Their dashboard layouts. Their notification rules. Your team adapts to the product instead of shaping software around the work.
AI can now build an entire application from a text description. But who maintains it? Who's on call when the database query goes slow? Who reviews the data model? Who patches the security bug? Who proves which user accessed which customer record?
Generated code is easy to create. Operational ownership is not.
Piezas focuses on the reusable backend layer: data records, permissions-aware service APIs, integrations, notifications, documents, scheduling, workflow primitives, access logs, and cloud-managed provider credentials.
For a prototype, that's fine. For running your business, it's a liability.
Run the Piezas CLI in your app repo. It installs the SDK and writes instructions for Cursor, Claude Code, Codex, and Windsurf.
Tell your AI coding agent what to build. The generated instruction files point it to 15 service APIs, SDK usage, recipes, and live OpenAPI specs.
Your agent builds the interface, workflow, and product-specific logic while using Piezas APIs for backend records, tasks, calendars, forms, documents, jobs, and integrations.
Your app owns the UI and workflow. Piezas owns tenant-scoped records, app integration policy, tokens, access logs, jobs, documents, and provider actions.
Store any business data with custom fields and relationships
Track anything through configurable stages
Manage work with due dates and priorities
Send emails, alerts, and transactional messages
Availability, bookings, overlap checks, holidays, and sync
Sequences, reminders, and Gmail-backed sending flows
Rules, durable jobs, retries, and sync queues
Data collection forms with website embed
Files, versions, extraction jobs, signature state
Dashboards, charts, KPIs
Catalogs, quotes, invoices, reconciliation patterns
Threaded conversations on any record
Per-tenant branding, sender settings, and app configuration
Document ingestion, semantic search, and AI Q&A
OAuth, scoped grants, connector actions, and token refresh
Same backend primitives. A CRM, a booking site, a client services workspace, or a lightweight finance workflow should differ mostly in UI, business rules, and setup scripts, not in custom databases.
Tenant users, invite-only signup, mandatory MFA, team access, app registry, shared API keys, provider keys, access logs, and audit events.
Piezas does not make certification claims. It gives teams the backend shape compliance reviews usually ask for: isolation, access logs, managed secrets, app-scoped integration policy, service boundaries, and fewer places for generated code to leak sensitive data.
Tenant-scoped records, tenant app policy, service tokens, jobs, and public sessions keep generated apps away from raw backend state.
Generated frontends call documented service APIs through a gateway-owned API surface. Dedicated deployments can keep service-to-service traffic behind private network boundaries.
API keys, OAuth tokens, provider keys, refresh state, and scoped grants stay encrypted server-side and are exposed through Piezas actions.
Admin and service foundations include durable access logs, usage logs, audit events, public-session records, and integration grant state.
Tenant users, invite-only signup, team roles, shared API keys, and mandatory TOTP MFA are managed from the control plane.
Apps can stay focused on views, workflows, and product-specific logic instead of duplicating migrations, OAuth clients, retries, and schedulers.
Separate generated apps can have their own origins, callback URLs, provider credentials, connector purposes, and grants.
Server apps can expose approved Piezas entity, pipeline, and task tools through the SDK while keeping auth and tenant checks in the app.
CRM records, bookings, tasks, documents, invoices, and workflow events can share one record layer, reducing avoidable ETL and warehouse cleanup.
Your users interact with your interface and workflow while Piezas stays behind the application layer.
App registry entries, allowed origins, callback URLs, public sessions, usage, provider access, and gateway routing can be reviewed centrally.
Piezas services ship with live OpenAPI specs, the SDK includes MCP-ready server support, and the CLI gives Claude, Cursor, Codex, and internal agents the project instructions they need from the first command.
Every Piezas backend service publishes an OpenAPI spec your coding agent can read before it writes direct REST calls.
Server-runtime apps can expose approved Piezas tools through `piezasMcp`, while your app keeps auth, tenant context, and route access control.
The CLI writes CLAUDE.md, AGENTS.md, Cursor rules, Windsurf rules, a manifest, recipes, and SDK setup guidance into the project.
Default setup
Use this for most projects. It installs the SDK and gives your AI coding agent the Piezas ownership rules, OpenAPI links, and backend component guidance.
Server app with MCP
Use this when a Next.js/server-runtime app should expose a protected MCP route. Static-only apps should use a server adapter instead.
Common business stack
Every extra system adds auth, sync, reporting, audit, and failure modes.
The Piezas way
CRM + client work + finance workflows + email + scheduling + documents
Built from shared backend services instead of one-off databases and integration code.
Fewer moving parts.
Generated apps can stay thin because records, provider tokens, job state, document workflows, access logs, and audit events live behind Piezas APIs.
Business software often scatters operating data across separate systems. Customer history, projects, files, invoices, form submissions, and bookings live in different places before analytics or automation can even start.
With Piezas, customer records, bookings, tasks, forms, documents, invoices, and workflow events can reference the same tenant-scoped records. You still can use a warehouse or lakehouse, but you do not need an ETL project just to reassemble your operating data.
Today
Different APIs and data models before analytics even starts.
With Piezas
One record layer behind the apps your team actually uses.
Cursor
.cursor/rules project rule
Claude Code
CLAUDE.md instructions
OpenAI Codex
AGENTS.md instructions
MCP
SDK-backed server route
Piezas owns the integration boundary.
Tenant app records, allowed origins, OAuth callback URLs, provider client config, encrypted tokens and provider keys, refresh state, scoped grants, and connector actions stay on the Piezas side. Generated apps keep references and workflow logic, not provider secrets. Each generated app can use separate provider credentials and scopes, while shared company-wide login policies can still be represented in the tenant app registry. Server apps can also expose approved Piezas tools to agents through the SDK-backed MCP route.
Get started in 30 seconds:
Start from the app console, scaffold a project from the CLI, or join the community while you build.
Or start from the command line: