1.0
One database, by default.
Most engineering teams run a stack of eight 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 Free tier. CAPA, NCR, traceability matrix — all of QMS — ship to a team of five at $0. The argument is simple: a team of five medtech engineers shouldn't be priced out of using 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 codebase runs on your VPS as on ours. There is no "Enterprise edition" with secret modules we don't ship to the public repo. The deploy script is in git; the schema migrations are in git; the env-file template is in git. If you want to inspect what runs on your server, every line is there.
Self-host is on the Enterprise tier today only because that's where we put the support agreement, 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 marketing line that turns into a six-month "professional services engagement" when you actually ask for it.
5.0
No per-module pricing.
The eight modules — Project Management, QMS, ERP, HR, Finance, Facilities, Wiki, Support — are all in every tier. A team that signed up for "just the QMS" can use the timesheet module the next day without a quote. A team that wanted "just project management" can spin up a CAPA against a bug the day they discover they need to.
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 claim on this site has a corresponding implementation we can point to in the codebase. We publish a third-party audit of our own marketing claims alongside a deferred-work doc listing every claim we softened or qualified, with the engineering work it would take to make each one fully true.
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 on a free trial tenant 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 user counts, storage limits, and record counts — not AI credits, API calls, automation runs, or any of the other meters that quietly accumulate into a surprise invoice. The two meters that exist (users and storage) are visible from the dashboard, change slowly, and cost the same per unit at every tier.
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 trial tenant can't deliver — and a buyer evaluating us can A/B compare the screenshot against the live product in their own browser tab.