Tessom: every upholstery offcut gets a next piece

Mide — Sun, 04 Oct 2026 21:00:40 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange.

What I Built

Tessom is a marketplace and workshop system for upholstery fabric offcuts.

Upholstery shops regularly cut fabric for a sofa, chair or other job and end up with usable material left over. Some pieces are large, valuable and completely unique, but they usually sit in a corner because listing them is harder than it sounds.

An odd-shaped remnant can have flaws, a repeating pattern, a fixed direction and limited usable space. On top of that, the fabric may still belong to the original client, which means the workshop can't simply sell it.

Tessom handles that whole process.

Each remnant stores its dimensions, pattern repeat, direction, flaws, ownership status and fabric photo. From that information, Tessom works out what can actually be made from the remaining material.

Instead of showing generic products, the shop shows cuts that really fit the available fabric, with their actual placement and price drawn against the real remnant.

Offers are calculated on every read rather than stored. If the usable area changes, the available products change with it, so stale offers aren't left behind.

When someone places an order, Tessom locks the exact area of fabric being used. That means the same part of a remnant can't be sold twice.

I tested this directly by sending two buyers after the same cut at almost exactly the same time. One request succeeded with HTTP 200. The other received HTTP 409.

The second browser updated automatically through a Sanity listener without needing a reload.

Ownership consent is also part of the workflow rather than a checkbox added on top. If a remnant belongs to a client, the owner must approve it before the workshop can sell anything from it.

From there, the workshop moves an order through its actual production stages:

Awaiting consent → Allocated → Cut → Sewn → Shipped

Tessom is aimed at small upholstery workshops and customers who might want a one-off cushion, bench pad, tote or similar product made from fabric that already exists.

Anyone with leftover fabric can offer it at /submit: size, a photo, and optional details. The offer is stored on a private path with the contact encrypted, and nothing is listed until the workshop reviews it.

In /workshop, the same Groq selvage reader pre-fills the fabric name, maker, repeat and direction from the offer's photo. The workshop checks the fields, sets a value and accepts it, and the fabric enters the consent workflow under a generic owner name, never the submitter's name or email.

The submitter gets a private status page.

What's real

The live project includes:

remnant and allocation data stored in Sanity
owner consent
deterministic cut fitting
order creation
concurrency and conflict handling
encrypted buyer contact data
workflow progression
live Sanity updates
selvage extraction with vision
workshop management
production stages from allocation through shipping

The remnants, owners and makers in the demo are fictional sample data. The fabric photography comes from Unsplash.

Payments and transactional emails aren't implemented. After an order is placed, the workshop would currently contact the buyer manually.

The offer engine itself doesn't use AI. Rectangle fitting and allocation are deterministic because there was no reason to introduce a model into something that can be calculated and independently verified.

The AI-assisted part is the selvage reader inside Studio.

Demo

Live project: https://tessom.midelabs.xyz

You don't need an account.

No sign-up.

Open /shop, pick a fabric and order a cut with any name and email.

Open /workshop, enter the PIN tessom-judges-2026 and move the order to cut, sewn and shipped.

To try the intake side, open /submit, offer a fabric with a photo, then find it under Offered fabric in /workshop. Press Read selvage photo, then Accept.

On the board, press Copy owner link on an Awaiting consent card to try the owner's approve or decline page.

Code

Repository: https://github.com/mystiquemide/tessom

The README maps the main judging criteria to their implementation and includes the tests behind the failure cases I tried to break.

The project currently has 302 tests.

How I Used Sanity

Sanity is the source of truth for the inventory, ownership, allocations, orders and workshop state.

Structured remnants

Each remnant records the information the offer engine needs to make a real decision:

dimensions
pattern repeat
fabric direction
flaws
ownership
image
existing allocations
current workflow state

The offer engine reads that structured content and fits product templates into the remaining usable space.

Offers aren't persisted as documents. They're derived from the current remnant state every time they're requested.

That means an offer can't stay visible after another customer has consumed the area it depended on.

Allocation and concurrency

The remnant owns its allocations, so the sold area lives in one authoritative place.

When an order is placed, the order route writes the new allocation using the remnant's Sanity revision.

If two buyers attempt to reserve the same area at the same time, only one revision can win.

The other request fails instead of silently creating a double booking.

I also kept the allocation guard and area-lock validation based on the same rules so the two checks can't disagree about whether a cut is available.

Privacy

Orders use private document paths, and buyer contact details are encrypted before being stored.

The public Sanity dataset can expose the inventory needed by the storefront without exposing buyer information.

Sanity Workflows

Consent and production aren't represented as loose status strings.

They move through real workflow stages:

Awaiting consent → Allocated → Cut → Sewn → Shipped

Sanity Workflows 0.36 is still early access and doesn't provide the background runtime I needed, so every application route that mutates an order also advances the corresponding workflow itself.

Inside Studio, the official Workflows plugin exposes the live instances in both table and board views.

Studio selvage reader

I also built a custom Studio action called Read selvage photo.

A user can open a remnant and run the tool against its fabric image.

The server fetches the image from Sanity and sends the image bytes to Groq Vision.

It attempts to extract:

