Vi byggede Stackable, fordi rabatter blev ved med at fejle i netop det øjeblik, det betyder noget

Gennemgå nok anmeldelser af rabat-apps, og et mønster dukker op igen og igen: en pris ser korrekt ud i kurven, og så opkræves noget andet ved kassen. En kunde betaler fuld pris for noget, en forhandler lovede til rabat, eller to rabatter, der skulle have stablet, gør det stiltiende ikke, og ingen bemærker det, før en refusionsanmodning lander i supporten.

Mønstret bliver værre netop i de øjeblikke, forhandlere bekymrer sig mest om. Omkring Black Friday og Cyber Monday, når trafikken stiger, og hver ordre tæller, er præcis når disse fejl er mest tilbøjelige til at dukke op, fordi det er da kurve er fyldest, og rabatregler stables hårdest. Og hurtige kasser - Shop Pay, Apple Pay, Google Pay, PayPal - kører deres egen kodesti, så en rabat, der fungerer perfekt i en normal kasse, stille kan forsvinde i et etryks-betalingsflow, en forhandler aldrig selv tester.

Der er en anden fejltype, der er lige så skadelig for tilliden: apps, der ændrer et produkts faktiske pris for at vise en rabat, og lader den forblive ændret efter forhandleren afinstallerer. En ren afinstallation bør betyde, at butikken ser præcis ud, som den gjorde, før appen nogensinde blev tilføjet. Det burde ikke være en bonusfunktion - det burde være det mindste, man kan forvente.

Stackable er bygget omkring én idé: en rabat-apps eneste opgave er at have ret, overalt, hver gang. Ikke ret i kurven og forhåbentlig ved kassen. Ret i kurven, ret ved kassen, og ret i hvert eneste hurtige betalingsflow - fordi Shopify beregner dem alle ud fra den samme server-side regel, hvis du bygger appen på den måde.