Marknadsplatsidéer är billiga. Förtroende för en marknadsplats är det inte. Om betalningar, utbetalningar, återbetalningar och tvister inte är konstruerade från dag ett slutar det med att säljare lämnar, köpare gör chargebacks och supportinkorgen aldrig tystnar.
Den här marketplace playbook prompt är byggd för produktansvariga som behöver en byggplan som engineering kan genomföra utan ”fyll i luckorna”, grundare som förbereder transaktioner med riktiga pengar och onboarding av säljare, samt tekniska konsulter som måste leverera ett trovärdigt arkitekturdokument till en kund. Resultatet är en produktionsredo byggblueprint för en tvåsidig marknadsplats med Next.js 14, TypeScript, Tailwind, Prisma, Postgres och Stripe Connect, inklusive datamodeller, API:er, UI-komponenter och hantering av fel och avvikelser.
Vad gör den här AI-prompten och när ska du använda den?
| Vad den här prompten gör | När du ska använda den här prompten | Vad du får |
|---|---|---|
|
|
|
Hela AI-prompten: byggblueprint för playbook för tvåsidig marknadsplats
Fyll i fälten nedan för att anpassa prompten efter dina behov.
| Variabel | Vad du ska ange | Anpassa prompten |
|---|---|---|
[PRODUKTBESKRIVNING] |
Ge en detaljerad beskrivning av den produkt eller tjänst du vill skapa, inklusive syfte, funktionalitet och viktigaste funktioner. Till exempel: "En tvåsidig marknadsplatsplattform där hantverkare kan sälja handgjorda produkter direkt till konsumenter, med integrerad betalningshantering och säljaranalys."
|
|
[MALGRUPP] |
Definiera den primära gruppen personer som kommer att använda produkten, inklusive demografi, beteenden och behov. Till exempel: "Småföretagare som söker prisvärda grafiska designtjänster av hög kvalitet, främst i USA och Kanada."
|
|
[KOPARPROFIL] |
Beskriv egenskaperna hos köparna på marknadsplatsen, inklusive deras köpvanor, preferenser och drivkrafter. Till exempel: "Teknikvana millennials som värdesätter miljövänliga produkter och är beredda att betala extra för hållbara varor."
|
|
[BRANSCH] |
Ange vilken bransch eller sektor marknadsplatsen ska verka inom. Ta med relevanta underkategorier vid behov. Till exempel: "Handgjort hantverk och artisanalprodukter, inklusive smycken, keramik och textilier."
|
|
[BEGRANSNINGAR] |
Lista eventuella begränsningar eller krav som måste beaktas vid design och utveckling av produkten. Till exempel: "Måste följa GDPR och PCI-DSS; begränsad budget för den initiala utvecklingsfasen."
|
|
[TIDSRAM] |
Ange förväntad tidsplan för projektet, inklusive viktiga deadlines eller milstolpar. Till exempel: "6 månader till lansering av en betaversion, med 3 månader för MVP-utveckling och 3 månader för testning och iteration."
|
|
[FORETAGSNAMN] |
Ange namnet på företaget eller organisationen som skapar den här marknadsplatsen. Till exempel: "CraftConnect Inc."
|
|
[VARUMARKESTON] |
Beskriv varumärkets ton, stil och personlighet i kommunikationen med användarna. Till exempel: "Vänlig, tillgänglig och professionell, med fokus på att stärka kreativa entreprenörer."
|
|
[VERSAL_MED_UNDERSCORES] |
Ange en sträng skriven med versaler och understreck mellan orden, vanligt för miljövariabler eller konstanter. Till exempel: "MARKETPLACE_API_KEY"
|
Proffstips för bättre resultat från AI-prompten
- Ge den en konkret transaktionshistoria. Innan du kör prompten, skriv en köparresa och en säljarresa på enkel svenska (5–10 steg vardera). Ta med ”jobbiga” moment som avbokningar, delåterbetalningar och adressändringar. Fråga sedan: ”Använd de här resorna för att styra schema- och webhook-designen; peka ut var du skulle lägga till audit events.”
- Bestäm vem som är merchant of record. Ditt ansvar för utbetalningar, skatt och tvister förändras beroende på om säljare tar betalt av köpare direkt via Connect eller om du gör det. Lägg till en följdfråga: ”Anta att säljare är merchant of record via Stripe Connect; gör om avsnitten om avgifter, återbetalningar och tvister och markera vad som ändras om plattformen är MoR.”
- Tvinga fram konkret webhook-hantering. Be modellen att lista event du måste lagra och stämma av, inte bara ”lyssna på webhooks”. En bra knuff: ”Lista exakta Stripe-event att hantera för checkout success, payout paid/failed, återbetalningar och tvister, och visa pseudokod för idempotent processing för ett event.”
- Iterera på failure modes, inte funktioner. Efter första outputen, välj ett riskområde (återbetalningar, tvister eller onboarding av säljare) och pressa hårdare. Testa: ”Gör nu tvistflödet mer rigoröst: inkludera statusövergångar, databasfält, admin-åtgärder och användarnära messaging för varje tillstånd.”
- Kombinera med en plan för operations-överlämning. En blueprint är bara användbar om teamet kan drifta den. Be om ett ”ops-bilaga” som innehåller larm, dashboards och eskaleringsvägar, och anpassa den sedan till en intern playbook med https://nodenordic.se/prompts/skapa-en-spelbok-for-uppgiftsoverlamning.
Vanliga frågor
Head of product-team använder den för att översätta ”vi bygger en marknadsplats” till en plan som går att bygga, med tydliga flöden, förtroendesignaler och driftkrav. Fullstackutvecklare använder den för de konkreta delarna: riktning för Prisma-schema, gränser för Next.js API:er och felhanteringsmönster kring webhooks och idempotens. CTO:er använder den för att stresstesta antaganden om säkerhet, observability och skalning innan riktiga pengar går i produktion. Fractional architects tar in den i kundarbete när de snabbt behöver en trovärdig blueprint utan att hamna i generiska råd.
Marknadsplatser för lokala tjänster (hemservice, skönhet, wellness) får värde eftersom återbetalningar, avbokningar och tvistlösning är återkommande, och förtroendesignaler avgör konverteringen. Plattformar för digitala produkter använder den för att designa audit trails och policy-styrd åtkomst, särskilt när chargebacks kan trigga direktbedrägeri och hög supportbelastning. B2B-upphandling och leverantörskataloger gynnas av multitenant-onboarding av leverantörer, rollbaserad åtkomst och avstämning som ekonomiteam accepterar. Biljetter och event-team använder den när timing för utbetalningar, avbokningar och delåterbetalningar måste hanteras korrekt utan att skapa säljarilska.
En typisk prompt som ”Skriv en marknadsplatsplan för Next.js och Stripe” misslyckas eftersom den: saknar hårda constraints (Next.js 14, Prisma, Postgres, Stripe Connect) vilket gör outputen abstrakt, inte ger någon strukturerad databasmodell för ordrar/utbetalningar/tvister, ignorerar webhook-verifiering och idempotent bearbetning, producerar generiska råd som ”hantera återbetalningar” i stället för faktiska tillståndsövergångar och audit trails, samt missar driftverkligheten: avstämning, observability, rate limiting och återhämtning vid fel.
Ja, men du anpassar genom marknadsplatsbeskrivningen du skickar med tillsammans med prompten, eftersom prompten i sig inte har inbyggda variabler. Lägg till detaljer som: vad som säljs, vilka säljarna är, hur leverans/fulfillment fungerar, regler för utbetalningstiming, provisionsmodell och dina mest riskfyllda failure modes (missbruk av återbetalningar, säljarbedrägerier, chargebacks). Ställ sedan en följdfråga som: ”Skriv om blueprinten för en marknadsplats där säljare levererar tjänster på plats, inkludera avbokningsfönster, delåterbetalningar och ett tvistflöde med admin-åtgärder.” Ju mer konkreta dina flöden är, desto mer konkreta blir schema- och API-designerna.
Det största misstaget är att lämna marknadsplatsbeskrivningen för vag — i stället för ”en marknadsplats för creators”, skriv ”en marknadsplats för digitala nedladdningar där säljare säljer mallar; omedelbar leverans; 10% plattformsavgift; veckovisa utbetalningar; vanligt problem är chargebacks efter nedladdning.” Ett annat vanligt fel är att hoppa över utbetalningsbegränsningar; ersätt ”betala säljare snabbt” med ”utbetalningar är T+7, med en intern reserv för förstagångssäljare i 30 dagar.” Folk glömmer också reglerna för tvister och återbetalningar; ”återbetalningar hanteras från fall till fall” bör bli ”återbetalningar tillåts inom 14 dagar endast om filen inte har laddats ner; annars kredit; tvister eskaleras till admin inom 48 timmar.” Till sist utelämnar team icke-funktionella krav; säg inte ”måste vara säkert”, specificera ”RBAC-roller (köpare, säljare, admin), rate limits i checkout, verifiering av webhook-signatur och audit-loggning för utbetalningsåtgärder.”
Den här prompten är inte optimal för engångsprototyper där du inte kommer att implementera webhooks, avstämning och riktiga utbetalningsflöden, eftersom den medvetet kommer att kännas ”för tung”. Den passar inte heller om du behöver juridisk eller skattemässig rådgivning; den kan peka ut var professionell granskning krävs, men den kan inte ersätta juridisk rådgivning. Och om teamet inte använder den angivna stacken (Next.js 14, TypeScript, Prisma, Postgres, Stripe Connect) kommer du att lägga tid på att översätta nyckeldelar i stället för att exekvera. I de fallen, börja med en enklare intern spec och anpassa sedan de avsnitt du behöver.
Betalningar förstör förtroende snabbt, och marknadsplatser lever eller dör på förtroende. Klistra in den här prompten i din modell, besvara de öppna frågorna ärligt och gå därifrån med en blueprint som teamet faktiskt kan bygga utifrån.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.