We identified a documented gap
A Babalawo — a priest in the Yorùbá Ifá tradition — runs a practice that looks, structurally, like a clinical one. A client comes for a reading. The reading produces a record: what was seen, and what the client must now do (an offering to make) and not do (a restriction to observe). The relationship is longitudinal, obligation-driven, and intensely private. The practitioner needed exactly what a doctor's office has — a client-facing portal holding each client's history, their prescribed actions, and whether they followed through.
Nothing on the market fit, and the reasons were structural. Strip away the tradition and the shape is generic: a client-owned, provider-scoped longitudinal record with an obligation-and-compliance loop. That shape sits in a gap between three mature product categories, and each one misses it for a different reason.
No finished, domain-shaped system that gives the client ownership of a longitudinal record with a real obligation loop — and no tool anywhere where the operator is structurally barred from reading the content.
We investigated why the gap persists
The gap isn't an oversight. Each adjacent category is prevented from closing it by the very thing that makes it work.
Clinical platforms can't leave the clinic
The prescribe–track–comply loop exists in mature form only in health and wellness software. But it is built around health protocols, adherence, and clinical vocabulary, and sold per-seat to practices that bill insurance. A non-clinical practitioner is not a customer these platforms know how to serve; the loop they need is trapped inside a product shaped for someone else.
Generic portals have no domain
The white-label client portals are excellent at what they do — files, messages, invoices, e-signatures, all under your brand, live in a day. But their core object is a document or a task, not a prescribed obligation with a compliance state. There is no place in them for "here is what you owe, here is your status, here is the nudge." The loop that matters most has no home.
Advice marketplaces own the client, not the reverse
The platforms built for spiritual and advisory services run on a pay-per-minute wallet with the platform as sole merchant of record. The operator owns the relationship, the transaction, and the record. That is a deliberate business model — and the precise opposite of a practitioner who needs the client to own their own history and needs the operator to see as little as possible.
The conclusion of the investigation: this practitioner didn't need a subscription, a toolkit, or a marketplace listing. They needed the thing none of the three sells — a finished system, shaped to their own domain, where the client owns the record and the operator is kept structurally blind to its contents.
We intervened — and deliberately left something out
We built Ebo-Chart: a multi-tenant, client-controlled record platform standing on three pillars. Each practitioner sees only their own clients; each client owns their own record.
Longitudinal record
A client-facing history of dated events, each authored by the practitioner.
Obligation loop
Every event carries prescribed actions and restrictions; the system tracks completion and surfaces who has fallen behind.
Conditional payments
An itemized quote the client approves before paying, routed so the practitioner is paid in local currency and the platform never becomes merchant of record.
The operator's ability to read the content.
The company that runs Ebo-Chart cannot see what a reading said. It operates on metadata — that a reading occurred, that an obligation is open or met, that a payment cleared — and nothing more. The private substance of the relationship is walled off from the operator by the architecture, not by a promise in a privacy policy.
That omission is the design, and it enforces the principle underneath the whole build: the record belongs to the client, not to the operator. Client-ownership is easy to claim and hard to prove — every marketplace claims to respect its users while quietly owning everything they generate. The only version of the claim that survives scrutiny is one the operator cannot violate even if it wanted to. So we made operator-blindness structural. The privacy wall isn't a compliance feature bolted to the side of the product; it is the product's central guarantee — and the reason a practitioner in a sensitive tradition can trust the system with a client relationship they would never hand to a marketplace.
For the technically curious (optional depth)
The platform is a React PWA over a Hono/TypeScript API and a PostgreSQL store, deployed as a single multi-tenant instance with per-practitioner isolation enforced below the application layer. Payments use Stripe Connect destination charges: the platform orchestrates the transaction but is not the merchant of record, so practitioners receive payouts in local currency and the platform takes zero net margin on the flow. The domain model was built extensible from day one — a second tradition can be added as reference data, without migrations or code changes, which is the same seam that later makes white-labeling a configuration rather than a rebuild. The stack is deliberately unexotic: the judgment is in the boundaries, not the components.
We documented the outcome — and what generalizes
The outcome. Ebo-Chart is live in production serving a real practitioner cohort. The thing we gave up — the operator's ability to read the content, and with it the easy data-leverage every marketplace relies on — is precisely the thing that turned a niche build into a general asset. "The operator structurally cannot read your clients' records" is not a limitation to a privacy-sensitive practice. It is the single most reassuring sentence they can hear, and no clinical platform, generic portal, or marketplace can say it.
What generalizes. The architecture separates what belongs to the practitioner from what is the system.
Shape of an event
Kinds of obligations
Reference content
Branding
Obligation loop
Payment orchestration
Tenant isolation
Operator-blind privacy wall
A deployment for a new domain is a re-configuration and a vocabulary map, not a fresh build. And the shape re-fits a surprising range of practices the moment you stop calling it divination.
A client owes a checklist of documents, appointments, and filings on hard deadlines, where a missed obligation can sink a case — the same loop, with legal consequences.
The client must execute and fund instruments after the engagement ends, at a drop-off point the lawyer currently cannot see.
Implementation steps assigned between sessions, with no structured way to know whether they happened.
Each is the same engine — longitudinal record, obligation loop, client-owned, operator-blind — pointed at a different vocabulary. That is the offer: the architecture is proven and owned, and a new vertical takes it on as a white-label deployment configured to their domain, with B&A Solutions hosting and maintaining it for an ongoing fee. The client gets the finished system the market refuses to sell them. They do not get another dev shop starting from a blank repository and their money.