printed fabric name
maker
pattern repeat
direction
supporting evidence
confidence

The result is only a suggestion.

Nothing is written back to the remnant until the user presses Apply suggestions.

If the photo doesn't contain readable selvage information, the tool returns null values rather than inventing an answer.

Live updates

The storefront listens for relevant Sanity changes.

When an allocation changes, another open browser can update its available cuts without reloading the page.

Getting this working required both Sanity CORS configuration and adding the Sanity API host to the application's CSP connect-src.

My Build Process

I started Tessom in Codex and finished it in Claude Code.

Rather than asking either tool to build the entire product in one shot, I kept a written task list and moved through it one task at a time.

Each task had three basic requirements:

implement the scoped change
add or update tests
pass the gate before moving on

Changing the idea

Tessom wasn't the idea I started the challenge with.

My first concept was an agent that sold to EU buyers. I dropped it and replaced it on October 2 after validating the offcut problem.

One detail changed the project significantly: large remnants often still belong to the customer whose furniture was upholstered.

That made consent one of the core system states rather than a simple permission field.

I also made an early decision to keep the offer engine deterministic. Fitting known shapes into known dimensions doesn't need an LLM, and deterministic logic made the result much easier to test.

Building the backend

The first major Codex prompt was essentially:

Fan out multiple sub-agents to complete the remaining backend tasks. Inspect the code first, stay within your assigned scope, run your own checks, audit your work and report back. Do not accept an agent's work simply because it claims the task is complete. Verify the implementation and evidence yourself. When you reach the frontend, stop.

That final instruction mattered.

The agents built the project scaffold, schemas, offer engine, order route and workflow layer, then stopped before visual design so I could choose the direction myself.

I carried the plan and a small project memory file between Codex and Claude Code so a new session didn't need the architecture explained again.

Review loops

The review passes ended up improving the project more than the initial generation.

After each backend wave, I ran fresh agents against the implementation instead of asking the agent that wrote the code to approve its own work.

The test count moved from:

13 → 69 → 80 → 97 → 137 → and 302 by the end

Those reviews caught issues that would otherwise have appeared during the demo, including:

stale shipping decisions
buyer contact information being readable through the public dataset
replayed keyed orders that weren't actually idempotent
streamed request bodies bypassing the intended size limit
a Sanity consistency race
overlapping cut-plan labels
route-specific layout mistakes
missing production configuration

For the frontend, I used separate audits for design, page planning, UX, conversion, microcopy and hackathon judging.

The microcopy review alone changed around 20 strings and forced the product to settle on consistent language around cuts, offcuts and panels.

The hostile judge-style review is also what pushed me to add live Sanity updates and the Vision tool inside Studio.

Intake

I also added a public /submit form and tested it end to end in a throwaway Sanity dataset before touching production.

An offer is stored on a private submissions. path with an encrypted contact, so the public dataset returns none of it. The workshop reviews it in a panel on the board, can run the same selvage reader on the offer's photo, and accepts it to create the owner and remnant and start the consent workflow.

The owner is created under a generic name such as Client 3fa9, so the submitter's real name and email never reach the public data.

Where the models got stuck

The build wasn't clean.

I initially asked for GPT-5.6 Luna Max sub-agents, but an orchestration skill interpreted the request differently and started another model.

I stopped the run, corrected the model selection and restarted the same work lanes without throwing away the files that were already valid.

I also caught several cases where the models followed an incomplete specification too literally.

For example, the initial page plan forgot the logo and favicon, so the generated navigation had neither.

The workshop navigation also showed a link back to the workshop while the user was already on that page, and a shared footer leaked into routes where it didn't belong.

The final fix was to stop patching each page independently and move those rules into the layout itself.

Things that actually broke

A few implementation bugs shaped the final architecture.

Groq Vision initially worked with only one of the models I tested, and remote Sanity image URLs returned HTTP 403. The working implementation fetches the Sanity image server-side and sends the image as base64 data.

The first generated offers were also priced too low to survive the margin floor because my templates didn't include labour minutes and fill costs.

When four products overlapped on the same fabric, every cut-plan label rendered at once and became unreadable. Labels now appear only for the active offer.

Reseeding also failed because Sanity documents with active references couldn't simply be deleted. The working reset order became: seed the base data, remove dependent orders and workflow instances, then bootstrap again.

One CSS rule caused a particularly annoying bug:

margin: 0

It was applied globally to headings outside Tailwind's layers and silently overrode spacing utilities across the interface.

The first production deployment failed too. The Vercel project had no framework preset, so the build system looked for a dist output directory that didn't exist.

Those failures are also why I kept a short project memory file containing decisions and known gotchas. When I moved between sessions and tools, the next agent could continue from the actual state of the build rather than rediscovering the same problems.

Sanity Project Details

Project ID:

59g78icb

Dataset:

production

The dataset has public read access for the storefront content required by the demo.

Example query:

View remnant data

curl -s -G 'https://59g78icb.api.sanity.io/v2025-02-19/data/query/production' \
  --data-urlencode 'query=*[_type=="sanity.workflow.instance"]{_id,currentStage}'

DEV Community: Mide