
Scoppa ett webbapp-projekt med AI: Den 6-promptskedjan vi använder (från idé till SOW)
På våra senaste fem kundscopes sjönk den del som brukade ta 12 till 16 timmars discovery-möten till ungefär 3 timmars AI-arbete plus en timmes mänsklig granskning. Vi kör hela kedjan i ett och samma Claude Project så att kontexten följer med hela vägen. Problemet? AI gjorde tre saker fel varje enskild gång. Så vi lade till ett grindsteg innan något når kunden.
Det här är den faktiska 6-promptskedjan vi använder, vilken artefakt varje prompt producerar, ett genomarbetat exempel och de fellägen du måste fånga själv.
Kan AI scoppa ett webbapp-projekt? Ja. AI kan ta fram ett fullständigt scope (problemformulering, user stories, features, MoSCoW-prioriteringar och ett statement of work) på några timmar istället för dagar. Det den inte kan göra är att validera det utkastet. Den hittar på krav och underestimerar arbete, så ett mänskligt grindsteg är obligatoriskt innan sign-off.
Viktiga punkter
- AI tar fram ett fullständigt webbapp-scope på timmar, inte dagar — men kan inte validera sin egen output.
- Kedjan är sex prompts: problem, user stories, features, MoSCoW, estimat, SOW.
- AI hittar på integrationer och underskattar edge cases, så kör alltid ett mänskligt grindsteg.
- Använd Claude Projects eller ChatGPT Projects för kedjan; agenter kommer efter att scopet är signerat.
AI kan skriva ditt första scope-utkast på en eftermiddag. Den kan bara inte säga när den har fel.
Vad är AI-assisterad scoping (och vad är det INTE)?
AI-assisterad scoping innebär att använda en serie LLM-prompts för att omvandla en grov idé till strukturerade scope-artefakter: krav, user stories, en featurelista, prioriteringar och ett statement of work. AI gör utkastet och struktureringen. En människa fattar fortfarande besluten, för stakeholder-samtalen och gör valideringen.
Tänker AI åt dig? Inte riktigt. Den är snabb på AI-kravhantering — den del där du stirrar på ett tomt dokument och försöker översätta "jag vill ha en bokningsapp" till något en utvecklare kan offerta. Den är dålig på att veta vad kunden faktiskt behöver kontra vad som låter rimligt.
Några saker AI-assisterad scoping inte är: den är inte autonom, den ersätter inte samtal med riktiga intressenter och den garanterar inte korrekthet. Modellen skriver gärna en välformaterad spec för en feature ingen bad om, och gör det med full tillförsikt.
Det här inlägget förutsätter att du redan förstår scoping-processen som sådan. Vill du ha grunderna täcker vår steg-för-steg-scopingguide den underliggande processen utan AI, de 7 stegen och hela scope-dokumentstrukturen. Här håller vi oss till AI-lagret: vilken prompt, i vilken ordning och var det går snett.
AI-scoping-promptskedjan i korthet
Kedjan är sex prompts som körs i sekvens, där varje prompt matar sin output in i nästa. I ordning: (1) problem och mål, (2) user stories, (3) featurelista, (4) MoSCoW-prioritering, (5) estimat för arbete, kostnad och tidslinje, och (6) SOW-utkastet. Kör dem i ett och samma projekt så att kontexten finns kvar.
Det smarta med det här: eftersom varje prompt bygger på den föregående behöver du inte förklara appen sex gånger. Modellen vet redan vad problemet är när den skriver user stories, och den känner redan till historierna när den prioriterar features.
- Problem & mål: omvandlar en grov idé till en problemformulering plus SMART-mål.
- User stories: konverterar mål till user stories med acceptanskriterier.
- Featurelista: härleder ett konkret feature-inventory från historierna.
- MoSCoW-prioritering: sorterar features i Must, Should, Could, Won't.
- Estimat: producerar ett estimat för arbete, kostnadsintervall och tidslinje.
- SOW-utkast: sätter ihop allt till ett statement of work.

