Skip to main content

​
Overview

The arckit platform-design command creates a comprehensive platform strategy for multi-sided ecosystems using the Platform Design Toolkit (PDT) from Boundaryless.io. This methodology is designed for marketplaces, data sharing platforms, service platforms, and ecosystem orchestration.

​
Command Syntax

arckit platform-design "<platform name>"

​
Arguments

​
platform
string
required
Platform name or description, e.g. NHS API marketplace, gov procurement platform, data sharing ecosystem

​
What It Creates

Generates a comprehensive 8-canvas platform design document:
  • File: projects/{NNN}-{project-name}/ARC-{PROJECT_ID}-PLAT-v1.0.md
  • Document ID: ARC-{PROJECT_ID}-PLAT-v1.0
  • Content: 8 PDT canvases (1,500-2,500 lines) covering ecosystem, entities, motivations, transactions, learning, experience, MVP, and synthesis

​
Prerequisites

MANDATORY: Must run arckit principles first. Platform designs require architecture principles. Run arckit principles before proceeding.
RECOMMENDED: Also run arckit stakeholders (for better entity portraits), arckit requirements (for platform capabilities), and arckit wardley (for build vs buy decisions).

​
Platform Design Toolkit (PDT) v2.2.1

The PDT methodology focuses on:
  • Multi-sided ecosystem thinking: Supply side, demand side, supporting entities
  • Transaction cost reduction: Core value proposition
  • Learning engine: Creates long-term defensibility
  • Network effects: Same-side, cross-side, data, learning effects

​
8 Canvases

1

Canvas 1: Ecosystem Canvas

Map 5-15 entity types (Supply side, Demand side, Supporting)
  • Create Mermaid diagram showing relationships
  • Catalog entities with roles, resources provided/consumed
  • Define ecosystem boundaries and interfaces
2

Canvas 2: Entity-Role Portraits

3-5 portraits minimum (supply-side, demand-side, supporting)For EACH portrait:
  • Context: Who they are, current situation, constraints
  • Performance Pressures: External and internal forces
  • Goals: Short-term (0-6mo), medium-term (6-18mo), long-term (18+mo)
  • Gains Sought: 5 value propositions with metrics
  • Linkage to Platform Features: Map goals → features → value delivery
3

Canvas 3: Motivations Matrix

Cross-entity motivation analysis (NxN matrix)
  • Identify synergies (aligned motivations)
  • Identify conflicts (misaligned motivations)
  • For each conflict: Platform solution to resolve it
4

Canvas 4: Transactions Board

10-20 transactions minimumFor EACH transaction:
  • Transaction name
  • From entity → To entity
  • Existing? (Yes/No - does it happen today?)
  • Current channel and transaction costs
  • Platform channel and reduced costs
  • Cost reduction percentage
Calculate total value created (cost savings × transaction volume)
5

Canvas 5: Learning Engine Canvas

5+ learning servicesFor EACH learning service:
  • What: Service description
  • Inputs: Data sources
  • Outputs: Delivered value
  • How Entity Improves: Specific improvements
  • Platform Benefit: Why this creates defensibility
  • Success Metric: Measurable impact
Define learning services business model (freemium, premium tiers)
6

Canvas 6: Platform Experience Canvas

2+ core journeys (supply-side onboarding, demand-side discovery)For EACH journey:
  • Journey map: 8-10 stages from awareness to retention
  • For each stage: Entity action, platform service, transaction ID, learning service, touchpoint, pain point addressed
  • Journey metrics: Time, cost, completion rate, satisfaction
Business Model Canvas: Revenue streams, cost structure, unit economics, LTV:CAC ratios
7

Canvas 7: Minimum Viable Platform Canvas

MVP definition and validation strategy
  • Critical assumptions (5+): What must be true for platform to succeed?
  • For each assumption: Riskiness, evidence needed, test method
  • MVP feature set: What’s IN, what’s OUT
  • Liquidity bootstrapping strategy: How to solve chicken-and-egg problem
    • Phase 1: Curate initial supply
    • Phase 2: Seed demand
    • Phase 3: Test transaction velocity
    • Phase 4: Expand liquidity
  • Validation metrics: 10+ success criteria for Go/No-Go decision after 90 days
  • MVP timeline and budget
8

Canvas 8: Platform Design Canvas (Synthesis)

The 6 Building Blocks:
  1. Ecosystem: Who participates, ecosystem size targets
  2. Value Creation: Value for supply, demand, overall ecosystem
  3. Value Capture: Revenue model, pricing rationale
  4. Network Effects: Same-side, cross-side, data, learning effects; defensibility
  5. Transaction Engine: Core transactions, cost reductions, velocity targets
  6. Learning Engine: Learning services summary, revenue, impact
Strategic Alignment: Link to stakeholders, requirements, principles, Wardley maps

​
Auto-Population from Existing Artifacts

The command automatically extracts data from existing ArcKit artifacts:

