How We Build Projects and Partners

Innopo works with two core concepts at the framework level: Projects and Partners. Projects are assembled platforms built from Business Systems. Partners are the organisations these platforms are built for.

This page explains how Projects and Partners are represented inside the Innopo Platform, how they are connected, and how they evolve over time.

Definitions

Partner

A Partner is an organisation that works with Innopo. Each Partner has its own profile in the Innopo Platform, which stores:

• basic details (name, domain, contact information)
• notes on their workflows and objectives
• the Projects associated with that Partner
• which Business Systems are used across those Projects

Project

A Project is a specific platform built for a Partner using the Innopo Modular Systems Framework (IMSF). Each Project:

• assembles one or more Business Systems
• has its own workflow customisation layer
• tracks deployed environments (for example, staging, production)
• pins to specific system versions

A Partner can have multiple Projects. For example, one Partner might have a quoting platform and a separate internal tools dashboard.

How We Create a New Partner

When we begin working with a new organisation, we first create a Partner entry in the Innopo Platform. This does not immediately create a Project; it creates a profile that future Projects can be attached to.

A Partner record typically includes:

• Partner name and primary contact
• Industry or domain context
• Links to reference material (for example, their current site)
• Initial workflow notes and discovery comments
• List of Projects (empty at the beginning)

This separation allows us to have a long-term relationship with a Partner, even as multiple Projects are created, paused, or evolved over time.

How We Create a New Project for a Partner

A Project starts when a specific workflow or platform need is identified. The process follows the IMSF steps and is tracked as a distinct Project linked to a Partner.

High-level steps to create a Project:

1. Attach to a Partner: The Project is created under a specific Partner inside the Innopo Platform.
2. Define the workflow: We complete the Workflow Mapping step (Step 1), documenting the process the Project must support.
3. Select systems: We identify which Business Systems from the library are required (Step 2).
4. Assemble the base platform: The selected systems are combined to form the Project’s base application (Step 3).
5. Add custom workflow logic: Partner-specific rules, branding, and integrations are implemented in the workflow layer (Step 4).
6. Launch and evolve: The Project is deployed, and system versions are tracked for future evolution (Step 5).

What the Innopo Platform Stores for Each Project

Inside the Innopo Platform, each Project has its own entry with structured metadata. This allows us to keep a clear technical and conceptual picture of every platform.

Typical Project fields include:

• Project name and description
• Linked Partner
• Current status (for example, discovery, in build, live)
• Deployed environments (staging, production URLs)
• List of Business Systems in use
• Version map (which version of each system is installed)
• Notes about the workflow customisation layer
• Key dates (start, launch, major upgrades)

This information makes it easy to see, at a glance, what the Project consists of and how it has changed over time.

The Relationship Between Systems, Projects, and Partners

The hierarchy inside Innopo can be thought of in three levels:

• Systems – reusable building blocks.
• Projects – assembled platforms using systems.
• Partners – organisations for whom Projects exist.

A single Business System can be reused across many Projects. A Partner may have one or multiple Projects. This modular structure allows:

• shared improvements to systems across different Projects
• clear tracking of which systems are used where
• Partners to grow into additional Projects over time

Partner View vs. Internal View

Internally, the Innopo Platform shows full details about systems, versions, and configuration across all Partners and Projects.

Partners, however, only see information relevant to them. In a restricted view, a Partner typically sees:

• the Projects associated with their organisation
• which Business Systems those Projects are using
• the current state of each Project (for example, live, in progress)
• high-level notes on what each system does in their context

This provides transparency without exposing internal implementation details or other Partners’ information.

How Projects Evolve Over Time

Projects are not fixed. As workflows change or systems improve, a Project can be updated in a controlled way.

Typical evolution actions include:

• adding a new Business System to a Project
• upgrading a system to a new minor or major version
• extending the workflow layer with new rules or flows
• creating an additional Project for the same Partner

All changes are recorded against the relevant Project, with system versions and dates, so the full history remains clear.

Why We Separate Projects and Partners

Keeping Projects and Partners as distinct entities provides several benefits:

• Clarity: It is always clear which platform belongs to which organisation.
• Reusability: Systems can be reused across Projects without being tied to a single Partner.
• Scalability: Partners can grow from one Project to several as their needs expand.
• Maintenance: Upgrades and changes can be managed at the Project level while keeping a stable record at the Partner level.

Summary

Innopo builds platforms by assembling Business Systems into Projects that are linked to Partners. Projects represent concrete, versioned platforms; Partners represent long-term relationships with organisations. This separation allows us to reuse systems efficiently, maintain architectural clarity, and support multiple Projects per Partner as needs evolve.