Det här är också en snygg uppsättning AI-prompts för projektledning generellt, men vi har finjusterat varje prompt specifikt för webbappar (tech stack, integrationer, edge cases). Den finjusteringen är det som skiljer ett användbart scope från ett generiskt.
Tricket är inte en magisk prompt. Det är sex prompts som lämnar sin output vidare till varandra.
Hur kör du kedjan, steg för steg?
Du kör kedjan uppifrån och ned i ett Claude Project eller ChatGPT Project, klistrar in varje prompt i ordning och låter det föregående svaret finnas kvar i kontexten. Nedan följer de sex stegen med exakt de prompts vi använder. Varje prompt är avsiktligt webbapp-specifik, för att generiska affärsanalysprompts ger generiska scopes.
En sak att tänka på innan du börjar: ersätt platshållarna inom hakparentes med dina egna uppgifter, och acceptera aldrig det första resultatet som slutgiltigt. Det smarta sättet är att läsa varje resultat, rätta det och sedan köra nästa prompt.
Prompt 1: Problemformulering & mål
You are a senior product manager scoping a web application.
Here is the rough idea: [describe the app in 2-4 sentences].
The target users are [who]. The business wants [outcome].
Write:
1. A one-paragraph problem statement.
2. 3-5 SMART goals with success metrics.
3. 3 assumptions you are making that I should confirm.
Flag anything that is unclear instead of guessing.Det här ger dig din overview- och målsektion. Tips: raden "3 assumptions" gör ett tungt lyft. Den blottlägger de luckor AI annars skulle spackla över.
Prompt 2: User stories
Acting as the same product manager, turn the goals above into
user stories for a web app. Use the format:
"As a [role], I want [action], so that [benefit]."
Cover every user role. For each story, add 2-3 acceptance
criteria. Group stories by feature area.Nu har du funktionella krav. Det här är ett rent AI-user story generator-steg. En sak att bevaka: modellen tenderar att glömma admin- och edge-case-roller, så följ upp med "lägg nu till stories för admins, misslyckade betalningar och tomma states."
Prompt 3: Featurelista
Based on the user stories above, produce a flat feature
inventory for this web app. Group features into: core, account
and auth, admin, integrations, and notifications. Note any
feature that requires a third-party service or API.Det här är din kandidatlista för in-scope-features. Håll ett extra öga här, för det är i det här steget AI börjar hitta på integrationer (mer om det senare).
Prompt 4: MoSCoW-prioritering
Prioritize the feature list using MoSCoW (Must, Should, Could,
Won't) for a first release (MVP). For each feature give a
one-line reason. Assume a 3-month MVP budget and be ruthless:
most features should NOT be "Must."Det här taggar dina in-scope- och out-of-scope-poster. Instruktionen "be ruthless" spelar roll; utan den markerar modellen nästan allt som Must.
Prompt 5: Estimat för arbete, kostnad & tidslinje
Estimate effort, cost, and timeline for the Must-have features
only. Assume a stack of [e.g. Next.js, Supabase, Stripe] and a
team of [N] developers. Break the estimate down by feature in
days. State every assumption. Give a cost RANGE, not a single
number, and flag the 3 riskiest estimates.Det här är din input till AI scope of work generator för budget och tidslinje. Kräv alltid ett intervall och antagandena, för ett enda säkert tal är den farligaste output AI ger dig.
Prompt 6: SOW-utkast
Assemble everything above into a draft statement of work for a
client. Include: overview, goals and success metrics, in-scope
features, explicit out-of-scope items, timeline, budget range,
deliverables, assumptions, and a sign-off section. Mark any
section where you are uncertain with [REVIEW].[REVIEW]-taggarna blir din checklista för det mänskliga grindsteget. Det här steget sätter ihop hela den utlovade idé-till-SOW-spänningen kedjan lovar.
Prompt → Scope-sektionsmapping
Varje prompt svarar inte bara på en fråga — den fyller ett specifikt avsnitt i det dokument du överlämnar till kunden. Den här mappningen ersätter den vanliga 11-sektionsmallen: istället för att memorera ett skelett kör du kedjan och dokumentet sätter ihop sig självt. Här är vilken prompt som producerar vilket leverabel.
| Prompt | Producerar | Scope-dokumentsektion |
|---|---|---|
| 1. Problem & mål | Problemformulering + SMART-mål | Overview, Mål & Framgångsmått |
| 2. User stories | User stories + acceptanskriterier | Funktionella krav |
| 3. Featurelista | Feature-inventory | In-scope-features |
| 4. MoSCoW | Prioriterade Must/Should/Could/Won't | In-scope (taggade) + Out-of-scope |
| 5. Estimat | Arbete, kostnadsintervall, tidslinje | Tidslinje, Budgetintervall |
| 6. SOW-utkast | Sammanställt statement of work | Fullständigt SOW + leverabler + sign-off |
När du är klar med Prompt 6 har du ett färdigt första utkast av ett dokument kunden faktiskt kan läsa och signera — inte en hög med lösa anteckningar.
Varje prompt svarar inte bara på en fråga. Den fyller ett specifikt avsnitt i dokumentet du lämnar till kunden.
Ett genomarbetat exempel: Scoping av en boknings-SaaS
Här är kedjan körd från start till mål på ett konkret fall: en boknings-SaaS för en liten tandläkarkedja. Det är ett illustrativt exempel, inte ett riktigt kundleverabel — och ja, vi hittade två fel i AI-outputen, som vi åtgärdar i grindstegsavsnittet nedan.
Output från Prompt 1 (problem & mål). Problem: en tandläkarkedja med tre kliniker tappar bokningar på grund av telefonkö och uteblivna patienter. Mål: minska uteblivna med 30% via påminnelser, låt patienter boka online och ge receptionspersonal en gemensam kalender. Flaggade antaganden: en tidszon, bara engelska, ingen försäkringshantering.
Output från Prompt 2 (exempelstories).
- Som patient vill jag boka en tid online, så att jag inte behöver ringa.
- Som patient vill jag få ett SMS-påminnelse, så att jag inte glömmer min tid.
- Som receptionist vill jag se alla tre kliniker i en kalender, så att jag kan hantera överlapp.
Output från Prompt 3 (featurelista, förkortad). Online-bokning, kalendersynk, SMS- och e-postpåminnelser, patientkonton, flerorts-admin, grundläggande rapportering och ett betalningssteg (det sista var påhittat; ingen bad om det).
Output från Prompt 4 (MoSCoW-grid).
| Prioritet | Features |
|---|---|
| Must | Online-bokning, flerorts-kalender, SMS-påminnelser, patientkonton |
| Should | E-postpåminnelser, grundläggande rapportering |
| Could | Patientens egenomskolning |
| Won't (v1) | Betalningar, försäkringshantering, native mobilapp |

Output från Prompt 5 (estimat, förkortad). Med Next.js, Supabase och Twilio med två utvecklare: Must-have-features på ungefär 45 till 60 utvecklardagar, ett kostnadsintervall runt $35K–$55K och en tidslinje på 8 till 10 veckor. Riskigaste estimat flaggat: logiken för flerorts-kalendern.
Output från Prompt 6 (SOW-utdrag). "In scope: online-bokning, delad flerorts-kalender, SMS-påminnelser (Twilio), patientkonton. Out of scope: betalningar, försäkring, native mobil. Tidslinje: 8–10 veckor. Budgetintervall: $35K–$55K. [REVIEW] Bekräfta Twilio kontra alternativ SMS-leverantör med kunden."
Läser du igenom det ser du att ett riktigt, signerbart scope tog form på ett sammanträde. Om du planerar att lägga på smarta funktioner senare tar vår guide om att lägga till AI-funktioner i din app vid där det här slutar.
Hur estimerar du kostnad och tidslinje med AI?
Du ber modellen bryta ned estimatet per feature i dagar, anta en specifik tech stack, ange varje antagande och returnera ett intervall snarare än ett enda tal. Sedan rimlighetskontrollerar du intervallet mot kända marknadsnivåer, för AI ankrar nästan alltid för optimistiskt på arbetsinsatsen.
Behandla AI-estimat som en startpunkt, aldrig som en offert. Den enskilt mest användbara instruktionen är "flagga de tre riskigaste estimaten", som visar exakt var du ska lägga din egen bedömning. Här är de nivåer vi kontrollerar varje AI-estimat mot.
| Komplexitet på webbapp | Typiskt kostnadsintervall | Typisk tidslinje |
|---|---|---|
| Enkelt MVP | $10K–$50K | 1–3 månader |
| Medel (auth, betalningar, dashboard) | $50K–$100K | 3–6 månader |
| Komplext (flerrols, integrationer, skalbarhet) | $75K–$150K+ | 6–12 månader |
Dessa intervall stämmer överens med publicerade byråers och marknadsplatsers riktmärken; Clutch:s kostnadsforskning för apputveckling är en rimlig offentlig referenspunkt. Om ditt AI-estimat hamnar långt under den relevanta nivån har den troligen missat edge cases. Det är också i det här läget du bör ställa den större frågan: bygga eller köpa. Ett scope som spränger den komplexa nivån är ibland ett argument för att köpa istället för att bygga.
Vilket AI-verktyg ska du använda till vad?
För hela kedjan, använd Claude Projects eller ChatGPT Projects, eftersom båda persisterar kontext mellan prompts så att output bärs vidare utan att du behöver klistra in om. Använd en fristående agent först efter att scopet är signerat och du genererar upprepningsbara artefakter. För engångsscoping slår Projects en agent varje gång.
Vi kör kedjan i Claude Projects för steg med lång kontext (user stories, SOW-sammansättning) och går till ChatGPT för en second opinion på estimaten. Enligt Anthropics Projects-dokumentation håller ett Project delad kontext och instruktioner över en konversation — vilket är precis vad ett sex-prompts Claude Projects för krav-arbetsflöde behöver. OpenAIs Projects fungerar likadant för ChatGPT-prompts för mjukvaruutveckling.
En teknik värd att stjäla: dela upp AI:ns roll per steg. Säg åt den att "agera produktchef" för user stories och "agera senior ingenjör" för estimaten. Rollbytet förändrar hur den resonerar, och ingenjörspersona är märkbart mer försiktig med arbetsinsatsen.
När scopet är levererat och bygget börjar skiftar verktygsfrågan till AI-kodningsagenter — vilket är ett helt annat beslut.
Var gör AI fel i scoping? Det mänskliga grindsteget
AI gör fel i scoping på förutsägbara sätt: den hittar på integrationer ingen bad om, underskattar edge cases och felhanteringsstates, och antingen hittar på compliance-krav eller utelämnar riktiga. Den ankrar också kostnadsestimat för optimistiskt. Inget av det här är sällsynt — det händer i princip varje körning, vilket är anledningen till att det mänskliga grindsteget inte är förhandlingsbart.
Dåliga krav är dyra oavsett om en människa eller en modell skriver dem. PMI:s Pulse of the Profession-forskning visade att felaktig kravhantering är en primär orsak till projektmisslyckanden i ungefär 37% av fallna projekt — så poängen med grindsteget är att fånga de misstagen innan de når en offert, inte efteråt.
Åtgärden är en kort checklista som en människa kör innan ett scope når en kund:
- Ta bort påhittade features: ta bort allt (betalningar, exporter, integrationer) kunden aldrig bad om.
- Lägg till de saknade edge cases: misslyckade betalningar, tomma states, behörigheter, felhantering.
- Verifiera varje integration: bekräfta att varje nämnd tredjepartstjänst är riktig, behövd och budgeterad.
- Kontrollera compliance-påståenden: bekräfta eller korrigera varje auth-, integritets- eller regulatoriskt krav AI hävdade.
- Öka estimaten: justera de optimistiska talen mot din egen leveranstakt, särskilt de flaggade riskfyllda.
AI scoppar gärna ett betalningsflöde den hittade på. Ditt jobb är att ta bort de delar ingen bad om.
Vad vi lärde oss när vi körde det här på riktiga kundscopes
Över våra senaste kundscopes har discovery som brukade ta ungefär 12 till 16 timmars möten och skrivarbete nu resulterat i ett första SOW-utkast på ungefär 2 till 3 timmars AI-arbete plus en timmes mänsklig granskning. Det är ärliga intervall från våra egna körningar, inget exakt rubriksiffra — och timmen med en människa är den vi aldrig skär bort.
Vi kör kedjan i Claude Projects, med ChatGPT som rimlighetskontroll på estimaten. Tidsbesparingen är verklig, men värdet ligger i att fånga samma tre fel varje gång:
- Den hittar på integrationer. Ett betalningssteg i tandläkarexemplet som ingen bad om. I nästan varje scope dök det upp minst en spökfeature.
- Den underskattar edge cases. Felstates, tomma states och adminflöden saknas konsekvent eller underskattas — det är där verkliga budgetar spricker.
- Den hanterar compliance och auth fel. Ibland hittar den på ett krav, ibland utelämnar den ett riktigt. Vi litar aldrig på den i det här.
Så vi lade till det mänskliga grindsteget ovan som ett fast steg. Kedjan skriver utkastet snabbt; grindsteget är det som gör det säkert att skicka. Hoppar du över grindsteget skickar du bara en välformaterad, säker gissning.
Hur Techsy hanterar AI-assisterad scoping
Den här kedjan plus det mänskliga grindsteget är exakt det arbetsflöde vi kör för kunder som bygger webbappar. Vi utkastet snabbt med AI, sedan validerar en person som har levererat riktiga byggen varje rad innan den blir en offert. Om du hellre vill lämna scopet till ett team som gör det här dagligen är det vad vi erbjuder. Du får ett välgrundat SOW utan att betala för två veckors discovery-möten först.
Om författaren
Mert Batur är medgrundare av Techsy.io, där teamet levererar AI-agenter, automationssystem och röst/SDR-pipelines till B2B-kunder. Han skriver om det LLM-verktygsstack Techsy-teamet faktiskt använder i produktion.
Medgrundare, Techsy.io. Kontakta på LinkedIn.
Vanliga frågor
Kan AI skriva ett projektscope eller SOW?
Ja, AI kan ta fram ett fullständigt projektscope eller statement of work, inklusive problem, user stories, features, prioriteringar, tidslinje och budgetintervall. Kör en sex-promptskedja i ett Claude- eller ChatGPT-projekt. Utkastet är tillförlitligt som startpunkt, men en människa måste validera det innan sign-off.
Vilket är det bästa AI-verktyget för att scoppa ett mjukvaruprojekt?
Claude Projects och ChatGPT Projects är de bästa verktygen för scoping, eftersom båda persisterar kontext över promptskedjan så att varje output matar nästa. Vi använder Claude Projects för steg med lång kontext som user stories och SOW-sammansättning, och ChatGPT som en second opinion på estimaten. Agenter passar bättre för byggarbete efter scopet.
Hur använder du ChatGPT eller Claude för att samla in krav?
Kör promptskedjan i ordning: be om en problemformulering och mål, sedan user stories med acceptanskriterier, sedan en featurelista, sedan MoSCoW-prioriteringar. Håll allt i ett Project så att kontexten bärs vidare. Varje prompts output blir input till nästa, vilket är det som gör AI-kravhantering snabb.
Kan AI estimera mjukvaruprojekts kostnad och tidslinje?
Ja, men bara som startpunkt. Be modellen bryta ned estimatet per feature i dagar, anta en specifik stack, ange sina antaganden och returnera ett intervall. Rimlighetskontrollera sedan mot marknadsnivåer: $10K–$50K för ett enkelt MVP, upp till $150K+ för komplexa appar. AI tenderar att ankra för optimistiskt.
Är AI-genererat scope faktiskt tillförlitligt?
Tillförlitligt för ett första utkast, inte för sign-off. AI producerar ett välstrukturerat scope snabbt, men hittar på integrationer, underskattar edge cases och hanterar compliance fel i nästan varje körning. Behandla outputen som ett snabbt utkast, kör sedan ett mänskligt valideringssteg för att ta bort påhittade features och lägga till saknade edge cases innan någon signerar.
Hur omvandlar jag en grov idé till en spec med AI?
Börja med Prompt 1: klistra in din idé i två till fyra meningar och be AI skriva en problemformulering, SMART-mål och de antaganden den gör. Kör sedan de fem nästa prompterna i sekvens. Efter Prompt 6 har du ett SOW-utkast. Hela kedjan tar ett par timmar istället för dagar.
Ersätter AI-assisterad scoping en discovery-fas?
Nej, den komprimerar discovery snarare än att ersätta den. Du behöver fortfarande riktiga stakeholder-samtal för att veta vad kunden faktiskt vill ha. AI hanterar utkastet och struktureringen och omvandlar dina anteckningar till krav och ett SOW på timmar. Människor validerar, prioriterar och fattar fortfarande de slutgiltiga besluten om scope.
Hur lång tid tar det att scoppa en webbapp med AI?
I vår erfarenhet tar ett första SOW-utkast ungefär 2 till 3 timmars AI-arbete plus ungefär en timmes mänsklig granskning, mot 12 till 16 timmars manuell discovery och skrivarbete. AI-tiden är snabb; granskningstimmen är inte förhandlingsbar — det är där du fångar de features AI hittade på och de edge cases den missade.