voxcog: product decisions with a traceable trail
The studio’s relationship to the client
voxcog is a product Torn Studio built and holds a stake in. The studio ran product management, architecture and the build through to handover in August 2026.
Short answer
Torn Studio ran voxcog’s product work from prototype to MVP. Every feature was planned as a written spec — 108 of them are still in the repository — and every directional call was written down with its options and what the choice cost. A pivot in June 2026 narrowed five pillars to one pipeline.
The brief
voxcog needed to move from a prototype with five parallel pillars to a product with one clear core, and to do it so the reasoning behind each call survives for whoever reads the code next.
What made it hard
- Five co-equal pillars made the product hard to demonstrate and hard to describe in one line, which is a positioning problem before it is a build problem.
- Several parallel work streams against one database make sequentially numbered migrations unsafe, because two branches each pick the same next number.
- The product holds customers’ internal material, so data protection had to be in place before launch.
Figures a reader can count
- 108written specs in the repository
- Thirty-two active folders and seventy-six archived. Each carries the design call and the steps, so a delivered feature can be read backwards.
- 3recorded directional decisions
- Each with context, the options weighed and the price of the one chosen. The format requires the cost to be written out.
- 102database migrations
- Timestamped, with a test that fails the build on a duplicate or sequential prefix. The rule exists because parallel branches otherwise pick the same number.
- 6legal documents before launch
- Record of processing, impact assessment, breach response plan, data processing agreement, privacy policy and terms of service.
How it was done
A written spec before every build
Every feature got its own folder with a design spec and a step-by-step implementation plan before any code was written. Once delivered, the folder moved to the archive, so the repository carries both what is being built now and the reasoning behind what is already built.
Decisions with options and a price
Directional calls were written as their own documents with the context, the options weighed and what the chosen option cost. The format forces the hard sentence: what got worse because of this decision.
The pivot was filed beside what it replaced
When the product narrowed from five pillars to one linear pipeline in June 2026, the old strategy moved to a dated archive and the new one was filed next to it. Anyone reading today sees both and can judge whether the reasoning still holds.
Traceability as the product’s own mechanism
The chain that was built mirrors the way it was built: every signal points at its exact source, every insight at its signals, and new material that contradicts a signal flags everything downstream that needs revisiting.
Stack
- Next.js 16
- Supabase
- Postgres
- pgvector
- Reciprocal Rank Fusion
- Claude Sonnet 4.6
- MCP
The limits of this proof
This shows product management that leaves a trail: decisions can be read backwards and the reasoning survives. It says nothing about whether the market wants voxcog — the platform was handed over before launch, and that question is open.
Evidence
What this article rests on — a measurement we took, a dated source, or a decision we made and what it cost.
- Measurement
How many features were planned in writing before the build
Measured on: voxcog’s plan folders
Method: Count the folders under plans and plans-archived in the repository.
Result: 108 folders, 76 of them archived
- Decision
Narrow the product from five co-equal pillars to one linear pipeline with a traceable trail.
What it cost: The interview system, already finished with voice and participant flows, went behind a feature flag and stopped being sold.
- Decision
Number migrations by timestamp and let a test fail the build on a sequential number.
What it cost: Versions no longer read as an order at a glance, and the older sequential files live on as exceptions.
Common questions
- What is an evidence chain in practice?
- Four links pointing downward: a signal points at its exact source, an insight at its signals, a decision at its insights, and a principle at what has proven durable. Every link carries a type and a confidence.
- What happens when new material contradicts an earlier assumption?
- The chain is traversed forward and flags every insight, decision and principle resting on the signal now in doubt. What has gone stale becomes visible in the chain itself.
- Why write a spec when AI writes the code anyway?
- The spec is what makes the build reviewable. A tool given a clear boundary and an ordered set of steps produces something that can be read and verified, and the folder left behind explains the call to the next person.
- How do you decide what to take out of a product?
- By writing down what keeping it costs. The interview system was finished and working, but it pulled focus from what carried the product, so it went behind a flag with the reason recorded.
- Can you run product work for us the same way?
- Yes. The method is independent of the product: a written spec before every build, directional calls with options and a price, and an archive that keeps the reasoning available when the team changes.
- How much of this is AI-generated?
- Drafts are pulled with AI tooling and every spec and decision is read and edited by a person before it stands. What decides quality is the boundary and the review, and that part is still manual.
Tell us what you want to build
Thirty minutes, free of charge, and a straight answer on whether we are the right studio for it.