”Trackingplattform” låter enkelt tills du börjar bygga. Sedan stöter du på scope creep, otydliga behörigheter, skör statuslogik och en dashboard som i praktiken bygger på gissningar. Det värsta är att upptäcka sent att ditt schema inte klarar realtidsuppdateringar i stor skala.
Den här tracking platform prompt är byggd för produktansvariga som vill omvandla en luddig ”vi behöver tracking”-idé till byggbara specifikationer, utvecklingschefer som behöver en säker multi-tenant-design i Supabase med RLS från dag ett, och implementeringskonsulter som mappar kundflöden till konfigurerbara entity-typer och statuspipelines. Resultatet är en teknisk ritning i produktionsklass: schematabeller, riktning för RLS-policyer, realtidskoppling, React-komponentgränser och analysmönster för en React + TypeScript + Supabase-stack.
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: byggare för konfigurerbar trackingplattform
Fyll i fälten nedan för att anpassa prompten efter dina behov.
| Variabel | Vad du ska ange | Anpassa prompten |
|---|---|---|
[MALGRUPP] |
Beskriv produktens primära användare eller kundsegment, inklusive deras roller, behov och utmaningar. Till exempel: "Operativa chefer i större logistikföretag som behöver spåra försändelser och optimera leveranskedjor."
|
|
[PRODUKTBESKRIVNING] |
Ge en kortfattad översikt av produkten och lyft fram syfte samt viktigaste funktionerna. Till exempel: "En konfigurerbar spårningsplattform som gör det möjligt för organisationer att följa arbetsflöden, visualisera framdrift och hantera komplexa processer i realtid."
|
|
[BRANSCH] |
Ange vilken bransch eller vilket område produkten riktar sig mot, inklusive relevanta delsegment. Till exempel: "Logistik samt supply chain management."
|
|
[KONTEXT] |
Ge bakgrund eller specifika omständigheter som påverkar produktens design och användningsfall. Till exempel: "Plattformen är avsedd för miljöer med höga volymer där realtidsspårning och samarbete mellan flera användare är avgörande."
|
|
[HUVUDMAL] |
Definiera det huvudsakliga målet som produkten ska uppnå för användarna. Till exempel: "Göra det möjligt för organisationer att effektivt spåra och hantera arbetsflöden med minimal manuell hantering."
|
|
[TEKNIKSTACK] |
Lista de tekniker, ramverk och verktyg som ska användas för att bygga produkten. Till exempel: "React, TypeScript, Supabase (PostgreSQL + realtid), Tailwind CSS, Recharts, React Router."
|
|
[VARUMARKESTON] |
Beskriv vilken ton och kommunikationsstil produkten ska förmedla till användarna. Till exempel: "Pragmatisk, genomförandefokuserad och professionell, med tydliga och kortfattade budskap."
|
|
[FUNKTIONER] |
Lista de viktigaste funktionerna och den funktionalitet som produkten ska innehålla. Till exempel: "Anpassningsbara objekttyper, realtidsuppföljning av framdrift, rollbaserade behörigheter och analysdashboards."
|
|
[PRESTANDAKRAV] |
Ange förväntad skalbarhet och prestandamål för produkten. Till exempel: "Stöd för 10 000+ objekt, 500+ samtidiga användare och hög händelsevolym med minimal latens."
|
|
[ANVANDARBEHORIGHETSNIVAER] |
Definiera de olika roller och behörigheter som användare ska ha i systemet. Till exempel: "Admin, Manager, Viewer; admins kan konfigurera arbetsflöden, managers kan uppdatera statusar och viewers kan endast följa framdrift."
|
|
[TIDSRAM] |
Ange förväntad tidsplan för leverans av produkten eller specifika milstolpar. Till exempel: "Initial MVP levereras inom 12 veckor, med full produktionsmognad inom 6 månader."
|
|
[BUDGET] |
Ange ekonomiska ramar eller finansiering som avsatts för projektet. Till exempel: "150 000 USD för utveckling och initial driftsättning."
|
|
[VERSALER_MED_UNDERSCORE] |
Ange ett värde formaterat med versaler och understreck mellan orden. Till exempel: "SPARNINGSPLATTFORM_KONFIGURATOR"
|
Proffstips för bättre resultat från AI-prompten
- Ge den ett verkligt workflow, inte fem. Börja med att beskriva ett enda trackingfall (till exempel ”inbound logistics: containers → milestones → exceptions”) så att schema och statuspipeline blir sammanhängande. När du har första ritningen, fråga: ”Visa nu hur man lägger till en andra entity-typ (shipments) utan att duplicera tabeller.”
- Tvinga fram en tydlig multi-tenant-modell. Tala om för AI:n vilken tenant-gräns du vill ha (organization_id överallt, eller en delad tabell med tenant-scoping) och be den motivera avvägningarna. En bra följdfråga: ”Föreslå RLS-policyer för org_admin, org_member och read-only auditor; inkludera exempel på tillåtna och nekade queries.”
- Be om paginering och indexering tidigt. Skalningsproblem föds nästan alltid i första schemat. Begär detaljer som: ”Inkludera index för high-read-paths (senaste status, aktiva objekt, statushistorik) och rekommendera cursor-paginering för 10k+ objekt.”
- Iterera på statuspipeline-beteendet. Statuslogik blir snabbt rörig, särskilt när team vill ha ”egna steg”. Efter första svaret kan du fråga: ”Gör alternativ A strikt (endast en aktiv status åt gången) och alternativ B flexibelt (parallella statusar), och betygsätt båda utifrån spårbarhet och komplexitet i realtime-UI.”
- Lås UI-acceptanskriterierna. Prompten ber om minimal, tydlig ”shipping-status-tydlighet”, dark mode och smaragdaccent (#10b981). Gör det mätbart: ”Definiera UI-states för trackinglistan (loading, stale realtime, error, empty) och skriv acceptanskriterier för status timeline-komponenten.” Ärligt talat: det här steget förhindrar veckor av design-by-opinion.
Vanliga frågor
Produktchefer använder den här för att omvandla ”vi behöver tracking” till en prioriterad, byggbar spec med tydliga moduler (admin-konfiguration, tracking-UI, realtid, analys). Utvecklingschefer använder den för att rimlighetskontrollera schemabeslut, skalningsantaganden (10k+ objekt) och Supabase RLS-upplägget innan arbetet startar. Lösningsarkitekter använder den när en konfigurerbar plattform måste stödja många workflows utan kundspecifik kod. Implementeringsansvariga använder den för att definiera hur icke-utvecklare säkert ska konfigurera entity-typer och statuspipelines.
Logistik- och supply chain-team använder den för att modellera shipments, containrar, avvikelser och milstolpslinjer med realtidsmässig ”var är det nu”-tydlighet. Vårdverksamheter kan anpassa entity/status-upplägget till patientflöden, labbprocess-steg eller utrustningsspårning, samtidigt som man behåller strikt tenant- och rollseparering. Tillverknings- och fältservicegrupper får nytta när jobb rör sig genom konfigurerbara steg och arbetsledare behöver dashboards för live-progress utan manuell rapportering. Professionella tjänsteföretag använder den för att följa projekt, godkännanden och leveranser över flera kunder, där RLS säkerställer att en kund aldrig ser en annan kunds data.
En typisk prompt som ”Write me a tracking platform spec for React and Supabase” misslyckas eftersom den: saknar tydliga antaganden och hantering av saknade inputs, ger ingen strukturerad byggordning (schema → dataåtkomst → UI → realtid → analys → härdning), ignorerar tenant-isolering och design av RLS-policyer, producerar generiska UI-råd istället för komponentgränser och state-beteenden, och missar skala i praktiken kring paginering, indexering och realtidsuppdateringar med hög eventvolym. Den här prompten trycker på ”byggbara” artefakter, inte magkänsla.
Ja, och det bör du, eftersom bäst resultat kommer av att skärpa de antaganden som prompten ber den att återge. Lägg till dina workflow-detaljer (entity-typer, obligatoriska fält, statussteg och vem som får ändra vad), din tenancy-modell (en org vs många orgs) och dina realtidsförväntningar (vilka skärmar som måste uppdateras direkt). Kör sedan en följdfråga: ”Skriv om schema- och RLS-avsnitten utifrån att vi behöver historik i revisionsklass och en read-only auditor-roll, och håll UI:t minimalt med dark mode och smaragdaccent #10b981.” Om du redan känner till dina prestandamål, ta med dem (peak samtidiga användare, dagliga events) så att val av indexering och paginering blir konkreta.
Det största misstaget är att ge en vag workflow-beskrivning—istället för ”spåra paket”, skriv ”spåra containrar med milstolpar (Booked, Departed, Arrived, Delivered) plus avvikelser (Held, Damaged) och ett obligatoriskt ETA-fält.” Ett annat vanligt fel är att hoppa över roller och behörigheter; ”användare kan redigera” bör bli ”org_admin kan konfigurera entity-typer, org_member kan uppdatera statusar, auditor är read-only inklusive historik.” Många glömmer också skaleinputs: ”många objekt” är svagt jämfört med ”10k aktiva objekt per tenant, 50 samtidiga användare, 200 statusevents/minut.” Slutligen under-specar team realtid: ange vilka vyer som prenumererar (lista, detalj, dashboards) och vad som händer vid avbrott (stale-badge, retry, last-updated-timestamp).
Den här prompten är inte optimal för engångsverktyg internt där du bara behöver en snabb CRUD-tabell och inte tänker investera i konfiguration, realtid eller analys. Den passar också dåligt om du inte är låst till den angivna stacken (React + TypeScript + Supabase), eftersom många rekommendationer utgår från Supabase realtid och RLS. Och om ert workflow ännu inte är förstått alls kan ni behöva en discovery-först-övning innan ett schema i produktionsklass. I så fall: fånga krav i en workshop och återvänd till den här prompten när kärn-entities och roller inte längre är gissningar.
Konfigurerbara trackingplattformar misslyckas inte för att team inte kan koda; de misslyckas för att specen aldrig blir ”byggbar”. Klistra in den här prompten i ditt AI-verktyg, svara ärligt på de saknade inputs, och gå in i nästa sprintplanering med en ritning istället för en magkänsla.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.