Praion AI is our own SaaS platform, where every client has its own database. Three applications (Lead Concentrator, Content Studio, Product Manager) share accounts, company profiles and one wallet of AI credits.
Our own product
| Industry | SaaS & technology · Internal tools & platforms |
|---|---|
| Challenge | Product understanding |
| Decision environment | Product evaluation |
| Complexity | High |
| Service | Platform |
If you are thinking about a SaaS product of your own, this case study gives one concrete example: how a basic choice, a separate database for each client, affects everything built on top of it. Praion AI is our own product, so we give its real name.
Praion AI is our own product, so it started from a need we knew well. A small business wants to answer its customers in many messaging apps. It also wants to plan its posts and keep the texts of its site organised, in one place instead of three different tools. An agency needs the same, for ten clients together.
So the platform had to serve very different clients with the same code. A small shop and a marketing office use the same service, while each sees only their own data.
This led to three applications. Lead Concentrator gathers the conversations from Messenger, Instagram, WhatsApp, Telegram and Viber into one inbox. Content Studio helps plan and prepare content for social media. Product Manager organises products, pages, SEO and AEO fields, and translations for a website or an e-shop. The client picks the application they need, or all of them together.
The goal was to keep every client separate, with a product that stays easy to use. A business trusts a shared inbox when it knows that its conversations, contacts and private notes belong only to it. The same goes for draft posts and product texts.
There was also a practical issue. Messages come from five outside services, each with its own way of connecting and its own rules. The client's team had to answer every conversation from one screen, without learning five different tools.
The two needs lead to the same answer. The separation is built into the structure of the platform. Daily work happens in one product, not in a series of separate integrations.
Four limits decided most of the design: data that stays separate, many people in one account, outside channels with their own rules, and files sent by strangers. All were solved from the first version, because each one affects how the whole platform is built.
Limit | What it meant in practice |
|---|---|
Each client's data stays separate | A separate database for each client, not a shared table with a filter |
Many people work in one account | Roles: administrator (admin) and agent; the agent sees only the company profiles (brands) assigned to them |
Outside channels have their own rules | In Messenger and Instagram, a reply is allowed within a time window set by Meta, and the product shows it clearly |
Files from strangers reach the inbox | Every attachment goes into quarantine and is checked for viruses before anyone opens it |
There is also a limit we chose on purpose: clients join the platform through public sign-up and create their own projects. So every new client starts without waiting for anyone from us.
In a platform with many clients, the first point that needs care is the shared database. There the separation depends on every query filtering correctly by client. One missing filter on one screen is enough to show another client's conversations. In tests this rarely shows, because the test data is small and tidy.
Three more points need design from the start. A client with a heavy load can slow down those who share the same tables. Deleting all of a client's data must be one clean action, not a painful cleanup job. An AI assistant that sends replies on its own can give a wrong answer to a real person before anyone notices.
That is why we designed the solution for each of these points from day one. The protection is part of the structure from the start.
We built the platform in layers. At the base, every client has one record, which we call a project, and it leads to that client's own database. An account can belong to many projects and picks one at sign-in. Inside the project, the company profiles keep the brands separate. Each application opens per company.
For the most important flow, the incoming message, the applications follow a clear order:
The channel sends the message to the platform, which checks that it is not a duplicate.
The platform finds or creates the contact and opens a conversation.
Every attachment goes into quarantine and is checked before it is shown.
The team is notified in real time. A conversation nobody has answered is assigned to someone after five minutes.
If the client has turned it on, an automatic reply or the AI assistant takes over.
With this structure, every step has one job and is checked on its own.
Four decisions did most of the work. We gave priority to the separation of data, to approval by a person and to an exact list of features. Each had a cost, which we accepted on purpose. We explain them below, one by one.
A separate database for each client needs more work to run, because every update must reach all the databases. We chose it because the separation is then guaranteed by the structure and not by the care of whoever writes the code.
The AI assistant suggests a reply, while a person decides on sending it. Only the optional Autopilot flows send automatically. They start in a mode where they only suggest and record what they would do, and take no action until a person approves. They also stop when someone from the team has already replied.
Finally, the list of features describes only what really exists. Clients join through public sign-up. A feature that exists only as a label is not presented as a feature.
Clients work in one product instead of many, and their data stays in their own database. We give no numbers, because this case describes how the product is built, not measurements.
The build itself gives concrete benefits: five channels in one inbox, an AI assistant that suggests while a person decides, files that pass a virus check before they are opened. Every change in the administrators' console is logged.
If you are planning your own platform, the questions we answered here are the most useful place to start. The article what a platform needs before code is written goes through them one by one. The page SaaS platforms and business applications explains how we work. The way we build such products is described in Planner: from specification to application.
Yes. Every client, which we call a project, has its own database. An account can belong to many projects, but the data of each project is stored separately. After public sign-up, the client creates their own projects.
The inbox covers Facebook Messenger, Instagram, WhatsApp, Telegram and Viber, together with the comments on Facebook and Instagram posts. Messenger and Instagram connect with sign-in through Meta. WhatsApp, Telegram and Viber connect with credentials that the provider gives.
Not by default. The assistant suggests a reply, a summary and a next step, while a person sends or changes them. Automatic sending exists only in the optional Autopilot flows. These can start in a mode where they only suggest and do nothing until a person approves.
Yes, we can discuss it. We start from your own requirements and not from a ready-made list of tools. Describe your idea in the project request or write to us at info@iwebforyou.com.
Planner is our own tool that turns detailed specifications into an application without supervision. For every feature the test is written first, the result is checked in the browser against the design, and a quality gate decides what moves on.
The website of a SaaS platform makes the product clear when the content is split by audience and depth, with use cases placed before the feature list.
We built the AWS infrastructure of a US healthcare platform (SaaS) from scratch. The app runs on Elastic Beanstalk with Nginx.
Send a project request, or check your current website for free. We read every message ourselves.