What is AI-native SaaS development?
AI-native SaaS development builds the AI into the product's core rather than bolting a chatbot onto the side. Onpolar ships multi-tenant SaaS on Go and PostgreSQL behind a single OpenAPI contract — assistants grounded in each tenant's own records, row-level security enforced in the database, per-seat billing and a full audit trail.
- Typical timeline
- 2–3 months to production
- Core stack
- Go · PostgreSQL · OpenAPI · React
- Tenant isolation
- Row-level security in the database
- Built this way
- ERPFlow.ai · Deal.ee
The problem
Most "AI SaaS" is a chatbot in a trench coat
A wrapper around an API key demos well and dies in the first security review. It has no idea which tenant is asking, no record of what it did, and no answer when a customer asks where their data went.
The hard half was never the model. It is tenant isolation you can prove, permissions the AI layer respects, billing that survives a plan change mid-cycle, and an audit trail an enterprise buyer will actually accept.
That work is unglamorous, and it is the reason most AI pilots never graduate from prototype. We build it first and put the AI on top of it.
What you get
What ships with a production SaaS build
Not a feature list — the foundations that decide whether year two is survivable.
Multi-tenant data model
Row-level security policies enforced in PostgreSQL, not in application code that a future endpoint can forget to call.
Auth, roles and permissions
Real role-based access resolved server-side, session handling that survives a key rotation, and an invite flow tenant admins can run themselves.
Tenant-grounded AI layer
Assistants and tool-calling agents that read only what the asking user may read, with model routing through a gateway so you are never locked to one provider.
One OpenAPI contract
A single spec generates the typed clients for web, mobile and any AI consumer, so the three cannot drift apart.
Per-seat billing
Stripe subscriptions with seat counts, proration on mid-cycle changes, and the webhook handling that keeps entitlements in step.
Audit trail and observability
Every mutation attributed to a user and a tenant, with structured logs and traces, so a support question has an answer.
Localisation that scales
UI strings, dates, currencies and right-to-left layouts handled from the start. ERPFlow ships 19 UI languages on this foundation.
CI/CD and migrations
Versioned, reviewed, reversible migrations, a repeatable release, and a rollback someone has actually rehearsed.
How it works
From spec to production in four moves
- 01Week 1
Spec before code
We write the OpenAPI contract and the tenancy model first. Disagreements about what the product does are cheap on a spec and expensive in a migration.
- 02Weeks 2–4
The boring half, first
Tenancy, auth, roles, migrations, billing and the audit trail land before any feature work. Retrofitting tenant isolation onto a shipped product is a rewrite, not a patch.
- 03Weeks 5–9
Features and the AI layer
Product surfaces built against the contract, and the AI layer wired to tenant-scoped data with model routing through a gateway.
- 04Weeks 10–12
Harden and hand over
Hot paths profiled, observability wired, runbooks written, CI green. You get the repository, the infrastructure definitions and the keys.
Proof of work
How this looks in production
Both of these are ours — built, shipped and operated in-house. Which means the tenancy model, the billing edge cases and the 3am pages are all things we own rather than things we read about.
ERPFlow — API-First Multi-Tenant SaaS ERP with EU E-Invoicing
ERPFlow is a multi-tenant SaaS ERP — invoicing, CRM, inventory, staff and finance in one platform — built API-first on a Go + PostgreSQL backend behind a single OpenAPI contract, with native Peppol e-invoicing and per-seat Stripe billing.
Deal.ee — AI-Indexed Business Intelligence and Marketplace for Estonia
Deal.ee turns Estonia's public business data into a fast, AI-citable intelligence layer — ~368,000 companies across 19 government datasets, refreshed daily in Estonian, Russian and English — and adds a verified-company marketplace where businesses claim their profile by national eID, with an offers layer — products, services, real estate, jobs and investments — rolling out on top. Built in Go on PostgreSQL, engineered to be cited by ChatGPT, Claude, Perplexity and Gemini.
Have a SaaS product to ship?
Bring the problem and whatever exists today — a spec, a prototype, a spreadsheet everyone has outgrown. Thirty minutes is usually enough to tell you what it takes.
The bar
What "production-ready" has to mean for multi-tenant SaaS
The features a buyer asks about in a demo are rarely the ones that block the deal. These are.
| Concern | The prototype answer | What we ship |
|---|---|---|
| Tenant isolation | A tenant_id column and a WHERE clause | Row-level security policies in PostgreSQL, enforced beneath the application |
| Permissions | Role checks in the interface | Roles resolved server-side; the AI layer reads only what the asking user may read |
| Billing | One price, one plan | Per-seat Stripe subscriptions with proration and webhook-driven entitlements |
| Audit trail | Application logs | Every mutation attributed to a user and a tenant, queryable and retained |
| API surface | Endpoints added as needed | One OpenAPI contract generating typed clients for web, mobile and AI consumers |
| Migrations | Edits run against production | Versioned, reviewed, reversible, applied by CI |
| EU compliance | Deferred to later | Peppol BIS 3.0 e-invoicing where invoicing is in scope |
Every row in the right-hand column ships in ERPFlow.ai — the multi-tenant ERP we built and operate ourselves.
FAQ
Questions we get asked
How long does a multi-tenant SaaS build take?
Two to three months to a production release for a focused product. ERPFlow — invoicing, CRM, inventory, finance, HR and reporting, with Peppol e-invoicing and per-seat Stripe billing — took two months. What moves that number is integration count and compliance scope, not feature count.
What does AI-native actually mean here?
The AI reads your tenants' real records under the same permissions as the user asking, and can call tools that change state. It is not a chat box over a public documentation index. Model routing goes through a gateway, so changing provider is a configuration change rather than a rewrite.
Why Go and PostgreSQL rather than a JavaScript backend?
Predictable latency, real concurrency and a small deployment surface, against a database whose row-level security can enforce tenant isolation below the application layer. TypeScript still runs the frontend, and Next.js goes in where server-side rendering earns its place.
Do we own the code?
Yes. The repository, the infrastructure definitions and the credentials are yours from the first commit, in your accounts. No proprietary runtime, and no licence you have to keep paying us for.
Can you take over an existing SaaS codebase?
Often, yes. We start with an architecture review and a written assessment of the tenancy model, the auth layer and the migration history before proposing any work. If the honest answer is that a rebuild costs less than a rescue, we say so.
What if we already have engineers?
Then we take the parts they have no bandwidth for and build against the same contract. Spec-driven development exists precisely so two teams can work from one OpenAPI document without blocking each other.
How do you price a build like this?
Fixed-scope phases against the spec, rather than hourly against an open backlog. The spec is what makes that possible: when the contract is agreed up front, the estimate means something.
What happens after launch?
A handover with runbooks and a rehearsed rollback, then whatever support shape suits you — retained hours, a fixed monthly block, or nothing at all. We build products we would be comfortable walking away from.
Start a SaaS build
Tell us what you are building and where it is stuck. We reply within one business day.