# quiXzoom Builder Sessions — Förslag **Beslutsunderlag för Erik Svensson, CEO LandveX AB** **Datum:** 15 juni 2026 **Författare:** Kommunikationsstrateg (intern) --- ## Sammanfattning quiXzoom konfronterar tekniska problem som är genuint svåra och genuint intressanta för de byggare som definierat vad moderna system är. Det vore ett misstag att bemöta det intresset med marknadsföring. Det rätta svaret är att öppna dörrarna och prata teknik. Det här dokumentet föreslår **quiXzoom Builder Sessions** — en öppen, månatlig seminarieserie i online-format där LandveX bjuder in tekniska opinionsbildare att diskutera exakt de problem vi faktiskt har. Ingen sponsorskylt. Ingen produkt-pitch. Teknisk substans. Insatsen är liten. Potentiell avkastningen är stor: credibilitet, rekrytering, nätverkseffekter i communities vi annars inte når. --- ## 1. Koncept och namn ### Namn och tagline **quiXzoom Builder Sessions** *"The physical world has a data problem. Help us fix it."* Alternativa undertitlar per session kan varieras (t.ex. *"When nodes are humans"*, *"Coverage without a denominator"*), men det övergripande varumärket hålls konsekvent. ### Format - **Frekvens:** En session per månad - **Längd:** 60–90 minuter - **Upplägg:** 30–40 min djupintervju/samtal → 20–30 min publik Q&A → 10 min valfri "office hours" (öppen kanal, oinspelade) - **Kanal:** YouTube Live (primär) + simultanstream via Riverside/StreamYard för inspelning i studiokvalitet - **Tillgänglighet:** Alltid öppet, alltid gratis, alltid publik inspelning - **Språk:** Engelska (primärt), svenska versioner sammanfattas i blogg ### Varför detta är tekniskt legitimt quiXzoom är inte ett CRUD-API med en mobilapp. Det är ett distribuerat system där varje nod är en människa med en telefon — rörlig, periodvis offline, economically motivated och geographically biased. Det skapar en systemmodell med reella constraints: **Offline-first på noder som rör sig.** En Zoomer fotograferar en fasad i ett område med dålig täckning. Uppdraget synkas när det finns connectivity. Vad händer om uppdraget redan tilldelats någon annan? Hur löser vi konflikter utan att straffa Zoomers för infrastrukturens misslyckanden? **Eventual consistency på geografisk data.** Vår coverage-karta är inte en sanningstabell — den är en probabilistisk approximation av vad som fotograferats, när, av vem, och med vilken bildkvalitet. Det är ett CRDT-problem med rörliga polygoner och mänskliga felkällor inbakade. **AI-klassificering med asymmetrisk felkostnad.** False positive (godkänner dålig bild) → vi levererar skräp till kund. False negative (avvisar bra bild) → Zoomern slutar använda appen. De tradeoffs är inte lika, och de påverkar olika stakeholders med motstående intressen. Det är ett produktionsproblem, inte ett Kaggle-problem. **Betalningsidentitet för gig-workers i 20+ länder.** Stripe Connect i nordiska länder är relativt friktionsfritt. Stripe Connect i Nigeria, Filippinerna eller Colombia är ett annat djur. KYC, banking access, skattskyldighet och payout-latens är inte "integration issues" — de är affärslogik. **Coverage-mätning utan denominator.** Hur vet man vad man missat? Denominatorn (allt som *borde* fotograferas) är inte känt. Vi arbetar med statistisk sampling, Zoomer-distribution som proxy för coverage, och SLA-garantier på polygoner vi inte kan garantera fullt ut. Dessa är äkta problem. De flesta byggare på vår lista har tänkt på minst ett av dem i sina egna system. Det är anledningen till att de kommer vilja delta. --- ## 2. Fem tematiska spår ### Spår 1: Distribuerade system i fält **"When nodes are humans"** **Frågeställning:** Vad händer när du designar ett distribuerat system och varje nod är en människa med ekonomiska incitament, intermittent connectivity och fri vilja att sluta använda systemet? Klassisk distribuerad systemteori antar noder som är deterministic (givet input, givet output), alltid-på eller med väldefinierade failure modes, och utan agency. Zoomers bryter alla tre antagandena. Hur applicerar klassisk teori — CRDTs, vector clocks, quorum reads, partition tolerance — på ett system där noderna ibland väljer att inte synca för att de tappat motivation? **Lämpliga deltagare:** - Martin Kleppmann (CRDTs, Designing Data-Intensive Applications) - Bryan Cantrill (systemdesign, observability, Oxide Computer) - Brendan Gregg (performance engineering, BPF, systembeteende under last) - D. Richard Hipp (SQLite — en databas designad för offline-first, embedded use) - Jon Gjengset (Rust, concurrent systems, djupa dives i systemdesign) - Jeff Preshing (concurrency primitives, lock-free programming) - Thorsten Ball (systemförståelse, "Writing an Interpreter in Go") - Andrew Gallant (ripgrep — extremt väloptimerade verkliga system) **Konkret samtalsämne:** *"SQLite som Zoomer-local store: är WAL-mode rätt val för offline-first sync i en app där noden rör sig och vi inte kontrollerar connectivity?"* — med Hipp och Kleppmann i samma samtal vore detta exceptionellt. **Format:** Tvåpersonerssamtal (Kleppmann + Hipp som drömpar), eller Cantrill ensam med publik Q&A som driver innehållet. --- ### Spår 2: AI-granskning i produktion **"The cost of being wrong"** **Frågeställning:** Hur designar man en CV-pipeline i produktion när false positives kostar pengar och false negatives kostar användare — och de tradeoffs inte är lika? De flesta AI-demos optimerar för accuracy på ett benchmark. Vi optimerar för en multivariat funktion: bildkvalitet × Zoomer-retention × kundvärde × granskningstid. Det är ett reinforcement learning-problem maskerat som ett klassificeringsproblem, och vi kör det i produktion med verkliga människors inkomst som utfall. **Lämpliga deltagare:** - Andrej Karpathy (neural nets i produktion, Tesla Autopilot-erfarenhet) - Georgi Gerganov (llama.cpp — lokal inference, edge deployment) - Jeremy Howard (fast.ai, practical deep learning, transfer learning) - Tim Dettmers (QLoRA, kvantisering — relevant för edge-inference på mobila enheter) - Jay Alammar (visualisering och förklaring av transformer-beteenden) - Harrison Chase (LangChain — AI-pipelines i produktion) - Abubakar Abid (Gradio, ML-demos, snabb prototyping) **Konkret samtalsämne:** *"Kan vi träna en lightweight klassificerare som kör on-device (iOS/Android) och pre-screener bilder innan de laddas upp? Vad är tradeoffs mot server-side granskning med ett större modell?"* — direkt relevant för Gerganov och Dettmers. **Format:** Solo-djupintervju med Karpathy (om möjligt — hög svarsfrekvens osannolik men värd försöket), eller panel med Howard + Abid om praktisk ML-pipeline. --- ### Spår 3: Betalningsinfrastruktur för gig-economy **"Money is hard. Cross-border money is harder."** **Frågeställning:** Hur bygger man ett betalningssystem som fungerar för gig-workers i 20+ länder, utan att KYC-friktion dödar onboarding, och utan att skattskyldighetshantering blir en heltidstjänst? Stripe Connect är inte en knapp. Det är ett jurisdiktionsproblem, ett identitetsproblem och ett tillitnsproblem. Bakom API:n finns beslut om vilka länder man stödjer, vilken nivå av KYC man kräver, hur man hanterar disputes när arbetet är "fotografering av en fasad" och inte "leverans av en produkt". **Lämpliga deltagare:** - Guillermo Rauch (Vercel — skalad finansiell infrastruktur för developers) - Tom Preston-Werner (GitHub — tidigt gig-economy-liknande modeller för open source) - David Heinemeier Hansson (Rails, HEY — opinionated om enkelhet i systemdesign) - Isaac Z. Schlueter (npm — distribuerad developer-ekonomi, paketbetalningar) - Marek Majkowski (Cloudflare — distribuerad infrastruktur, edge payments-adjacent) - Mitchell Hashimoto (Terraform/Ghostty — infra-as-code, automatisering av repetitiva system) **Konkret samtalsämne:** *"Stripe Connect Custom vs Express vs Standard för gig-workers: vilken modell ger bäst konvertering vid onboarding, och vad förlorar man på varje val?"* — pragmatisk, specifik, ingen vet svaret perfekt. **Format:** Fireside chat med DHH om design philosophy (han har starka åsikter om betaltjänster efter HEY-lanseringen), eller djupare teknisk session med Rauch om infra. --- ### Spår 4: Coverage-mätning och geografisk sampling **"How do you know what you've missed?"** **Frågeställning:** Hur mäter man täckning av något man inte vet storleken på? Och hur ger man kunder SLA-garantier på data man samlar in opportunistiskt? Denominatorn för vår coverage-karta är okänd. Vi vet vad vi fotograferat. Vi vet inte hur mycket som *borde* fotograferas. Vår Zoomer-distribution är snedvriden mot städer, mot dagtid, mot områden med bättre ersättning. Hur identifierar man och kompenserar för den bias utan att introducera nya fel? **Lämpliga deltagare:** - Simon Willison (Datasette — datautforskning, transparens i datapipelines) - BurntSushi (ripgrep/regex — extremt noggrant tänkande om edge cases och korrekthet) - Casey Muratori (performance engineering — denominator-tänkande, mätbarhet) - Jeff Preshing (statistisk korrekthet i systemmätning) - Filippo Valsorda (kryptografisk korrekthet — tangerar sampling-teori) - Brendan Gregg (perf/BPF — mätning av komplexa system) **Konkret samtalsämne:** *"Vi har en polygon (ett postnummer). Vi har fotograferat 40% av adresserna i den. Kan vi med statistisk säkerhet säga att coverage är '40%' och sälja ett SLA på det?"* — äkta fråga utan enkelt svar. **Format:** Workshop-format med Simon Willison som facilitator — han är utmärkt på att offentligt utforska problem han inte har svaret på. --- ### Spår 5: Open source som affärsstrategi **"Give away the network, sell the data"** **Frågeställning:** Vilka delar av quiXzoom borde vara open source — och varför? Är det möjligt att bygga community runt ett system vars vallgrav är ett levande Zoomer-nätverk? quiXzoom säljer inte mjukvara. Vi säljer datan som nätverket producerar. Det öppnar en möjlighet: vad händer om vi open sourcear plattforms-infrastrukturen men behåller datanätverket closed? Är det ett hållbart strategival, och vad kan vi lära av Redis, SQLite, Svelte och Gitea? **Lämpliga deltagare:** - Antirez (Redis — kärninfra OSS, kommersiell layer ovanpå) - Armin Ronacher (Flask — det pragmatiska OSS-projektet som ingen monetariserar) - Rich Harris (Svelte — byggt i offentligheten, finansierat av Vercel) - Evan You (Vue/Vite — community-driven med sponsor-modell) - Kailash Nadh (Listmonk — solo-byggare, kompromisslöst OSS) - DHH (Rails — OSS som konkurrensmedel för konsultverksamhet → produkt) - Lunny Xiao (Gitea — fork-dynamics, community governance) - Graydon Hoare (Rust — language design + community + kommersiella överväganden) **Konkret samtalsämne:** *"Antirez open sourcade Redismodule-API:t men behöll Redis Cluster proprietärt ett tag. Vad var det beslutet värt i community-tillit vs kommersiell kontroll?"* — en specifik historisk fråga som öppnar en bredare diskussion. **Format:** Panelsamtal med Antirez + Rich Harris (båda opinionated, kontrasterande stilar — OSS som konst vs OSS som strategiverktyg). --- ## 3. Individuella profiler för 18 nyckelpersoner ### 1. Martin Kleppmann **Vem:** Forskare och författare till *Designing Data-Intensive Applications* (O'Reilly), skapare av Automerge CRDT-biblioteket; den person som lärt fler ingenjörer distributed systems än kanske någon annan levande författare. **Varför quiXzoom är relevant för honom:** Kleppmanns forskning handlar om hur man håller data konsistent när noder är oberoende och syncar asynkront. quiXzoom är ett fälttest av hans teorier med en twist han inte designat för: noderna har ekonomiska incitament och kan rationellt välja att inte synca. Det är en ny failure mode för CRDTs. **Hur man når honom:** Akademisk e-post (cam.ac.uk), Twitter/X (@martinkl, aktiv), konferenser (StrangeLoop, QCon). Han svarar på substantiella tekniska frågor — referera till specifika avsnitt i DDIA. **Spår/format:** Spår 1, djupintervju + whiteboard-session (virtual). **Outreach-meddelande:** > "Martin — vi driver quiXzoom, en crowdsourcing-plattform för fältdata där varje nod är en människa med en telefon och ekonomiska incitament. Vi har ett CRDT-problem du förmodligen inte sett: noder som rationellt väljer att inte synca för att de tappat motivation. Kapitel 9 i DDIA täcker nästan det här — men inte riktigt. Vi vill bjuda in dig till quiXzoom Builder Sessions för ett 60-minuters samtal om vad distributed systems-teori missar när noderna har fri vilja. Ingen pitch, bara teknik." --- ### 2. Bryan Cantrill **Vem:** CTO på Oxide Computer, skapare av DTrace, veteran från Sun Microsystems och Joyent; känd för att kombinera djup systemkunskap med exceptionell kommunikationsförmåga och starka åsikter om hur system borde designas. **Varför quiXzoom är relevant för honom:** Cantrill har byggt observability-verktyg för komplexa distribuerade system och har en stark uppfattning om vad som gör system *förstbara*. quiXzoom har ett observability-problem som är unikt: noderna (Zoomers) rapporterar inte sin egen hälsa på samma sätt som en server gör. Hur debuggar man ett system vars noder är offline när du vill fråga dem? **Hur man når honom:** Twitter/X (@bcantrill, mycket aktiv), YouTube-intervjuer, konferenser (Systems We Love). Uppskattar direkthet och teknisk specificitet. **Spår/format:** Spår 1, solo-djupintervju. Han driver gärna samtalet själv — ge honom utrymme. **Outreach-meddelande:** > "Bryan — quiXzoom har ett observability-problem du förmodligen hittar intressant: våra 'noder' är Zoomers med telefoner som är offline när vi vill fråga dem om sin hälsostatus. DTrace ger dig synlighet i vad ett OS gör; vad gör du när nodens 'OS' är en människa som inte svarar på ping? Vi vill ha dig till Builder Sessions för ett samtal om vad observability ens betyder i ett system med mänskliga noder. Inget keynote-format — en faktisk teknisk diskussion." --- ### 3. Brendan Gregg **Vem:** Senior performance engineer, skapare av flame graphs, BPF-expert och författare till *Systems Performance* (Pearson); den person som i princip definierat modern Linux performance engineering. **Varför quiXzoom är relevant för honom:** Gregg tänker på system i termer av vad som faktiskt händer under ytan, inte vad man tror händer. quiXzoom har en latency-profil som är ovanlig: end-to-end-latensen för ett "uppdrag" kan vara timmar (Zoomer tar bild offline, syncar senare, AI granskar, kund notifieras). Hur mäter man performance i ett system med den tidsSkalan? **Hur man når honom:** Twitter/X (@brendangregg), LinkedIn (aktiv), konferenser (USENIX LISA). Svarar på välformulerade tekniska frågor. **Spår/format:** Spår 1 eller Spår 4 (mätning), djupintervju. **Outreach-meddelande:** > "Brendan — vi har ett performance-mätningsproblem du förmodligen inte sett i exakt den här formen: hur gör man en latency-analys av ett system vars end-to-end-latens kan vara 4 timmar, och vars kritiska path inkluderar en människa med en telefon som kanske är på lunchen? Flame graphs hjälper oss för server-sidan — men vad gör man för den mänskliga noden? Vill du diskutera det här i quiXzoom Builder Sessions? Ingen marknadsföring, bara ett genuint svårt mätningsproblem." --- ### 4. Andrej Karpathy **Vem:** Grundare av Eureka Labs, tidigare Director of AI på Tesla (Autopilot), tidigare OpenAI; känd för exceptionellt pedagogiska förklaringar av neural networks och djup praktisk erfarenhet av AI i produktion på verkliga system. **Varför quiXzoom är relevant för honom:** Karpathy har byggt CV-system för verkliga fordon i verkliga förhållanden — exakt den typen av adversarial, uncontrolled input-miljö vi möter. Han förstår asymmetrin i felkostnad (Tesla: false negative = olycka; false positive = obehag) och vad det gör med systemdesign. quiXzoom har samma asymmetri, lägre stakes men samma principiella avvägning. **Hur man når honom:** Twitter/X (@karpathy, extremt aktiv), YouTube. Han är selective men svarar på tekniskt substantiella inlägg. Referera till specifika delar av hans arbete. **Spår/format:** Spår 2, solo-djupintervju. Hög svårighet att boka men hög avkastning om det lyckas. **Outreach-meddelande:** > "Andrej — vi kör en CV-pipeline i produktion där false positive (godkänner dålig bild) kostar kundvärde, och false negative (avvisar bra bild) kostar Zoomer-retention. Det liknar det du beskrev om Autopilot-tradeoffs i din Stanford-föreläsning — asymmetrisk felkostnad med motstående stakeholders. Vore det intressant att diskutera hur man designar runt det i quiXzoom Builder Sessions? Vi kan göra det maximalt tekniskt och minimalt marknadsföring." --- ### 5. Georgi Gerganov **Vem:** Skapare av llama.cpp, whisper.cpp och ggml — de mest inflytelserika open source-projekten för lokal LLM-inference; har ensam förändrat vad som är möjligt att köra utan moln. **Varför quiXzoom är relevant för honom:** Vi kör AI-bildgranskning server-side idag. Men det optimala systemet kör en lightweight klassificerare on-device för pre-screening — exakt det problem Gerganov löser för språkmodeller. Han har tänkt djupt på kvantisering, model compression och edge deployment. quiXzoom är ett konkret use case för hans verktyg. **Hur man når honom:** GitHub (@ggerganov, mycket aktiv), Twitter/X (@ggerganov). Han är en builder som föredrar teknisk konversation framför hype. **Spår/format:** Spår 2, teknisk djupdyk om edge inference. **Outreach-meddelande:** > "Georgi — vi granskar Zoomer-bilder server-side men funderar på om vi kan pre-screena on-device med en lightweight modell (MobileNetV3-klass, kvantiserad). llama.cpp-arkitekturen för attention är uppenbar — men vad är rätt approach för CNN-klassificerare på ARM (iOS/Android) idag, med fokus på minne och batteripåverkan? Vill du diskutera det här i ett öppet Builder Session-format? Det är ett genuint problem vi inte har svaret på." --- ### 6. Jeremy Howard **Vem:** Grundare av fast.ai, skapare av ULMFiT (transfer learning för NLP), före detta president på Kaggle; känd för att demokratisera praktisk deep learning och för att ha rätt om saker innan konsensus hunnit ifatt. **Varför quiXzoom är relevant för honom:** Howard är besatt av praktisk ML — hur man faktiskt tränar modeller som fungerar i produktion med begränsad data och begränsade resurser. quiXzoom har exakt det problemet: vi har bilddata från Zoomers, men distribuerad och potentiellt bias-rik (stadsmiljöer överrepresenterade, vissa väderförhållanden saknas). Transfer learning och data augmentation är centrala för oss. **Hur man redan honom:** Twitter/X (@jeremyphoward, aktiv), fast.ai-forum, konferenser. Han är generös med sin tid mot projekt han tycker är genuint intressanta. **Spår/format:** Spår 2, praktisk ML-session med fokus på träningspipeline. **Outreach-meddelande:** > "Jeremy — vi tränar en bildklassificerare för fasadskador men kämpar med representativitetsproblem: vårt Zoomer-nätverk fotograferar mer Stockholm och Göteborg än glesbygd, fler soliga dagar än regniga. Klassisk data augmentation hjälper — men hur hanterar man distributional shift när denominatorn är okänd? Det är ett fast.ai-problem mer än ett akademiskt ML-problem. Vill du dissekera det här i ett öppet Builder Session?" --- ### 7. Simon Willison **Vem:** Skapare av Datasette och Django (med Adrian Holovaty), aktiv bloggare och offentlig tänkare om data journalism, SQLite i oväntade sammanhang, och AI-verktyg för dataanalys. **Varför quiXzoom är relevant för honom:** Willison har byggt Datasette för att göra datautforskning transparent och delbar. quiXzoom har ett datasynlighets-problem: vi har coverage-data som är genuint intressant för kommuner, journalister och forskare — men hur exponerar man det på ett sätt som är explorativt snarare än ett dashboard? Han har tänkt mer på det problemet än de flesta. **Hur man når honom:** Twitter/X (@simonw, extremt aktiv), blogg (simonwillison.net), GitHub (@simonw). Svarar på nästan allt om det är substantiellt. **Spår/format:** Spår 4, workshop-format där han faciliterar en utforskning av coverage-problemet live. **Outreach-meddelande:** > "Simon — vi har ett dataset som beskriver vad vi *har* fotograferat av Sverige, men inte vad vi *borde* fotografera. Att kommunicera coverage till kunder (kommuner, försäkringsbolag) utan att ljuga om vad vi inte vet är svårt. Du har tänkt mer på hur man presenterar dataunsäkerhet transparent — med Datasette och i din data journalism — än nästan någon annan. Vill du hjälpa oss tänka igenom det live i ett Builder Session? Ingen pitch, bara utforskning." --- ### 8. Antirez (Salvatore Sanfilippo) **Vem:** Skapare av Redis; en av de mest inflytelserika ensamma byggarna i open source-historien; känd för att ha designat ett system av extrem enkelhet med extrem genomslagskraft. **Varför quiXzoom är relevant för honom:** Antirez har navigerat exakt den spänning vi funderar på: hur mycket ska man open sourca, vad behåller man, och hur påverkar det community-tillit? Redis open sourcades helt, vilket skapade ett globalt community — men också konkurrenter (AWS ElastiCache) som tog intäkterna. quiXzoom ställer sig samma fråga med en annorlunda produkt. **Hur man når honom:** Twitter/X (@antirez, sporadisk men svarar), GitHub (@antirez). Han värderar integritet och äkthet — pitcha aldrig, fråga alltid. **Spår/format:** Spår 5, fireside chat om OSS-strategi. **Outreach-meddelande:** > "Salvatore — vi bygger quiXzoom och funderar seriöst på att open sourca plattformsinfrastrukturen men behålla datanätverket closed. Du vet bättre än de flesta vad som händer när man open sourcear kärnan och en cloud-leverantör tar ditt community. Vad skulle du göra annorlunda? Det är en fråga vi inte har svaret på, och vi tror att svaret är bättre om det diskuteras offentligt. Vill du delta i ett Builder Session om just det?" --- ### 9. David Heinemeier Hansson (DHH) **Vem:** Skapare av Ruby on Rails, grundare av Basecamp/HEY; känd för starka och välformulerade åsikter om mjukvaruutveckling, enkelhet, och hur startup-kultur ofta väljer komplexitet när enkelhet vore bättre. **Varför quiXzoom är relevant för honom:** DHH är djupt skeptisk mot onödig komplexitet och mot VC-drivna rationaliseringar för att inte göra saker enkelt. quiXzoom är ett system som har äkta komplexitet (geo-data, offline-sync, gig payments) men som kan falla i fällan att lösa det komplicerat. Han är rätt person att ställa frågan: *varför gör ni inte det här med Rails och Postgres och Stripe direkt, och vad är den faktiska anledningen till varje komplexitetslager ni har?* **Hur man når honom:** Twitter/X (@dhh, extremt aktiv och direkt), konferenser. Svarar på utmaningar och äkta tekniska frågor. **Spår/format:** Spår 3 eller Spår 5, fireside chat med adversarial karaktär — han är bäst när han kan utmana. **Outreach-meddelande:** > "David — vi kör Node.js/TypeScript, PostgreSQL och Stripe Connect. Du skulle förmodligen fråga varför vi inte kör Rails. Det är en fair fråga, och vi har svar som är genuina snarare än defensiva. Vill du ge oss 60 minuter i ett Builder Session för att utmana varje komplexitetslager vi har? Vi vill inte ha en intervju — vi vill ha en grillning. Det är mer användbart för oss och mer intressant för publiken." --- ### 10. Rich Harris **Vem:** Skapare av Svelte och Rollup, staff engineer på Vercel; känd för att ifrågasätta konsensus i frontend-världen och för att bygga verktyg som löser problem på konceptuellt annorlunda sätt. **Varför quiXzoom är relevant för honom:** Harris har byggt Svelte som ett alternativ till det dominerande paradigmet (React) genom att flytta arbete till compile-time. quiXzoom-appen kör på mobil med begränsade resurser och intermittent connectivity — exakt det sammanhang där Sveltes bundle-size-fördelar är som störst. Dessutom har han navigerat OSS-strategi (Svelte är sponsrat av Vercel men community-drivet) på ett sätt som är relevant för oss. **Hur man når honom:** Twitter/X (@Rich_Harris, aktiv), konferenser (Svelte Summit, JSConf). Öppen för tekniska diskussioner. **Spår/format:** Spår 5 (OSS-strategi) eller frontend-spår (om vi lägger till ett sådant), fireside chat. **Outreach-meddelande:** > "Rich — vår mobilapp är vad Zoomer-nätverket möter varje dag. Bundle size, offline caching och PWA vs native är genuina avvägningar för oss — vi kör i sammanhang med dålig connectivity och budget-enheter. Dessutom funderar vi på OSS-strategi och hur Svelte-modellen (community-drivet, kommersiellt sponsrat av Vercel) fungerar i praktiken. Vill du dela era erfarenheter i ett Builder Session? Två separata frågor vi gärna utforskar med dig." --- ### 11. Evan You **Vem:** Skapare av Vue.js och Vite; byggt och underhållit ett av världens mest använda JavaScript-ramverk som en självständig OSS-byggare med sponsor-finansiering. **Varför quiXzoom är relevant för honom:** Evan You har lyckats med något sällsynt: ett community-finansierat OSS-projekt som konkurrerar med Facebook-backade och Vercel-backade alternativ. quiXzoom funderar på community-strategi och om OSS kan vara ett rekryteringsverktyg. Han har gjort det utan VC-stöd och vet vad det kostar. **Hur man redan honom:** Twitter/X (@youyuxi, aktiv), konferenser (VueConf, ViteConf). Engagerar sig i communty-frågor. **Spår/format:** Spår 5, samtal om sponsor-modeller och community governance. **Outreach-meddelande:** > "Evan — du har finansierat Vue och Vite via sponsorskap utan att sälja bolaget eller ta VC. Vi funderar på om quiXzoom kan open sourca delar av plattformen och bygga ett community runt den — men vi är osäkra på om sponsor-modellen fungerar för infrastruktur snarare än developer tools. Vill du dela dina erfarenheter av vad som faktiskt fungerar i ett Builder Session? Det är en fråga vi inte hittar bra svar på annars." --- ### 12. D. Richard Hipp **Vem:** Skapare av SQLite — den mest deployade databas-mjukvaran i historien; arbetar ensam (med ett litet team) och har gjort det i 25+ år utan extern finansiering. **Varför quiXzoom är relevant för honom:** SQLite är vår naturliga kandidat för Zoomer-local storage (offline-first, embedded, WAL-mode). Hipp har tänkt djupare på embedded database design och offline-semantics än nästan någon annan levande person. Frågor om WAL, concurrent readers, journal modes och sync semantics på mobila enheter är direkt relevanta för vår arkitektur. **Hur man redan honom:** E-post (richard@sqlite.org — han svarar faktiskt), sqlite.org-forumet. Direkt, teknisk, ingen hype. **Spår/format:** Spår 1, teknisk djupdyk om SQLite för offline-first mobila appar. **Outreach-meddelande:** > "Richard — vi designar Zoomer-local storage för en mobilapp som arbetar offline i fält och syncar när connectivity finns. SQLite med WAL-mode är vår kandidat. Men vi är osäkra på hur vi hanterar sync-konflikter när samma uppdrag kan vara delvis slutfört på enheten och delvis ogiltigförklarat server-side. Har du designat för det mönstret, och vad är fallgroparna? Vi vill gärna diskutera det öppet i ett Builder Session." --- ### 13. Filippo Valsorda **Vem:** Maintainer av Go:s kryptografibibliotek, före detta på Google Security, känd för exceptionellt tydligt tänkande om säkerhetsdesign och kryptografiska protokoll; en av de tydligaste rösterna i debatten om hur man designar *rätt* snarare än *säkert nog*. **Varför quiXzoom är relevant för honom:** Vi har ett trust-problem: hur verifierar vi att en bild är tagen av rätt person, på rätt plats, vid rätt tidpunkt — och inte manipulerad? Det är ett kryptografiskt attestationsproblem, och det är inte enkelt. Filippo har tänkt på liknande problem (content provenance, supply chain) och skulle kunna bidra med ramverk för hur vi tänker på det. **Hur man redan honom:** Twitter/X (@FiloSottile, aktiv), blogg (filippo.io). Öppen för genuint tekniska frågor. **Spår/format:** Spår 4, samtal om bildautenticitet och cryptographic attestation. **Outreach-meddelande:** > "Filippo — vi betalar Zoomers per godkänd bild. Det skapar ett ekonomiskt incitament att fuska: skicka en gammal bild, manipulera metadata, använda en bild tagen av någon annan. Hur designar man ett system som gör det svårare att fuska utan att introducera så mycket friktion att ärliga Zoomers ger upp? Det är ett attestationsproblem med ekonomiska stakes. Vill du tänka igenom det med oss i ett Builder Session?" --- ### 14. Marek Majkowski **Vem:** Principal engineer på Cloudflare, känd för djupa tekniska blogginlägg om nätverksstack, UDP, QUIC och edge-infrastructure; en av de mest lästa tekniska skribenter i branschen. **Varför quiXzoom är relevant för honom:** Cloudflare har löst distribuerade system-problem i stor skala och har erfarenhet av betalnings-adjacent infrastruktur (Cloudflare R2, Workers). Marek är specifikt intressant för oss för hans djupa förståelse av hur distribuerade system beter sig under realistiska nätverksförhållanden — exakt vad Zoomers möter. **Hur man redan honom:** Twitter/X (@majek04, aktiv), Cloudflare-bloggen. Engagerar sig i tekniska diskussioner. **Spår/format:** Spår 1 eller Spår 3, teknisk djupdyk. **Outreach-meddelande:** > "Marek — Cloudflare-bloggen om QUIC och nätverksbeteende under realistiska förhållanden är bland det bästa som skrivits om ämnet. Vi har ett liknande problem i litet: Zoomers syncar data på intermittent 3G/4G i svenska glesbygder. Hur designar man sync-protokoll för den typen av connectivity utan att introducera för mycket overhead? Det är inte rocket science men det finns rätt och fel svar. Vill du dela ditt perspektiv i ett Builder Session?" --- ### 15. Jon Gjengset **Vem:** Rust-programmerare och skapare av "Crust of Rust"-YouTube-serien; känd för exceptionellt pedagogiska live-kodningssessioner om avancerade Rust-koncept som concurrent systems, async runtimes och unsafe code. **Varför quiXzoom är relevant för honom:** Gjengset undervisar om concurrent systems på ett sätt som gör abstrakt teori konkret. quiXzoom har concurrency-utmaningar som är ovanliga: vi har concurrent writes till geografiska polygoner, concurrent reads av coverage-data och concurrent payout-beräkningar — allt med starka consistency-krav på vissa delar och acceptabel eventual consistency på andra. Det är ett pedagogiskt intressant problem. **Hur man redan honom:** Twitter/X (@jonhoo, aktiv), YouTube-kanalen. Engagerar sig i tekniska diskussioner om systemprogrammering. **Spår/format:** Spår 1, live-kodning eller whiteboard-session om concurrency-design. **Outreach-meddelande:** > "Jon — vi har ett concurrency-problem som är pedagogiskt intressant: vi har starka consistency-krav på payout-beräkningar (vi kan inte betala två gånger) och svagare krav på coverage-uppdateringar (eventual consistency är OK). Hur designar man gränserna mellan dessa i en Postgres-databas med hög concurrent write-load? Det är ett textbook-problem som inte har ett textbook-svar i vår specifika kontext. Vill du hjälpa oss tänka igenom det live i ett Builder Session?" --- ### 16. Casey Muratori **Vem:** Spelmotor-programmerare och skapare av "Handmade Hero"-projektet (live-kodning av ett OS och spelmotor från scratch); känd för obsessivt fokus på performance, mätbarhet och att ifrågasätta abstraktioner som kostar mer än de ger. **Varför quiXzoom är relevant för honom:** Muratori ställer alltid frågan: *vad kostar den här abstraktionen?* quiXzoom har abstraktionslager som vi inte alltid ifrågasatt — microservices, AI-granskning som black box, Stripe Connect istället för direktbanktransaktioner. Han är rätt person att ställa frågan om vi betalar för komplexitet vi inte behöver. **Hur man redan honom:** Twitter/X (@cmuratori), YouTube (Handmade Hero). Han är direkt och orädd för att vara kontroversiell. **Spår/format:** Spår 1 eller som "utmanare" i vilket spår som helst, adversarial format. **Outreach-meddelande:** > "Casey — du har en förmåga att ställa frågan ingen annan ställer: 'vad kostar den här abstraktionen, och är det värt det?' Vi har en microservice-arkitektur, ett AI-granskningslager och Stripe Connect. Vi är inte säkra på att vi har de svaren. Vill du grilla oss om det i ett Builder Session? Vi lovar att inte vara defensiva — vi vill faktiskt veta om vi gör fel val." --- ### 17. Kailash Nadh **Vem:** CTO på Zerodha (Indiens största mäklarfirma), skapare av Listmonk (open source nyhetsbrevsmjukvara) och en rad andra OSS-verktyg; känd för att bygga system med extraordinär enkelhet och minimalala dependencies. **Varför quiXzoom är relevant för honom:** Zerodha hanterar betalningar och ekonomisk identitet för miljontals indiska användare — ett marknadskontext som liknar vad vi möter i emerging markets där Stripe Connect är svårare. Nadh har byggt betalningssystem utanför den enkla västerländska kontexten och vet vad det kostar. Dessutom är hans approach till OSS (Listmonk: kompromisslöst, ingen SaaS, ren mjukvara) ett intressant kontrast mot quiXzoom. **Hur man redan honom:** Twitter/X (@kailashnadh), GitHub (@knadh). Aktiv i tekniska diskussioner. **Spår/format:** Spår 3 (betalningar i emerging markets) + Spår 5 (OSS-strategi). **Outreach-meddelande:** > "Kailash — Zerodha hanterar betalningar för miljontals indiska användare i ett regulatoriskt och infrastrukturmässigt sammanhang som är fundamentalt annorlunda än Europa. Vi expanderar quiXzoom till marknader utanför Norden och möter exakt de svårigheterna. Vad är de tre saker du önskar att du visste om betalningsinfrastruktur i emerging markets innan du byggde det? Vill du dela det i ett Builder Session?" --- ### 18. Guillermo Rauch **Vem:** CEO och grundare av Vercel, skapare av Socket.io och Next.js-ekosystemets fremsta drivkraft; känd för att ha byggt developer experience till en konkurrensfördel och för att ha skalat en platform med komplex finansiell infrastruktur bakom kulisserna. **Varför quiXzoom är relevant för honom:** Vercel hanterar payments, subscription management och developer billing i stor skala — allt via tredjepartsintegrationer. Guillermo har fattat de besluten och lever med konsekvenserna. quiXzoom är på samma resa fast med gig-workers istället för developers. Han har en konkret erfarenhet vi kan lära av. **Hur man redan honom:** Twitter/X (@rauchg, extremt aktiv), konferenser. Han gillar att tala om systemdesign och developer experience. **Spår/format:** Spår 3, fireside chat om betalningsinfrastruktur och platformsdesign. **Outreach-meddelande:** > "Guillermo — Vercel hanterar payments för hundratusentals developers. Vi hanterar payouts för Zoomers i 20+ länder. De tekniska utmaningarna (KYC, jurisdiktion, payout-latens, dispute-resolution) är liknande men i omvänd riktning: vi betalar ut snarare än tar in. Vad är det svåraste beslutet du tagit om betalningsinfrastruktur som inte var uppenbart från dag ett? Vill du dela det öppet i ett Builder Session?" --- ## 4. Genomförandeplan aug 2026 – jan 2027 ### Tidslinje | Datum | Aktivitet | |-------|-----------| | **Juli 2026** | Outreach till samtliga 18 nyckelpersoner. Mål: 3 bekräftade för Q4. | | **1 aug 2026** | Officiell lansering av Builder Sessions-sidan (enkel, ingen hype). | | **Sept 2026** | Session 1: Spår 1 — Distribuerade system. Förstahandsval: Kleppmann eller Cantrill. | | **Okt 2026** | Session 2: Spår 2 — AI-granskning. Förstahandsval: Howard eller Gerganov. | | **Nov 2026** | Session 3: Spår 3 — Betalningsinfrastruktur. Förstahandsval: Kailash Nadh eller DHH. | | **Dec 2026** | Session 4: Spår 4 eller Spår 5 — Coverage-mätning eller OSS-strategi. | | **Jan 2027** | Session 5: Wildcard — baserat på vad som fungerat och vad publiken efterfrågat. | | **Kontinuerligt** | Blogg-sammanfattning (svenska + engelska) efter varje session. Transkript publiceras. | ### Förberedelser per session **6 veckor före:** Outreach till talare. Personlig e-post, inte template. Referera till specifikt arbete. **4 veckor före:** Bekräftelse och teknisk brief (2 sidor) skickas till talaren. Tydliga tekniska frågor — inget marknadsföringsmaterial. **2 veckor före:** Marknadsföring: Twitter/X, LinkedIn, developer-communities (Hacker News Show HN, relevant subreddits). Ingen betald marknadsföring i fas 1. **1 vecka före:** Teknisk genomgång med talaren (30 min). Testa ljud, video, Q&A-format. Förbereda 10 backup-frågor om publiken är tyst. **Dag för session:** Publicera kort "context doc" offentligt — vad problemet är, varför vi bjudit in just den här personen. **Dagen efter:** Blogg-sammanfattning, transkript, inspelning. Tag specifika Hacker News-trådar om teknikens innehåll är tillräckligt. ### Tre budget-nivåer #### Shoestring (0–5 000 SEK/session) - Zoom/YouTube Live för streaming - Ingen reseersättning - Talare deltar pro bono (detta är realistiskt för de flesta på listan om innehållet är genuint) - Klippt video produceras in-house - Total kostnad per session: < 2 000 SEK (tid undantaget) #### Medel (5 000–20 000 SEK/session) - Riverside.fm eller StreamYard för studiokvalitet på inspelning - Honorar till talare om de ber om det (5 000–10 000 SEK) - Grundläggande video-editing och chapters - Show notes och transkript (AI-assisterat + manuell korrekturläsning) - Total kostnad per session: 8 000–15 000 SEK #### Ambitiös (20 000–50 000 SEK/session) - Professionell video-editing med B-roll och diagram - Talare-reseersättning för fysiska guest-appearances - Dedikerad pod-form med branded audio - Aktiv distribution till tech-poddkatalogen (Spotify, Apple Podcasts) - Total kostnad per session: 25 000–40 000 SEK **Rekommendation:** Börja med shoestring och uppgradera till medel-nivå när format och utbud är bekräftade. Ambitiös-nivå är relevant från session 6+ om det finns tydlig traction. ### Framgångsmått **Primära (teknik-credibilitet):** - Antal sessioner med talare från listan som faktiskt genomförs (mål: 6 av 6 under perioden) - Inbound intresse från talare som sett en session och vill delta (mål: 2+ i Q1 2027) - Citat/nämningar av quiXzoom i tekniska bloggar eller på Twitter/X från deltagare (mål: 5+ organiska) **Sekundära (räckvidd):** - YouTube-tittarantal live (mål: 50+ per session i fas 1, 200+ i fas 2) - Video-views totalt per session inom 30 dagar (mål: 500+) - Hacker News-poäng om vi postar (mål: > 50 poäng på relevanta Show HN) **Tertiära (affär):** - Inbound rekryteringsintresse från engineers som sett Builder Sessions (mål: 3+ kvalificerade kandidater under perioden) - Kundrelaterade inbound (kommuner, data-buyers som sett sessionen och hört om PBOI-konceptet): mål 2+ **Anti-mått (vad vi INTE mäter):** - Antal följare på quiXzoom:s sociala kanaler - Likes och engagemang på marknadsföringsposter - Pressklipp i generalist-media --- ## 5. Vad som dödar initiativet ### Varningssignal 1: Det förvandlas till ett webbinarium **Symptom:** Slide-decks. Produktdemos. "Låt mig berätta om quiXzoom." Talaren pratar om sina egna projekt och quiXzoom nämns som sponsor. **Konsekvens:** Alla tekniska opinionsbildare på listan har en allergi mot detta format. En session i det formatet och resten av listan tackar nej. Det sprider sig snabbt i communities. **Förebyggande:** Tydliga kontrakt med talare: *vi ber dig om ditt tekniska perspektiv på ett problem vi har. Du pratar om teknik. Vi nämns bara om du frågar om vår kontext.* Aldrig mer än 2 minuter "om quiXzoom" i inledningen. --- ### Varningssignal 2: Utreach-meddelanden är templates **Symptom:** "Hej [NAMN], vi på quiXzoom driver en spännande seminarieserie och undrar om du vill delta?" **Konsekvens:** Alla på listan får hundratals sådana meddelanden per år. De läser inte andra meningen. **Förebyggande:** Varje outreach-meddelande refererar till ett specifikt arbete av personen (kapitel, commit, blogginlägg) och kopplar det till ett specifikt tekniskt problem vi har. Det tar 30 minuter per person att skriva rätt. Det är värda de 30 minuterna. --- ### Varningssignal 3: Vi ber för tidigt om för mycket **Symptom:** Outreach-meddelandet ber om en 90-minuters live-session med en person vi aldrig pratat med. **Konsekvens:** Även om personen är intresserad är det för stor aktivering. De lägger det åt sidan och glömmer. **Förebyggande:** Första kontakten är alltid en öppen fråga eller ett konkret tekniskt problem, inte en bokning. Låt konversationen starta naturligt. Böck-frågan kommer i uppföljningen. --- ### Varningssignal 4: Vi optimerar för kvantitet **Symptom:** Vi kör två sessioner per månad för att bygga innehållsvolym. Vi bjuder in mindre kända namn för att fylla schemat. **Konsekvens:** Varje session med en talare av lägre kaliber späder på varumärket. Talarna på listan tittar på vem som deltagit innan de tackar ja. En session per månad, med rätt person, är bättre än fyra per månad med fel personer. **Förebyggande:** Håll en session per månad hårt. Skippa hellre en månad än kör med fel talare. --- ### Varningssignal 5: Innehållet är quiXzoom-centerat **Symptom:** Samtalsämnena handlar om vad quiXzoom har byggt, inte om de tekniska problemen i sig. **Konsekvens:** Publiken är inte intresserad av quiXzoom (ännu). De är intresserade av de tekniska problemen. quiXzoom är kontexten, inte ämnet. **Förebyggande:** Redigera varje fråga du förbereder: kan den frågan ställas utan att nämna quiXzoom? Om inte, reformulera. Frågan "hur hanterar Automerge partiell sync?" är bättre än "hur skulle Automerge lösa quiXzoom:s sync-problem?" --- ### Varningssignal 6: Det finns ingen intern ägare **Symptom:** Builder Sessions är "en kommunikations-grej" som hanteras av marknadsföring. Ingen teknisk person på LandveX är involverad i att förbereda frågorna eller delta i samtalen. **Konsekvens:** Talarna märker direkt om frågorna inte är tekniskt djupa. Det tar 20 sekunder. Initiativet tappar trovärdighet omedelbart. **Förebyggande:** Erik Svensson (eller en senior engineer) är personligen involverad i varje session. Han förbereder frågorna, leder samtalet, och sitter med under Q&A. Det är inte delegerbart om det ska fungera. --- ## Slutord Builder Sessions är ett bra initiativ om det görs rätt — och ett skadligt initiativ om det görs halvdant. De tekniska problemen vi har är genuint intressanta. Vi behöver inte sälja dem. Vi behöver bara ställa rätt frågor till rätt människor och hålla ut av vägen för svaren. Det är det enda formatet som fungerar med den här listan av talare. **Rekommendation:** Godkänn en pilotperiod på tre sessioner (sept–nov 2026) på shoestring-budget. Utvärdera efter session 3. Om traction finns, eskalera till medel-nivå och bredda listan. --- *Dokument framtaget av kommunikationsstrateg på uppdrag av Erik Svensson, LandveX AB. Konfidentiellt beslutsunderlag. Inte för extern distribution.*