What we build
A portal where each client sees only their own data
And the boundary is enforced by the database, not by careful coding.
Why most portals are one bug from a leak
In a typical portal the interface decides what you see. A missing check in one query, one new screen added in a hurry, and a customer sees another customer’s records.
That is not a hypothetical. It is the single most common way a portal leaks, and it is invisible until it happens.
What gets built
- A private login per customer, investor or partner
- Their own status, statements, documents and reports — and nothing else
- An owner or admin view for you, with the ability to preview exactly what any one client sees
- Bilingual English and Arabic where you need it
How the isolation actually works
- Row-level security in the database: the query returns fewer rows, rather than the screen hiding them
- A new module cannot accidentally bypass the boundary, because the boundary is not in the module
- Commercially sensitive figures — your margin, your costs — are never sent to a partner’s browser at all
- Every isolation boundary is tested by attack before launch, signing in as two real accounts
Running today
UNIFAM runs a per-investor portal where each investor sees only their own position, published from the company’s own workbook. A confidential cross-border payments platform runs a partner portal that can never see margin.
How it starts
With a free 30-minute call, then a two-week paid discovery at AED 15,000 that ends in a written specification, a clickable prototype of your own system, and a fixed price. It comes off the build in full if you go ahead — and if you don't, you keep the specification and the prototype.
Also built here