Reducing manufacturing flaws at a concrete furniture factory

How a quality assurance web application increases accountability and spec-adherence for Restoration Hardware's main supplier of concrete furniture.

Role: Solo designer and builder
Deliverables: Full-stack web application
Year: 2025–Present
Process: Spec-driven, AI-assisted software development
Duration: 7 months
Collaborators: Factory owner, floor manager, fabricators, and product inspectors

The human problem

No accountability or visibility into process breakdown

It is very difficult to determine exactly which step of the process led to a flaw that might only be discovered at the very end of the line.

Paper checklists may get filled out, but it was often impossible to identify when and where a product flaw occurred without a photographic paper trail.

“I have no sense of how closely they are following these steps.”
— CEO of furniture manufacturer

The physical prototype is hugely important in the approval process and referenced closely when setting up the manufacturing line, but rarely referenced after that.

A paper quality checklist beside a concrete product on the factory floor — Paper checklists existed but had **drawbacks:**
Generic, one-size-fits-all
No photo references to check during inspection
No reporting

The technology problem

Physical samples were too cumbersome to reference

A singular physical prototype existed for each product line. These were stored far from the manufacturing line and were rarely referenced.

The physical prototype is hugely important in the approval process and referenced closely when setting up the manufacturing line, but rarely referenced after that.

Over time, variation creeps into the manufacturing process and the product can drift from the original specs.

A rectangular concrete finish sample photographed against a dark background

Solution

Replace paper checklists with visual references and photo inspection capture

A Benchmarkr quality checklist with pass and fail reference images — Inspectors compare the product in front of them with pass and fail references, capture evidence, explain deviations, and leave a visible record for managers.

An inspection screen asking a worker to compare a product with a known issue — Inspectors compare the product in front of them with pass and fail references, capture evidence, explain deviations, and leave a visible record for managers.

Define processes with pass and fail reference photos

A central question was how to store the process steps that would define how to manufacture a given SKU.

Defining the process on the SKU itself proved to be too limiting, because multiple SKUs might share the same process.

The Fire Table QC Process template made of seven configurable steps — Selecting Step 4 opens its configuration drawer. The companion views show the full process template and the inspection tasks, reference imagery, attachments, and completion settings stored inside a reusable process step.

Selecting Step 4 opens its configuration drawer. The companion views show the full process template and the inspection tasks, reference imagery, attachments, and completion settings stored inside a reusable process step.

Connect each SKU to a process template

Once processes could stand on their own, each SKU only needed to reference the process used to manufacture it.

This kept the quality definition consistent across variations in size, collection, and color without duplicating the same process on every SKU.

A Benchmarkr SKU catalog showing product collections, dimensions, colors, and statuses — Individual SKUs link to a reusable process instead of duplicating the same quality definition across every size, collection, and color variation.

Exception handling

Flagged products sent to Needs Review queue

When an inspector detects a defect, Benchmarkr routes that serialized product out of the normal flow and into a shared Needs Review queue. Managers can see which products need attention, how many issues were found, and where each unit sits in its process.

From there, they can clear the flag, send the product back to an earlier step for rework, or reject it outright and remove it from production.

The Benchmarkr Needs Review queue listing flagged products, their processes, issue counts, and review dates — The open queue turns a detected defect into an explicit management decision: clear it, route the product back for rework, or reject it and end its production run.

Pilot outcomes and learnings

What the pilot accomplished—and what it taught me

This was a focused pilot, not a factory-wide rollout. A working bilingual product was tested with factory leadership and floor users on one fire-table SKU. It showed how an approved standard, inspection evidence, and a management decision could stay connected to one serialized product. Measurable quality, time, and cost outcomes are still to be established.

What it accomplished

Put approved pass and fail references beside photo capture at the inspector’s point of work.
Connected reusable processes to individual SKUs and preserved the evidence history for each product.
Gave managers a live Needs Review workflow with step-level context instead of an isolated paper record.

What I learned

Buyers and practitioners hold different kinds of truth; floor managers needed to be part of discovery earlier.
Flexibility belongs at the Step and Task level, where the work varies—not in rigid process types.
Factory conditions shape adoption: an iPad fit inspectors carrying clipboards, but not fabricators working in heavy gloves.

What comes next

Broader use needs to show whether issues are caught before more labor or material is added, how quickly managers make review decisions, and which process Steps produce recurring issues.