1.0
One database, by default.
Most engineering teams run a stack of disconnected tools. Each tool has its own auth, its own data model, its own export format, and its own webhook to glue it to the others. The webhooks fail silently at 2am. Reporting across tools means a SQL job that no one trusts.
We picked the opposite default: one Postgres database with one account_id column on every table. A CAPA can reference the bug that triggered it because they're rows in the same database, joined by a foreign key. A timesheet entry references the project it was logged against because the project is two tables over. Cross-module reporting is a JOIN.
This costs us something. A developer joining the team has to read more of the schema before they can ship a feature in any one module. The tradeoff is a product that doesn't lose information at module boundaries — because there are no module boundaries.
2.0
Regulated-grade is the baseline, not the upgrade.
The standard SaaS playbook is to ship the consumer feature set on Free, and gate the audit-trail, the change-control workflow, and the electronic signature flow behind Enterprise. The actual buyers who need audit trails are then quoted six figures.
We put the audit log, the change-control workflow, and the e-signature primitives in the one plan every team gets — never behind an Enterprise gate. CAPA, NCR, and the traceability matrix ship to every team: the full platform is free during open beta, and read-only viewer seats remain free at GA. The argument is simple: a team of five medtech engineers shouldn't be priced out of the regulated-industry features they need on day one.
We're aware that this means we leave money on the table from the kind of enterprise procurement process that expects to be sold to. We're betting on the other kind of customer.
3.0
Postgres under the hood.
The database is psql-readable. No proprietary store. No closed query engine. If you want to ask a question the UI doesn't answer, you can SSH to the box and write the query yourself.
The schema is published. The migrations are in Webbased/drizzle/*.sql in the repo. There are no obfuscated column names, no encrypted-but-undocumented blobs for "business logic," no opaque JSON columns that hide what's actually being stored. If something is encrypted at the column level (TOTP secrets today), the envelope format is documented: enc:v1:<iv-hex>:<tag-hex>:<ct-hex>.
Why this matters: The day Azora stops being useful to you, your data is still in Postgres. You can pg_dump it and walk away. No data is held hostage. No "premium" tier unlocks export.
4.0
Self-host is a first-class citizen.
The same application codebase runs on your VPS as on ours. There is no separate "Enterprise edition" with a different module set. Self-host customers receive the deployment materials, schema migrations, and environment template needed to inspect and operate the contracted release.
Self-hosting is offered through an enterprise services agreement because it carries a separate deployment and support obligation, not because the software is different. We expect a fraction of customers to choose self-host — but we want that to be a real choice, not a different product edition with gated modules.
5.0
No per-module pricing.
Every solution is included in Azora's single plan. A team that starts with quality can use timesheets the next day without a quote. A team that starts with project management can open a CAPA against a bug the day it discovers the need.
This costs us a defensible-feeling monetization lever — most competitors slice out one module per tier and ladder buyers up. We picked the flat model on the theory that the whole point of the platform is that the modules talk to each other; charging extra to use the next one is just charging extra to use the product.
6.0
The marketing site doesn't lie.
Every product claim on this site should have a corresponding implementation we can demonstrate. The architecture and security brief publishes the concrete controls behind the trust language, while the public changelog separates shipped work from roadmap items.
When a claim doesn't yet match the code, we either soften the claim or commit to building the code. We don't leave the gap open and hope no one runs the eval. This is unusual enough in B2B SaaS marketing that we're publishing it as a principle, not a tactic.
You should expect: A capability we describe should be demonstrable in the live demo within five minutes. If it isn't, that's a bug — tell us and we'll either fix the product or fix the page.
7.0
No meters that bite.
The pricing page lists editor counts, storage, and records — not AI credits, API calls, automation runs, or any of the other meters that quietly accumulate into a surprise invoice. Those visible measures change slowly under the one product plan; enterprise implementation and support services are quoted separately.
We picked this because we hate getting bitten by meters ourselves. The competitors who price by AI credits are usually trying to recover the API costs of their model provider, plus a margin. We don't gate features behind a meter to do the same thing.
8.0
Real screenshots, not mockups.
Every screenshot on the marketing site comes from a real Azora demo tenant running the same code as production. The hero image is captured by a Playwright script that logs into azorasolutions.com in a real browser, navigates to /dashboard/tasks, and saves the page as a PNG. If you see a panel on the marketing site, you can log into the demo tenant and load the same panel.
This is more work than rendering a Figma mockup. The payoff is that the marketing site doesn't ship a fiction the live demo can't deliver — and a buyer evaluating us can compare the screenshot against the product in their own browser tab.