Fallstudie
Dice Cat: En matchmaking-app för bordsspel
Problemet
Bordsspelare samlar på sig stora samlingar och har starka preferenser, men det är verkligen svårt att hitta lokala spelare som äger samma spel, har samma tidspunkter och passar ihop spelstilmässigt. De alternativ som finns – Facebook-grupper, Discord-servrar, Meetup – kräver manuell samordning och erbjuder ingen matchning av spelbibliotek.
Det viktigaste kravet: skapa en applikation i stil med Tinder för brädspel som verkligen känner till ditt spelbibliotek.
Översikt
Produkten började som ”Meeplr” – ett UX-koncept som byggde på omfattande forskning redan innan en enda rad kod hade skrivits.
- ·Konkurrensanalys av befintliga verktyg för community- och matchmaking
- ·Utveckling av användarprofiler – en spelare som har flyttat och saknar en lokal spelgrupp
- ·Tre omgångar av användbarhetstestning med högt tänkande med 15 deltagare
- ·Kano-analys: alla planerade MVP-funktioner har bedömts som antingen prestandamässiga eller attraktiva
- ·Namnet ändrades till Dice Cat efter att en varumärkesundersökning visade att det ursprungliga namnet inte kunde användas – namnet visade sig vara lättare att komma ihåg i tester
Viktiga funktioner
- ·Flerdimensionell matchning: spelbibliotek, geografisk närhet, schemaläggningsöverlappningar och preferenser vad gäller spelstil
- ·En speldatabas med över 10 000 titlar, med lokal fuzzy-sökning och möjlighet att lägga till titlar manuellt
- ·Visuell verktyg för att skapa veckoscheman med funktion för att upptäcka eventuella tidsmässiga överlappningar
- ·System för anslutningsförfrågningar med ömsesidig matchning före meddelandeutbyte
- ·Krypterad meddelandefunktion i appen för planering av möten
- ·Push-meddelanden via Firebase Cloud Messaging
- ·Anpassad SVG-avatarbyggare med ett system av lagerindelade komponenter
- ·Karta över spelare i närheten med hjälp av geospatiala sökningar i PostGIS
Skärmdumpar




Teknisk arkitektur
Tekniska höjdpunkter
Databasens prestanda
JOIN-frågor med flera tabeller för matchresultat tog ursprungligen 3–5 sekunder att köra. Genom strategisk PostGIS-indexering och omstrukturering av frågorna kunde tiden minskas till under 500 ms.
Fel i beroendet av externt API
BoardGameGeek avbröt API-åtkomsten mitt under utvecklingsfasen. Vi bytte istället inriktning och byggde upp en lokal databas med över 10 000 spel, som fylls på av användarna – vilket ger bättre funktion offline och eliminerar risken för framtida beroende av tredje part.
Arkitektur för behörigheter för push-meddelanden
En triggerbaserad lösning stötte på behörighetsfel i produktionsmiljön. Vi flyttade logiken till Supabase Edge Functions, vilket löste problemet med behörighetskontexten på ett smidigt sätt.