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
- 01
Project intelligence - 02
PE intelligence - 03
Gap & conflict review - 04
Workload model - 05
Performance Contract - 06
Strategy & test plan - 07
Canonical test definition - 08
k6 execution - 09
Results - 10
Acceptance - 11
Findings - 12
Evidence package - 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
This fictional retail scenario illustrates how business demand translates into a workload. These inputs are examples, not product defaults or measured production traffic.
31,500
orders per hour
8.75
orders per second
8%
checkout share of journeys
109.375
mixed iterations per second required
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
Passing thresholds still needs workload evidence.
A test can meet individual criteria, such as checkout p95 and HTTP failure rate, while its telemetry does not establish that the required steady-state workload was achieved.
In that situation, the acceptance decision should remain inconclusive until the workload is established. Green thresholds alone are insufficient.
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.