Enterprise Performance Engineering software

Performance Engineering starts with questions, not scripts.

PECP converts messy project intelligence into governed, traceable Performance Engineering decisions—from business demand to engineering evidence.

Product under active development.

The problem

Generating load is not the hardest part

Requirements, architecture, tickets, spreadsheets, telemetry and stakeholder conversations rarely arrive as one dependable performance model. Engineers still have to find the information, judge its provenance, expose gaps and conflicts, translate demand into workload, design a valid experiment and defend the final decision.

PECP is being built to govern that process. It sits above the Performance Engineering toolchain rather than replacing k6, JMeter, delivery systems, observability platforms or work-management products.

100,000 users

That is not yet a performance requirement.

Are they registered, daily active or concurrent users? Which journeys do they perform, how often, and during what peak? What throughput matters? Which figures are approved, and which are still assumptions?

One governed lifecycle

From project intelligence to published evidence

  1. 01
    Project intelligence
  2. 02
    PE intelligence
  3. 03
    Gap & conflict review
  4. 04
    Workload model
  5. 05
    Performance Contract
  6. 06
    Strategy & test plan
  7. 07
    Canonical test definition
  8. 08
    k6 execution
  9. 09
    Results
  10. 10
    Acceptance
  11. 11
    Findings
  12. 12
    Evidence package
  13. 13
    Publishing / export

PECP treats these stages as one governed engineering lifecycle rather than a collection of disconnected documents and tools.

Canonical model

Missing information remains missing

Documents, portal views, tests, reports and integrations connect to a governed Performance Engineering model. Source, state, history and calculation lineage answer a vital question: where did this come from?

PECP does not invent a convenient default to make a workflow look complete. Workload calculations, acceptance, findings and evidence generation are deterministic.

RetailCo reference lab

Translating business demand into workload

A fictional Black Friday 2026 scenario verifies the lifecycle end to end.

31,500

orders per hour

8.75

orders per second

8%

checkout share of journeys

109.375

mixed iterations per second required

Browse 55%Search 20%Basket 15%Checkout 8%Account 2%

The business rate cannot be sent directly to a mixed-journey scheduler. PECP applies the journey distribution so the desired checkout throughput is represented by the whole workload.

Acceptance that asks the harder question

Thresholds passed. Workload proof did not.

In the reference execution, individual criteria such as checkout p95 and HTTP failure rate passed. But the available telemetry could not conclusively prove that the required steady-state workload was achieved.

PECP therefore did not turn green thresholds into an unjustified success.

Capabilities established

A platform, not a dashboard

  • Intelligence
    Canonical states, conflicts, provenance, intents and workload modelling.
  • Contracts and artefacts
    Performance Contract, strategy, test plan, fingerprint binding and drift detection.
  • Execution preparation
    Engine-neutral test definitions, k6 bundles, preconditions and workload schedules.
  • Evidence governance
    Results, acceptance, findings, defect candidates, evidence and publication bundles.
  • Portal
    Results, findings, executions, evidence and workload visualisation.
  • Persistent platform
    Organisations, projects, migrations, tenancy boundaries, transactions and isolated requests.

Platform architecture

Determinism through every layer

Portal

React + TypeScript

Vite, Tailwind and Recharts support structured review and workload visualisation.

API and domain

Node.js + Fastify

Versioned services sit over deterministic domain packages and canonical engines.

Persistence and execution

SQLite + k6

Transactional embedded persistence and an engine-neutral boundary with k6 first.

Repository and application-service boundaries, providers, a Unit of Work, concurrency isolation, npm workspaces and automated CI support reproducible behaviour.

AI-assisted engineering

Acceleration with explicit authority boundaries

PECP demonstrates an AI-assisted workflow in which AI accelerates implementation while architecture, domain constraints, tests and deterministic governance control the result. The same principle shapes the product: AI may assist extraction, classification, explanation and drafting, but it does not own calculation, approval or evidence.

Current product status

Built incrementally through governed milestones

The deterministic Performance Engineering engine, evidence lifecycle, portal and persistent platform foundation are established. Current productisation work is adding identity, permissions, audit authority and the remaining customer-facing integration layers required for the sellable MVP.

The intended production model is customer-controlled deployment, not a conventional public multi-tenant SaaS. Existing enterprise customers and production readiness are not claimed.

From specialist process to software

Does a complex process still live in spreadsheets, documents and manual decisions?

PECP began with a real industry problem and a body of specialist Performance Engineering knowledge. Wear Valley Digital is turning that expertise into a governed software product.