Spend more engineering effort on what makes your business different.

Use cases

Many applications need access control, administration, file handling and operational visibility before their distinctive business workflow can take shape. The foundation provides reusable code for those shared responsibilities.

These are illustrative uses, not claims of completed client implementations. Each needs its own requirements, workflow design, access policies and integrations.

• Customer, dealer or partner portal: a signed-in workspace for information, documents and tasks. Dealer onboarding, catalogue rules, ordering, ERP connections and reporting are tailored business capabilities.
• Document operations: controlled upload, review, sharing and lifecycle workflows, with retention and access rules defined for the organisation.
• Membership or training portal: combine account access and structured content with project-specific membership rules, learning progress and administration.
• Compliance-evidence workflow: build evidence capture and review around permissions, files and notifications. Required audit records and compliance controls need their own implementation and assessment.
• Internal operations application: connect administrative tasks and operational data around the way the business works.
• Vertical B2B SaaS: reuse shared platform responsibilities while building the specialist domain, customer experience and operating model.

Example walkthrough

An operations portal illustrates how the pieces can connect. This is a proposed implementation journey, not a claim that every step is a preconfigured application:

1. Sign in: authenticate through the identity foundation with the access flows selected for the project.
2. Manage access: assign roles and permissions around the organisation’s responsibilities.
3. Publish content: configure the CMS content model and make relevant information available to the appropriate users.
4. Share a file: upload a document and apply the agreed access and lifecycle rules.
5. Notify users: trigger an email and review its delivery state through the notification capability.
6. Trace the flow: use logs, metrics and traces to investigate the connected request and background work.

The technical overview explains the gateway and observability boundaries. A foundation discussion can examine the architecture and available curated evidence without requiring a public demo account.

What is reused, configured and built?

• Reusable groundwork: identity, operator interfaces, file handling, email notification and observability patterns.
• Configured for the implementation: providers, roles, permissions, modules, routes and environments.
• Built for your business: domain data, business rules, customer-facing workflows, integrations and the appropriate user experience.

Reuse is considered when it fits the problem. It does not remove the need for discovery or make this the required architecture for every project.

Implementation

An implementation can be shaped around four activities:

1. Assess product and architecture fit: map requirements, risks and available capabilities; separate reuse, configuration and bespoke development.
2. Configure the foundation: select modules, identity providers, access policies, routes, environments and engineering conventions.
3. Build the first useful domain slice: connect a meaningful business workflow end to end, with appropriate tests and telemetry, before expanding the scope.
4. Prepare deployment and handover: agree the environment and data-migration approach, infrastructure responsibilities, documentation, operational ownership and next development priorities.

The scope and outputs are agreed for the engagement; these activities do not define a fixed package. How we work explains assessment, implementation and ongoing collaboration options.

The foundation is a starting point for engineering work, rather than a finished application that can simply be switched on. Production environments, operational policies, support and ongoing development require their own scope and review.

Common questions

Is this a hosted application subscription?

This page describes reusable engineering for tailored implementation. It does not offer a self-service hosted product or a standard subscription.

Does source access mean we own the entire foundation?

Source access, the rights to project-specific deliverables and the rights to reusable foundation code are separate matters. The agreement must define them, alongside third-party licences, operating responsibilities and support. No licence grant is made by this page.

Can we use our existing systems?

Existing identity, data and operational systems are part of the fit assessment. Specific adapters and integration requirements need to be reviewed; a ready-made connector is not assumed.

How can we evaluate it?

We can discuss the requirements, architecture and available curated examples. The right next step may be a focused technical conversation or a scoped assessment.