piezas
compare · piezas vs firebase

Firebase powers your app.
Piezas is your backend.

Firebase's own pitch is that it helps "you and AI agents build" apps — and it does, with excellent primitives: Firestore, auth, storage, Cloud Functions, and deep Google AI hooks. But the business logic still gets written, by you or your agent, inside those functions. Piezas starts one level up: the booking engine, invoicing, and document flows already exist as services.

the short answer
The question isn't whether your agent canbuild a reservation system on Firestore — it can. It's whether the transaction logic it improvises handles the double-booking race, the duplicate write on retry, and the reminder that silently never fires. On Firebase those are your Cloud Functions; on Piezas they're the platform's job, tested once and patched under every app.
/ side by side
Piezas
Firebase
What you get
Sixteen finished business services — bookings, invoicing, forms, documents & e-signature, pipelines, email, jobs, audit logs — behind per-service OpenAPI specs.
App-development primitives: Firestore/Realtime DB, auth, storage, Cloud Functions, hosting, analytics, crash reporting, plus Gemini AI integration.
Data model
Relational under the hood — bookings, invoices, and line items keep integrity at the database (constraints, not conventions).
NoSQL documents. Flexible, but relationships and invariants live in your client and function code — the part the agent writes.
Where business logic lives
Inside the services. Availability windows, overlap exclusion, idempotency, retries, and signed webhooks ship built-in.
In your Cloud Functions and security rules — generated, deployed, and debugged by you.
Pricing shape
Per-app hosting with flat, predictable service usage (free tier: two hosted apps).
Consumption-based (reads/writes/invocations). Powerful at scale; famously easy for a runaway loop to turn into a surprise bill.
Lock-in surface
Your app talks HTTP/OpenAPI; records export as JSON/CSV.
Firestore's document model and security-rules language are proprietary — migrating off means re-modeling your data.
Ecosystem
Focused: business backends for AI-assisted development.
Vast: mobile SDKs, analytics, A/B testing, crash reporting, push — genuinely unmatched for consumer mobile apps.
/ one concrete example

The reminder that never fires.

A booking app needs "remind the customer 24 hours before." On Firebase your agent wires Cloud Scheduler to a function, tracks what's been sent, handles the reschedule case, and dedupes retries. Each piece is small; the composition is where generated code quietly drops one — and nobody notices until a customer asks why they never got a reminder.

On Piezas, reminders are a calendar setting (reminder_offsets_minutes: [1440, 60]). Fire-once semantics, reschedule handling, and delivery via signed webhooks are the service's job.

When Firebase is the right choice

→Consumer mobile apps that want the full Google kit: analytics, Crashlytics, push, A/B testing.
→Realtime-sync experiences — chat, presence, collaborative cursors — where Firestore's model shines.
→You're deep in Google Cloud and want one bill and one console.
→Prototypes riding the free tier and intro credits.

When Piezas is the right choice

✓Business software with relational reality: bookings, invoices, cases, client records.
✓You're shipping with AI agents and want the improvised-at-2am logic layer to not exist.
✓Predictable costs matter more than metered elasticity.
✓You want audit trails and tenant isolation as platform guarantees, not security-rules homework.

Even Firebase's homepage now says the future is you and AI agents building apps. We agree — the disagreement is only about what they should build on: primitives your agent must compose correctly, or capabilities that are already correct.

Try it on one feature.
$ npx piezas init — free, two apps hosted
Start building