Most AI products begin as a text box wired to a single model API. Then customers ask for searchable documents, image and video generation, pay-per-use pricing, a published website, a WhatsApp channel. Every new feature forces the same four decisions: who is asking, what are they allowed to do, which provider should do the work, and how is that work paid for. This guide walks through how a multi-feature AI SaaS product can answer those questions once, in shared layers, instead of re-solving them inside each tool. Every external fact is tied to a numbered source at the end, and each source was re-checked on 12 October 2026.
One control plane, many tools
The mistake that makes AI suites fragile is letting each tool call its provider directly. A summarizer, an image generator and a voice agent then each carry their own login checks, their own retry logic and their own idea of cost. The sturdier pattern is a thin set of shared layers that every tool passes through.
| Layer | What it owns | What goes wrong without it |
|---|---|---|
| Identity and access | Who the caller is, and what their role and plan permit | A free account reaches a paid tool by calling the API directly |
| Model routing | Choosing a provider and model per task | One provider outage or price change breaks every feature |
| Job handling | Long-running work such as media generation | Timeouts, duplicate runs and orphaned work |
| Metering | Credits, limits and usage records | Spend nobody can explain at month end |
| Knowledge | Ingestion, embeddings and retrieval | Answers that ignore, invent or leak documents |
| Publishing | Hosting what users generate | Stored scripts running on your own domain |
| Integrations | Payments, voice and messaging callbacks | Forged or double-processed webhooks |
Read as a request path: a call arrives, identity and plan are checked, credits are reserved, the router picks a provider, the work runs (streamed or as a job), the result is delivered, and the reservation is settled.
Everything below expands one step of that path. A new tool then costs a prompt template and a price-table row, not another copy of the security and billing code. The trade-off is that the shared layers become the most critical code you own, so they deserve the most tests. The same shared-core idea is what white-label super app platforms use to serve several service lines from one codebase.
Routing across multiple models
Multi-model orchestration is not “swap any model for any other.” Models differ in context length, structured-output reliability, streaming support, modality and price. A routing layer therefore needs a registry that records, for each model, what it can do and what it costs, plus a live health signal from recent errors and latency.
Selection then happens in three passes. First filter to models that can do the job at all, for example image input or a long context window. Next apply the operator’s preferences, such as a cheaper tier for free plans. Last, drop anything currently unhealthy. Fallback should only move between models in the same capability class, and prompts that depend on exact output formats should be versioned per model, because two text models can follow the same instruction differently. Treat “this fallback is good enough” as a claim to test on a sample set for each task, not as a default.
Streaming responses and long-running jobs
Chat is a streaming problem: keep a connection open and push tokens as they arrive. Video, music and large image jobs are queue problems: accept the request, return a job ID, let a worker run it, and let the client poll or receive a callback. Both need explicit timeouts, a cap on retries with backoff, and a way to cancel. Cancelling matters for billing as well as user experience, because a cancelled job has to release whatever credits were held for it.
Credits, metering and safe retries
Provider usage and platform credits are two different quantities. A provider measures tokens or generated items after the fact and bills you for them. Credits are your own unit, defined by a versioned price table that can key on tool, model tier and, for media, duration or resolution. Keeping them separate lets you change provider mix without changing what customers see.
A dependable credit flow has three moves:
For a stream that stops halfway, decide in advance whether delivered tokens are charged, and publish that rule. Reserving with a conditional update means two simultaneous requests cannot both spend the same credits.
Retries are where double charges come from. Have the client send a unique request ID and enforce uniqueness on the account and request ID pair, so a repeat becomes a lookup. Stripe’s API applies the same principle: for API v1 it saves the status code and body of the first request for an idempotency key, returns that saved response to retries, keys can be up to 255 characters, and they may be pruned once they are at least 24 hours old [6]. That is Stripe’s behavior, not something your own ledger inherits, so build the equivalent yourself. Finally, reconcile the ledger against provider invoices on a schedule, because a price table drifts from real cost unless someone checks it.
Retrieval-augmented generation with pgvector
The retrieval path turns uploaded files into answers that point back to their source. The steps are:
Embedding details that cause real bugs
Google’s documentation lists a 2,048-token input limit for gemini-embedding-001, so chunks must fit under it. The default output is 3072 dimensions, any size from 128 to 3072 is supported with 768, 1536 and 3072 recommended, and for sizes other than 3072 you must normalize the vectors yourself. The same page states that the embedding spaces of gemini-embedding-001 and gemini-embedding-2 are incompatible, so changing models means re-embedding all stored data [3]. Store the model name, dimension and task type beside every vector so mixed generations are visible instead of silently wrong. For gemini-embedding-001, the documented task types include RETRIEVAL_DOCUMENT for stored text and RETRIEVAL_QUERY for questions [3].
Indexing and permissions
pgvector supports HNSW indexes with a cosine operator class [1]. Its README explains that with approximate indexes filtering happens after the index scan, so a restrictive filter can return fewer rows than you asked for. As an example it gives a filter matching 10 percent of rows with the default hnsw.ef_search of 40, which yields about 4 matching rows on average [1]. The README suggests iterative index scans (strict or relaxed ordering), partial indexes when a filter has few distinct values, and partitioning when it has many [1]. Since document access rules are exactly this kind of filter, test retrieval with a restricted user, not only an administrator.
Keyword search versus hybrid search
PostgreSQL full-text search is a useful companion. websearch_to_tsquery accepts raw user text and, per the manual, never raises syntax errors; ts_rank_cd ranks by cover density, which considers how close matching words are to each other [2]. Running keyword search only when vector search finds nothing is a fallback. Hybrid retrieval runs both and merges the lists, and the pgvector README points to reciprocal rank fusion or a cross-encoder for that merge [1]. If you highlight snippets with ts_headline, sanitize the result, because the manual warns its output is not guaranteed safe for direct inclusion in web pages [2].
Answering honestly
Pass chunks with stable IDs and require the answer to cite them. If nothing clears a tuned relevance threshold and keyword search is also empty, say there is not enough evidence instead of improvising. Treat document text as data, never as instructions to the model.
Hosting websites that users generate
A site builder means your platform serves HTML written by a model and edited by strangers. The risk is simple: if that code runs on your application’s origin, it can act as your application. MDN’s guidance on the iframe sandbox attribute is a good starting point. It strongly discourages combining allow-scripts and allow-same-origin for same-origin content, because the embedded page can then remove its own sandbox. It also notes that sandboxing is useless if an attacker can display the content outside the frame, for example in a new tab, and says such content should be served from a separate origin [9]. In practice that means previews and published sites live on their own domain with no application cookies. Add a scan before publishing, proof of domain control (a DNS record check) before attaching a custom domain, a restrictive Content-Security-Policy, immutable versions so you can roll back, and a fast unpublish path for abuse reports.
Security basics that apply everywhere
Authorization. OWASP’s cheat sheet calls for least privilege, deny by default, and validating permissions on every request. It also advises preferring attribute-based and relationship-based access control over plain role checks, and making sure lookup IDs cannot be guessed or tampered with [8]. In an AI product that means every tool endpoint checks the caller’s plan and role on the server, not just in the interface.
Two-factor codes. RFC 6238 recommends a 30-second time step, allowing at most one step of network delay, refusing a second use of a code that already validated, and storing the keys securely [7].
Webhooks. Twilio signs requests with the X-Twilio-Signature header, hashed with HMAC-SHA1 using your auth token as the key, and says to use its SDK validator rather than writing your own [4]. Stripe needs the unmodified raw request body for signature checks, asks you to return a 2xx quickly before heavy work, does not guarantee event order, and advises logging event IDs to ignore duplicates and handling events through an asynchronous queue [5]. A safe handler verifies the signature, records the event ID, queues the work and answers immediately.
Secrets. Provider keys, payment secrets and two-factor seeds belong in a secrets manager or encrypted storage, never in client bundles or logs.
Choosing a WhatsApp integration path
Messaging is where teams often pick the fastest option and regret it later. Baileys is a WebSockets-based TypeScript library for the WhatsApp Web API. Its README says the project is not affiliated with or endorsed by WhatsApp, that the maintainers do not condone use that violates WhatsApp’s Terms of Service, and that they discourage bulk or automated messaging [11]. Meta’s own route is the WhatsApp Cloud API, which Meta hosts, which relies heavily on webhooks, and which separates free-form messages from template messages that need an approved template [10]. Consider the official route first for customer-facing business messaging, and read Meta’s current terms either way. For a packaged example of the feature set, see Zipprr’s WhatsApp automation software.
How to measure whether the design works
None of the benefits above are guaranteed. Measure them on your own traffic before claiming them.
| Metric | How to measure |
|---|---|
| Latency | Time to first token and total time, per tool and provider, at p50 and p95 |
| Task success | A labelled prompt set per tool, scored by rubric or human review |
| Retrieval quality | Labelled question and passage pairs; recall@k, comparing the HNSW index against exact search |
| Answer grounding | Citation precision, unsupported claims, and correct refusals on unanswerable questions |
| Billing accuracy | Daily ledger versus provider usage and payment events; count duplicate charges and orphaned reservations |
| Failure handling | Error rate by class, fallback success, job timeout and retry counts |
| Access control | Automated cross-tenant and cross-role tests, including retrieval permission filters |
Set targets from your own baseline rather than from another team’s numbers.
Build or buy
Building from scratch gives full control, but authentication, billing, retrieval and hosting each take care to get right. Starting from a ready-made codebase is faster, provided you review the shared layers described here before real customers depend on them. Either way, the checklist is the same.
Next step: plan your AI product with Zipprr
If you are weighing a custom build against a ready-made base, Zipprr can show how its AI chat bot and white-label platform options map to your feature list and what you would need to customize. Book a free demo and bring your requirements.
Frequently Asked Questions
1. What is an AI SaaS platform?
An AI SaaS platform is subscription software that offers AI features, such as chat, writing, image generation or document question answering, behind one login. It handles accounts, plans, billing and the calls to outside model providers so customers never manage models or keys.
2. What is multi-model AI orchestration?
It is routing each task to the most suitable model through a single internal interface. The router chooses by capability, cost and current health, and any fallback between models should be tested for the specific task.
3. How does RAG work with pgvector?
Documents are split into chunks and embedded as vectors stored in PostgreSQL. A question is embedded the same way, the nearest chunks are fetched by similarity, and the language model answers from those chunks.
4. Is pgvector enough for production retrieval?
For many products, yes, because it keeps vectors and business data in one database. Test recall and permission filtering on your own data, since approximate indexes apply filters after the index scan.
5. What is the difference between tokens and credits?
Tokens are what a provider measures and bills. Credits are the platform’s own unit, set by its price table, so a customer sees a stable price even when provider costs change.
6. How do you prevent double charges for AI usage?
Attach a unique request ID to every call and enforce uniqueness on the account and request ID. A retry then returns the earlier result instead of billing again.
7. How can AI-generated websites be hosted safely?
Treat the HTML as untrusted: sandboxed previews on a separate origin without session cookies, a scan before publishing, DNS-based domain verification, a Content-Security-Policy and a quick unpublish path.
8. Is WhatsApp automation allowed?
Meta provides the official WhatsApp Cloud API for business messaging. Unofficial libraries are not affiliated with WhatsApp and can put the number at risk, so review Meta’s current terms before choosing.
9. How do you secure webhooks from payment and voice providers?
Verify the provider’s signature with its official library, use the raw request body where required, record event IDs to ignore duplicates, and move the real work to a queue.
10. Should I build or buy an AI SaaS platform?
Build for maximum control, buy or start from a base codebase for speed. Review authentication, billing, retrieval and hosting either way.
