Work / 05All work

Gather

A blockchain-backed product-provenance workflow for a furniture company.

Built
A full-stack internal system for creating digital product passports and moving furniture through a provenance workflow.
Reality taught me
The blockchain was not the difficult part. The real challenge was translating an operational process into software a team could use to create and maintain trustworthy provenance data.
Role
Technical product consultant
Status
Delivered for pilot
Period
2024 — 2025
System
Next.js · Clerk · MongoDB · Base
Delivered workflowFurniture provenance from source record to customer passport
01 · InputMaterials & makersCertifications, suppliers and production evidence
02 · OperateProduction stagesInternal workflow and product status management
03 · AnchorBase recordsSelected provenance data anchored on-chain
04 · PublishProduct passportDurable, customer-readable provenance history

Gather wanted each furniture product to carry a durable, transparent record of its materials, makers, certifications and production journey. The starting point was a broad provenance concept, not a settled software specification.

The problem

A digital product passport only becomes trustworthy if the team can create and maintain the underlying record during normal operations. Gather needed to collect evidence from suppliers and makers, move products through production stages, correct records when necessary and publish a customer-readable history.

I worked directly with the team to understand where information entered the process, which stages mattered internally and what a customer should eventually see.

What I built

I translated that workflow into a full-stack system with:

  • an internal application for creating digital product passports;
  • structured records for materials, makers and certifications;
  • a workflow for moving products through production stages;
  • customer-readable provenance views;
  • authentication and access control with Clerk;
  • MongoDB-backed operational records;
  • selected Base records for durable provenance.

The customer application was built with Next.js and delivered for a pilot.

Where reality disagreed

The early concept placed blockchain near the centre of the product. Working through the real production process revealed that most of the difficult work happened elsewhere: assembling evidence, deciding who could update it, correcting records and making the workflow usable by the team.

The ledger could provide a durable anchor for selected facts. It could not make the operational data accurate or persuade people to maintain it.

The durable record mattered, but only after the day-to-day workflow made it practical to create accurate provenance data.

How I investigated it

The evidence came from customer discovery, workflow mapping and successive prototypes with Gather’s team. I traced how a product moved from materials and makers through production to a published passport, then tested where the proposed data model or interface failed to match that process.

Experience from Origin Thread also provided a concrete comparison. That founder product had already exposed the gap between an interesting provenance idea and a system a business could operate repeatedly.

What changed

The architecture separated operational records from the smaller set of facts worth anchoring on-chain. The internal workflow became the core of the product. Blockchain became one component serving provenance, rather than the interface or organising principle for every action.

The product scope also shifted towards the people maintaining the record: structured inputs, production status and access control came before the customer-facing passport.

What I learned

In this system, trust came from the combination of a usable operational workflow and a durable published record. The technology that made provenance tamper-resistant was secondary to the process that made the data accurate.

This changed how I approach customer engineering: map who creates and corrects the data before choosing where that data should ultimately live.

Read first

See how real failures became an evaluation and architecture system.

Read Crispin