AI SaaS development, from empty repository to paying customers

What "AI-native" actually means here

It is a phrase that has been worn smooth by overuse, so here is the concrete version. An AI-native product is one where the model is load-bearing in the core loop — it drafts the clinical note, it summarises the news wire, it grades the answer — rather than a chat bubble bolted onto a CRUD app after launch.

That distinction changes the architecture. You need somewhere to put prompts that is not source control. You need to store the model output alongside the input that produced it, because you will be asked to explain a result six months later. You need a fallback path for when the provider is slow or down, because it will be. And you need a cost model per tenant, because inference is the first line item that surprises people.

We have also learned when to take AI out. Building an automated newspaper layout engine, we shipped an AI copy-fitting pass that shortened text to fit its column. Testing showed it inventing an official assurance nobody had given — and the numeric guard we had written passed it, because the invented sentence contained no numbers. We cut the feature back to trimming only. It never pads, it never adds a clause. Knowing which half of a feature to delete is a skill worth paying for.

Multi-tenancy is a decision you make once

Multi-tenancy is the choice you cannot cheaply reverse. Row-level tenant IDs are quick to build and quick to leak — one missing WHERE clause and customer A is reading customer B. Separate schemas or databases cost more to operate but make the leak structurally impossible. We will push you toward isolation, and we will tell you what it costs to run.

The related trap is sequence generation. Invoice numbers, patient codes, order references — anything a human will read and a regulator might audit. Naive implementations do SELECT MAX + 1, which is fine until two requests arrive in the same millisecond. We found exactly this in a live clinic system: patient codes were silently duplicating because there was no unique constraint behind them. The fix is a dedicated counter table with atomic increments, and the test is to fire parallel requests at it until you are convinced.

• Tenant-isolated PostgreSQL, with the isolation boundary chosen deliberately rather than by default
• Atomic, race-tested counters for every human-readable identifier
• Role-based access control designed before the first admin screen, not retrofitted around it
• Per-tenant feature gating so plans can differ without forking the codebase

Billing, subscriptions and the parts that go wrong quietly

Payment integration looks finished long before it is. The happy path takes an afternoon. What takes the time is the webhook that arrives twice, the customer who pays while their subscription is mid-renewal, the mandate that stalls in an embedded checkout and has to be handed to a hosted page instead, and the expired account that cannot reach the renewal screen because the login gate rejects it first.

Every one of those is something we have hit in production and fixed. The renewal flow on one of our own products is proven exactly-once under a deliberate triple webhook race, tested with real money rather than sandbox keys. That is the standard we would apply to yours.

How an engagement runs

We start with a written architecture note — data model, tenancy boundary, auth model, and the three things most likely to bite. It is short, and it is the most valuable document in the project, because it is where disagreements surface while they are still cheap.

Then we build in vertical slices. One complete path through the system — real auth, real database, real deployment — before breadth. You get something you can click by the end of the first phase, and it is genuinely wired, not a prototype that has to be thrown away.

Frequently asked

Related