One surface for funds, mandates, distributors, and investors
Keep the operational model and the user-visible output in the same system instead of rebuilding the same context in spreadsheets, email, and slide decks.
Reporting. Workflows. Dashboards. API.
One operating layer for private markets teams.
IBEX ONE gives operations, investor relations, reporting, and platform teams a controlled path from structured data to reviewable outputs, live dashboards, and public integration surfaces. The website stays public. The product lives on the app host. Integrations land on the API host.
Built for teams managing funds, mandates, distributors, investors, review cycles, and the outputs that need to leave the building cleanly.
Public surface split
Website
localhost
App
https://app.localhost
API
https://api.localhost
From operating data to controlled output.
IBEX ONE is designed around the work that actually happens between data, review, approval, delivery, and external integrations. The goal is not another glossy dashboard. It is a cleaner operating path.
Outputs stay attached to rights, roles, and review stages
Reporting and workflow actions can inherit scoped permissions, gate review, approval, publishing, and structured follow-up without leaving the platform.
Browser views, PDFs, API bundles, and machine-facing contracts
The public API surface, developer portal, and generated delivery formats sit alongside the internal application instead of beside it as an afterthought.
Built around the surfaces that matter.
The platform already exposes the right building blocks: reporting, workflows, dashboards, security controls, and public integration surfaces. The website should make that obvious within seconds.
Template-ready reporting with lifecycle control
Create, review, approve, publish, and deliver reporting outputs from a controlled surface instead of stitching exports together after the fact.
- Template presets and report lifecycle states
- Browser views and PDF delivery paths
- Audit-friendly report actions and transitions
Assigned workflow control with deadlines and blockers
Move work through explicit stages with current-step ownership, reminders, comments, delegations, and deadline override control where it is needed.
- Step ownership and action gating
- Workflow and current-step due dates
- Comment, unblock, delegate, and close actions
Operational dashboards without losing the underlying context
Surface live views for monitoring, reporting, backlog, and workflow state while keeping the underlying record, rights, and auditability intact.
- Reporting and monitoring views
- Fund and workflow analytics surfaces
- Launchpad and operational control panels
Machine-facing delivery with a real developer surface
Expose controlled external surfaces for client credentials, tooling bundles, SDKs, webhooks, and portability contracts instead of ad hoc side endpoints.
- Developer portal on the API host
- Public API v1 contracts and SDK delivery
- Webhook and portability-oriented integration paths
A cleaner operating model.
The strongest product story here is not a marketing slogan. It is the sequence: model it, route it, review it, publish it, and expose it externally from one coherent system.
Security and trust are part of the product, not appendix copy.
The public site should communicate control clearly. This platform already points in that direction with scoped rights, passkeys, OAuth client credentials, audit operations, and signed delivery paths.
Passkeys, MFA, and standards-based auth
Authentication paths can support stronger identity controls while the API surface exposes client credentials for external integrations.
Scoped permissions around reporting and workflow actions
Review, publish, workflow, and object rights stay attached to the controlled actions that matter, instead of being implied by convention.
Audit events, health checks, and signed delivery paths
Operational activity, webhook delivery, and public file distribution can be handled with stronger observability and narrower exposure.
Three public surfaces. Three clear jobs.
This is the clean structure you wanted: the website for public presence, the app for authenticated product work, and the API for public machine-facing integrations. It is visible here because the site itself now runs that way.
Website
Public, indexable, lightweight, and content-first. Built to load fast and explain the operating model clearly.
localhost
App
Authenticated product surface for workflows, reporting, dashboards, review, and daily operations.
https://app.localhost
API
Public integrations, developer portal, reporting runtime surface, and machine-facing contracts under a clearer boundary.
https://api.localhost
See the real surfaces.
The site explains the product. The app runs the work. The API exposes the external contract. That is the right split for the current platform and the cleanest path to the production domain later.