Application infrastructure for emerging-market builders

The next generation of software companies in Africa and other emerging markets should not have to rebuild identity, workspaces, billing, entitlements, and application lifecycle before they can ship their actual products.

Ireti Platform exists to provide that common foundation. Arrowflow applications use it first; selected builders and partners can use the same contracts as they mature.

The problem is not only technical

Modern SaaS infrastructure is powerful, but much of its packaging assumes that customers already operate in mature subscription economies. Identity, authorization, billing, observability, and developer platforms are often priced per organization, per seat, per monthly active user, or behind enterprise tiers.

Those assumptions do not always fit early-stage builders, schools, clinics, agencies, professional-services firms, and local operators. Many need assisted onboarding, invoices, bank transfers, mobile money, manual approvals, collections workflows, or messaging-first support.

When the infrastructure does not fit, teams repeatedly rebuild the same foundations. They lose time, introduce security risk, and postpone the work that creates differentiated customer value.

The Ireti thesis

Ireti Platform provides reusable control-plane capabilities:

• identity and SSO through Ireti Identity;
• organizations, workspaces, members, invitations, and roles;
• application catalog, activation, launch metadata, and branding;
• subscriptions, entitlements, seat limits, and billing context;
• provisioning and connector bindings;
• stable OpenAPI, SDK, and automation contracts; and
• platform audit and support-recovery workflows.

Products remain independent. Notes owns its documents. Northfield owns school operations. Phenix and Fineract own financial records. CRM products own relationship workflows. Ireti Platform owns the shared facts needed to adopt, authorize, launch, and operate those products.

Adapt to the market without weakening the contract

The developer-facing contract should remain simple even when the operational model is regional.

A product should be able to ask:

Can this principal launch this application in this workspace?
Which current entitlements apply?
Which capabilities may this application invoke?
Where is the provisioned product resource?

The product should not need to understand whether a customer pays by card, invoice, bank transfer, mobile money, or an assisted process. It should not need identity-provider administration or billing-engine credentials.

This separation allows the platform to support regional realities behind a stable contract.

The service domains

The platform is easier to understand as a set of bounded service domains.

Identity

Ireti Identity authenticates people and applications. It owns login, recovery, MFA, federation, sessions, and OAuth protocol configuration. Authentication context never becomes a shortcut for application authorization.

Workspace

The workspace domain represents organizations, workspaces, memberships, invitations, and administrative boundaries. A person can belong to several organizations and hold different responsibilities in each.

Applications

The catalog describes approved products and providers. Activation records a tenant's adoption. Provisioning connects that adoption to an exact product resource. These are independent lifecycle facts.

Entitlements and billing

Entitlements answer which product capabilities a subscription permits. Billing coordinates pricing, subscriptions, invoices, and payment state through a provider-independent boundary. Neither should leak a vendor's internal model into every product.

Authorization and audit

Current platform state determines access. Applications receive bounded decisions rather than administrative credentials. Significant lifecycle and authorization changes produce auditable records.

Integration and developer experience

OpenAPI contracts, SDKs, webhooks, event envelopes, and provisioning adapters let products integrate without copying platform logic. The integration surface is itself a product.

What Ireti should not become

Ireti should not build an identity provider from scratch when a mature identity authority can be operated behind a clean boundary.

It should not expose billing-engine internals to product applications.

It should not centralize product-specific system-of-record data.

It should not give partners direct database access or administrative credentials.

And it should not attempt to build every possible platform feature before real applications require it.

Grow from proven product needs

The platform grows by turning demonstrated needs into reusable primitives:

1. prove a requirement with an Arrowflow application;
2. identify the correct authority and boundary;
3. expose a stable, tenant-scoped contract;
4. verify denial and revocation behavior;
5. reuse the contract in another application; and
6. offer it to selected partners only after the internal path is dependable.

If Notes needs an entitlement, the result should be a reusable entitlement contract. If Northfield needs billing context, the result should be a provider-independent billing decision. If Phenix needs financial API access, the result should preserve financial ownership while exposing a bounded capability.

The promise

Builders should ship applications, not reconstruct an infrastructure company around every product.

Ireti Platform is the shared application infrastructure. Arrowflow is the suite of applications proving it. The long-term opportunity is to let more builders reuse the same identity, workspace, catalog, access, billing, integration, and audit foundation while keeping their products and data independently owned.