# Clarkware Financial Plan

## Purpose

This document defines the current financial plan for Clarkware as a staged software business.

The near-term goal is not to maximize software revenue immediately. The near-term goal is to finance development and testing in a disciplined way while preserving a path to later bundled node value and selective standalone monetization.

## Commercial Principle

Clarkware should be treated in three financial stages:

1. development and testing asset
2. bundled node-enablement product
3. selective standalone and external-access product

This sequence matters. Clarkware should not be modeled as a mature SaaS business before the Niagara pilot and repeatable node package exist.

## Stage 1: Development And Testing

During the pilot stage, Clarkware behaves primarily as a cost center with strategic value.

Primary costs:

- product and engineering time
- pilot deployment and support
- local infrastructure and data handling
- integration and adapter work
- UI, reporting, and workflow iteration

Primary financial objective:

- keep spend tied to clearly staged proof points
- avoid premature platform buildout
- convert technical work into reusable node-launch assets

## Stage 2: Bundled Node Value

Once the pilot is credible, Clarkware should become part of the standard CLARK node package.

That means its first reliable monetization path is not a broad external seat business. It is bundled value inside:

- node onboarding
- recurring node licensing
- quality and reporting enablement
- training and operating-system support

## Stage 3: Selective External Access

Only after the node package is credible should CLARK expand Clarkware into selective standalone monetization.

This may include:

- limited-access external user accounts
- specialist remote-participation access
- premium reporting and audit packages
- facility deployments outside full Assembly Centre / Assembly Center relationships

## Working Revenue Architecture

The current working revenue architecture should be:

- `one-time onboarding and implementation`: charged when Clarkware is deployed as part of node setup
- `recurring node software value`: bundled into node licensing by default
- `external limited-access fees`: charged only for non-node users or partial-access customers
- `special integration work`: scoped separately where a facility needs unusual adapter or workflow work

## Working Pricing Hypotheses

These are planning bands, not validated market prices.

### Node Onboarding And Deployment

- light deployment: CAD 5,000 to CAD 12,500
- standard node deployment: CAD 12,500 to CAD 25,000
- integration-heavy deployment: CAD 25,000 to CAD 50,000+

### Recurring Node Software Value

- early bundled software value target: CAD 1,500 to CAD 3,000 per month per node
- heavier multi-station or reporting-rich deployments: CAD 3,000 to CAD 7,500 per month

### External Limited Access

- light external access: CAD 75 to CAD 150 per user per month
- specialist or manager access: CAD 150 to CAD 300 per user per month

These figures should be validated only after the pilot can demonstrate real operating value.

## Cost Discipline

Clarkware should use milestone-gated spending.

Recommended spending gates:

- Gate 1: workstation proof
- Gate 2: facility reporting proof
- Gate 3: second-station repeatability
- Gate 4: reproducible node package

No major expansion into cross-node intelligence or deep automation should occur before Gate 4.

## Gross-Margin Logic

Clarkware should eventually be one of CLARK's higher-margin lines, but only after:

- pilot-support load declines
- deployments become standardized
- adapter patterns become reusable
- implementation work stops being mostly custom

Until then, management should assume that practical contribution comes more from enabling node economics than from immediate software gross margin.

## Year 1 And Year 2 Planning View

### Year 1

- financial role: controlled development and testing spend
- revenue expectation: minimal direct software revenue
- success metric: pilot proof, not software ARR

### Year 2

- financial role: early bundled node-value capture
- revenue expectation: onboarding and bundled software value begin to matter
- success metric: at least one repeatable node software package with defined pricing logic

## Decision Rules

Clarkware pricing should not be finalized until CLARK can show:

- real user activity in live work
- evidence capture that matters to operators and managers
- at least one repeatable deployment pattern
- a clear support burden estimate per deployment

## Key Risks

- treating Clarkware like generic SaaS too early
- underpricing integration-heavy deployments
- overbuilding custom features that do not generalize
- promising node-wide software value before deployment discipline exists

## Current Recommendation

Use Clarkware financially as a staged enablement asset first and a monetized software layer second.

The most important near-term financial question is not "what is ARR?" It is "what spend is justified to prove a reusable node software package?"