​
From Stakeholder Analysis (ARC--STKE-.md)

  • Stakeholders → Map to Entities in ecosystem
    • Example: “CFO” stakeholder → “Enterprise Buyer” entity (demand side)
    • Example: “Service Provider” stakeholder → “Independent Consultant” entity (supply side)
  • Drivers → Map to Performance Pressures
  • Goals → Map to Entity Goals
  • RACI Matrix → Map to Ecosystem Roles

​
From Requirements (ARC--REQ-.md)

  • BR (Business Requirements) → Map to Value Creation and Revenue Model
  • FR (Functional Requirements) → Map to Platform Features and Transaction Engine
  • NFR (Non-Functional Requirements) → Map to Platform Architecture and MVP Scope
  • DR (Data Requirements) → Map to Learning Engine (analytics, insights)

​
From Wardley Maps (wardley-maps/ARC--WARD-.md)

  • Components and their Evolution Stages:
    • Genesis (0.00-0.25) → Build (novel, differentiating)
    • Custom (0.25-0.50) → Build or Partner (emerging, core capability)
    • Product (0.50-0.75) → Buy (commercial products available)
    • Commodity (0.75-1.00) → Use Utility (cloud, SaaS, APIs)

​
From Architecture Principles (ARC-000-PRIN-*.md)

  • Example: Principle “API-First” → Platform must expose APIs for ecosystem integrations
  • Example: Principle “Data Privacy by Design” → Learning engine must anonymize entity data
  • Example: Principle “Cloud-Native” → Platform runs on AWS/Azure, serverless where possible

​
Good Use Cases for Platform Design

Multi-sided marketplaces

Supplier-buyer platforms, G-Cloud, procurement marketplaces

Data sharing platforms

Cross-government data mesh, NHS data sharing, open data portals

Service platforms

GOV.UK services ecosystem, local government platforms, citizen services

Ecosystem orchestration

Vendor ecosystem, partner network, app store, API marketplace

​
NOT Suitable for Platform Design

The following are NOT suitable for platform design (use alternative commands instead):
  • Single-product SaaS applications: Use arckit requirements and arckit hld-review instead
  • Internal enterprise systems without multi-sided ecosystem: Use arckit requirements
  • Point-to-point integrations: Use arckit diagram for architecture

​
UK Government Context

For UK Government projects, the command includes Government as a Platform (GaaP) principles, Technology Code of Practice (TCoP) alignment, GDS Service Standard implications, and Digital Marketplace positioning (G-Cloud, DOS).

​
Real-World Example

​
NHS API Marketplace

arckit platform-design "NHS API marketplace connecting health app developers with NHS trust data APIs"
Generated Design:
  • Ecosystem: 12 entity types (App Developers, NHS Trusts, Patients, ICO, NHSX, etc.)
  • Entity Portraits:
    • Supply-side: NHS Trust API Product Owner (goals: monetize APIs, improve data quality)
    • Demand-side: Health App Developer (goals: fast integration, reliable data, GDPR compliance)
    • Supporting: ICO Data Protection Officer (goals: ensure GDPR compliance, audit trail)
  • Motivations Matrix: 15 synergies identified, 3 conflicts (resolved via platform features)
  • Transactions: 18 transactions cataloged, 67% average transaction cost reduction
  • Learning Engine: 7 services (API quality scoring, developer onboarding analytics, usage forecasting)
  • Platform Experience: 2 core journeys (API provider onboarding 3 weeks → 3 days, Developer integration 2 months → 2 weeks)
  • MVP: 8 critical assumptions, liquidity strategy (curate 5 NHS trusts, seed 20 developers, 50 API calls in 90 days)
  • Platform Design Canvas: £150K per transaction cost savings annually, 15% commission + £50/mo subscriptions, network effects via data quality improvements

​
Command Handoffs

​
Create RFP for Platform Development

arckit sow
Generate Statement of Work / RFP for platform development vendors.

​
Review Platform Architecture

arckit hld-review
Review high-level platform architecture against design canvases.

​
Generate Sprint Backlog

arckit backlog
Generate sprint backlog from platform features and MVP scope.

​
Important Notes

The platform design document is comprehensive (1,500-2,500 lines). The command uses the Write tool to create the file and shows only a summary to avoid token limits.

​
Key Concepts

  • Multi-sided markets: Platform design is for 2+ sided markets (supply-demand)
  • Transaction cost economics: Core value proposition is reducing transaction costs
  • Learning engine as moat: Creates long-term defensibility through data and insights
  • Network effects: Same-side, cross-side, data, learning effects drive growth
  • Liquidity bootstrapping: Must solve chicken-and-egg problem to launch
  • MVP validation: Define smallest testable platform to validate riskiest assumptions

​
Methodology Reference

Platform Design Toolkit (PDT) v2.2.1

Build docs developers (and LLMs) love

Get started for freeTalk to us