voxcog: produktbeslutninger med sporbart underlag
Studioets forhold til kunden
voxcog er et produkt Torn Studio har bygget og eier en andel av. Studioet hadde ansvaret for produktledelse, arkitektur og bygging fram til overleveringen i august 2026.
Kort svar
Torn Studio drev voxcogs produktarbeid fra prototype til MVP. Hver funksjon ble planlagt som en skrevet spesifikasjon — 108 av dem ligger igjen i kodebasen — og hver retningsbeslutning ble skrevet ned med alternativene og hva valget kostet. En dreining i juni 2026 smalnet fem søyler til én pipeline.
Oppdraget
voxcog trengte å gå fra en prototype med fem parallelle søyler til et produkt med én tydelig kjerne, og trengte å gjøre det slik at begrunnelsen bak hvert valg finnes igjen når neste person leser koden.
Det som gjorde det vanskelig
- Fem jevnbyrdige søyler gjorde produktet vanskelig å demonstrere og vanskelig å beskrive på én linje, noe som er et posisjoneringsproblem før det er et byggeproblem.
- Flere parallelle arbeidsspor mot samme database gjør sekvensnummererte migrasjoner utrygge, fordi to grener hver for seg velger samme neste nummer.
- Produktet håndterer kundenes interne materiale, så personvernet måtte være på plass allerede før lansering.
Tall som lar seg telle
- 108skrevne spesifikasjoner
- Trettito aktive og syttiseks arkiverte mapper. Hver av dem bærer designvalget og trinnene, så en levert funksjon kan leses bakover.
- 3dokumenterte retningsbeslutninger
- Hver med kontekst, alternativene som ble veid og prisen for det valgte. Formatet krever at kostnaden skrives ut.
- 102databasemigrasjoner
- Tidsstemplet, med en test som feller byggingen på et duplisert eller sekvensnummerert prefiks. Regelen finnes fordi parallelle grener ellers velger samme nummer.
- 6juridiske underlag før lansering
- Behandlingsprotokoll, konsekvensvurdering, hendelsesplan, databehandleravtale, personvernerklæring og brukervilkår.
Slik ble det gjort
En skrevet spesifikasjon før hver bygging
Hver funksjon fikk sin egen mappe med designspesifikasjon og trinnvis implementeringsplan før koden ble skrevet. Da arbeidet var levert, ble mappen flyttet til arkivet, så kodebasen bærer både det som bygges nå og begrunnelsen bak det som allerede er bygget.
Beslutninger med alternativer og pris
Retningsbeslutninger ble skrevet som egne dokumenter med konteksten, alternativene som ble veid og hva det valgte alternativet kostet. Formatet tvinger fram den vanskelige setningen: hva ble dårligere av denne beslutningen.
Dreiningen ble lagt ved siden av det den erstattet
Da produktet i juni 2026 ble smalnet fra fem søyler til én lineær pipeline, ble den gamle strategien flyttet til et datert arkiv og den nye lagt ved siden av. Den som leser i dag ser begge og kan vurdere om begrunnelsen fortsatt holder.
Sporbarhet som produktets egen mekanisme
Kjeden som ble bygget speiler arbeidsmåten: hvert signal peker på sin eksakte kilde, hver innsikt på sine signaler, og nytt materiale som motsier et signal flagger alt nedstrøms som må vurderes på nytt.
Teknologi
- Next.js 16
- Supabase
- Postgres
- pgvector
- Reciprocal Rank Fusion
- Claude Sonnet 4.6
- MCP
Hva beviset rekker til
Dette viser produktledelse som legger igjen spor: beslutninger kan leses bakover og begrunnelsen finnes igjen. Det sier ingenting om hvorvidt markedet vil ha voxcog — plattformen ble overlevert før lansering, og det spørsmålet står åpent.
Grunnlag
Hva denne artikkelen hviler på — en måling vi gjorde, en datert kilde eller en beslutning vi tok og hva den kostet.
- Måling
Hvor mange funksjoner som ble planlagt skriftlig før byggingen
Måleobjekt: voxcogs planmapper
Metode: Tell mappene under plans og plans-archived i kodebasen.
Resultat: 108 mapper, 76 av dem arkivert
- Beslutning
Smalne produktet fra fem jevnbyrdige søyler til én lineær pipeline med sporbart underlag.
Hva det kostet: Intervjusystemet, som var ferdig bygget med stemme og deltakerflyt, havnet bak et funksjonsflagg og sluttet å bli solgt.
- Beslutning
Nummerer migrasjoner med tidsstempel og la en test felle byggingen på et sekvensnummer.
Hva det kostet: Versjonene lar seg ikke lenger lese som en rekkefølge på øyemål, og de eldre sekvensfilene lever videre som unntak.
Vanlige spørsmål
- Hva er en beviskjede i praksis?
- Fire ledd som peker nedover: et signal peker på sin eksakte kilde, en innsikt på sine signaler, en beslutning på sine innsikter og et prinsipp på det som har vist seg å holde. Hvert ledd bærer en lenketype og en konfidens.
- Hva skjer når nytt materiale motsier en tidligere antakelse?
- Kjeden traverseres framover og flagger hver innsikt, beslutning og prinsipp som hviler på signalet som nå er i tvil. Det som er blitt utdatert blir synlig i selve kjeden.
- Hvorfor skrive en spesifikasjon når AI likevel skriver koden?
- Spesifikasjonen er det som gjør byggingen mulig å gjennomgå. Et verktøy som får en tydelig avgrensning og en rekkefølge av steg produserer noe som kan leses og verifiseres, og mappen som blir igjen forklarer valget for neste person.
- Hvordan avgjør dere hva som skal ut av et produkt?
- Ved å skrive ned hva det koster å beholde det. Intervjusystemet var ferdig og virket, men det trakk fokus fra det som bar produktet, så det havnet bak et flagg med begrunnelsen notert.
- Kan dere drive produktarbeid for oss på samme måte?
- Ja. Arbeidsmåten er uavhengig av produktet: en skrevet spesifikasjon før hver bygging, retningsbeslutninger med alternativer og pris, og et arkiv som gjør at begrunnelsen finnes igjen når teamet byttes ut.
- Hvor mye av dette er AI-generert?
- Utkastene trekkes med AI-verktøy, og hver spesifikasjon og beslutning leses og redigeres av et menneske før den gjelder. Det som avgjør kvaliteten er avgrensningen og gjennomgangen, og den delen er fortsatt manuell.
Fortell hva du vil bygge
Tretti minutter, kostnadsfritt, og et ærlig svar på om vi er riktig studio for oppdraget.