From email chains to a tamper-evident traceability platform

The challenge

Our client is a digital platform company in industrial metal trading. The client wanted to expand beyond trade into orchestration: the coordination of a full decommissioning of heavy industrial assets. This work runs across a network of partners, for an enterprise customer with a circular-economy programme. The process is months long, multi-party, hazardous, and heavily regulated. One project involves the asset owner, the enterprise that orchestrates it, dismantlers, oil processors, carriers, smelters, and sometimes manufacturers. It also involves compliance officers and external auditors.

Today that process runs on email chains, scanned PDFs, spreadsheets, and phone calls. The cost appears in five places:

• Sustainability claims depend on evidence spread across many inboxes.
• Licenses expire, and nobody notices.
• Partners argue about weight differences over email instead of a shared record.
• Staff spend hours on status requests.
• Each new partner joins through a separate, one-off conversation.

No off-the-shelf product covers this process. Our client needed a custom platform, and needed to show a functional system to the enterprise partner quickly.

What we built

We built a multi-tenant coordination and traceability platform. Each company on the platform sees only its own data. It also sees only the part of a shared project that concerns it.

The platform keeps one shared record per project. Three rules define that record:

• Every hand-off of material becomes a first-class custody event.
• The party that holds a document uploads that document.
• Every regulatory export comes from the same operational data that ran the project.

The audit trail is not a separate artefact that somebody assembles later. The audit trail is the work itself, in order.

In three months, a small team took this platform from an empty repository to an application that covers the full lifecycle:

• Partner onboarding, with license verification and alerts before a license expires
• A five-step project wizard with a fully editable execution chain (the ordered plan of who does what, where, and with which loss tolerances)
• Pickup schedules, transport legs with a custody transfer at pickup and at delivery, and weight-variance resolution with evidence windows
• Records for dismantling, smelting, and manufacturing, with material piles as the accounting unit and lineage from the source asset to the finished output
• Loss controls with colour-coded thresholds. A moderate loss requires a written explanation and photo evidence. A severe loss pauses the project until an administrator reviews it
• Compliance document gates that block process steps until the required evidence is on file (test reports, weighbridge tickets, quality certificates)
• Closure certificates, final reports, and a carbon-footprint report, all from operational data. Each document carries a cryptographic content hash. An auditor can then verify that the PDF matches the platform output
• A role-based Control Tower dashboard, and a notification system for email and in-app channels

The proof of concept contains roughly 60,000 lines of TypeScript, about 195 business-logic modules, 75 database tables, and 576 screen components.

Technology choices

We chose a mainstream, maintainable stack on purpose, and put the innovation into the architecture instead:

• Next.js 15 with TypeScript in strict mode - one framework for the UI and the API, and no any type anywhere in the codebase
• GraphQL, schema-first - the .graphql schema files are the contract. Code generation produces typed resolvers and client hooks, so the API cannot drift from its types
• PostgreSQL with Prisma - every schema change needs a matching migration. Pre-commit hooks and CI enforce this rule
• Material UI, React Hook Form, and Zod - typed, validated forms from the schema to the submission
• AWS - a containerized application, managed Postgres, and S3 for documents and generated PDFs

Two architecture decisions had the largest effect.

Policy-based access control as the single source of truth. The platform holds ten different personas from companies that compete with each other. Role checks spread through the UI were therefore not an option. Every authorization decision goes through a central policy engine:

• GraphQL resolvers use a schema directive.
• The server uses a single evaluation function.
• The client uses permission flags that arrive with the data.

A lint rule blocks an inline role check. A coverage test confirms that every declared permission action has a policy decision in the seed data. Authentication includes an SSO base (SAML), two-factor authentication through TOTP and email codes, a full password lifecycle, and four-eyes approval workflows for sensitive operations.

An audit trail with a cryptographic chain. The platform logs every meaningful action with the actor, the action, the state before and after, and a request fingerprint. Each log entry carries a SHA-256 hash of the previous entry. These hashes form a per-tenant hash chain. A walk along the chain detects any change to a historical record, as German GOBD record-keeping rules require. The platform also logs each audit export, so an auditor can audit the auditors.

Engineering discipline at speed

Three months with a small team works only if machines enforce the quality rules, not people. The guardrails ran from the first day:

• More than 16,000 automated test cases in unit, integration, and end-to-end suites (Jest and Playwright). The coverage gates are 80 percent overall and 90 percent for business-logic services
• A strict ESLint configuration: a maximum cyclomatic complexity of 10, a limit of 100 lines per function and 500 lines per file, and zero warnings
• Pre-commit hooks that run lint, format, and schema-drift checks. CI blocks any merge that fails a gate
• Strict layers: routes and resolvers stay thin, and the business logic sits in services. The 90 percent coverage requirement applies to those services

These rules were not aspirational documentation. CI enforced them on every commit. That enforcement let a small team work fast on a compliance-grade system. It also avoided the technical debt that usually comes with proof-of-concept speed.

Why fixed scope and a small team works

Custom product development fails most often through drift. The scope grows, the team grows with it, and the feedback loop with the client gets longer. The product then no longer fits the need. A small team, a three-month timeline, and automated quality gates prevent this drift. Every week produced software that worked and that the client could review. The client's domain experts corrected the course while a correction was still cheap.