We shipped tarotas.com a few weeks ago. It's a tarot reading app: 78 cards, 5 languages, no signup wall. The core interaction is dead simple: shuffle the deck, draw a card, flip it, read the meaning.
Getting it to feel right took longer than I expected. Here's how we built the card component in React, what tripped us up, and what actually worked.
The state machine
A tarot deck has four moments: idle, shuffling, drawing, and revealed. We modeled this as a simple state machine rather than a pile of booleans.
type DeckState = 'idle' | 'shuffling' | 'drawing' | 'revealed';
const [deckState, setDeckState] = useState<DeckState>('idle');
const [drawnCard, setDrawnCard] = useState<TarotCard | null>(null);
const [deck, setDeck] = useState<TarotCard[]>(shuffledDeck);
Each state transition maps to one user action. Tap "shuffle" moves to shuffling, which runs a 1.2s animation, then auto-transitions to idle with a reordered deck. Tap a card moves to drawing, then revealed after the flip completes.
Why not just a boolean isFlipped? Because we needed to block double-taps during animation. A card mid-flip shouldn't respond to another tap. The state machine gives us that for free: if deckState !== 'idle', ignore input.
CSS 3D card flip
The flip itself is pure CSS. Two faces (.card-front and .card-back), positioned absolutely, with backface-visibility: hidden. The parent rotates on Y.
.card-container {
perspective: 1000px;
width: 200px;
height: 340px;
}
.card-inner {
position: relative;
width: 100%;
height: 100%;
transition: transform 0.6s cubic-bezier(0.4, 0, 0.2, 1);
transform-style: preserve-3d;
}
.card-inner.flipped {
transform: rotateY(180deg);
}
.card-front, .card-back {
position: absolute;
width: 100%;
height: 100%;
backface-visibility: hidden;
border-radius: 12px;
}
.card-back {
transform: rotateY(180deg);
}
Two things we learned the hard way:
-
perspectivegoes on the parent, not the rotating element. Put it on.card-innerand the 3D effect collapses flat. - Safari needs
-webkit-backface-visibility. Without it, both faces render simultaneously and you get a weird ghost image.
The cubic-bezier(0.4, 0, 0.2, 1) gives a slight acceleration into the flip and a soft deceleration out. Linear feels mechanical. We tried spring physics from framer-motion but honestly the CSS curve was close enough and saved us the dependency.
Shuffle animation
For shuffling, we wanted the cards to scatter slightly and reassemble. Not a full Vegas dealer animation, just enough to signal "the order changed."
const shuffleDeck = () => {
setDeckState('shuffling');
// Fisher-Yates shuffle
const newDeck = [...deck];
for (let i = newDeck.length - 1; i > 0; i--) {
const j = Math.floor(Math.random() * (i + 1));
[newDeck[i], newDeck[j]] = [newDeck[j], newDeck[i]];
}
setTimeout(() => {
setDeck(newDeck);
setDeckState('idle');
}, 1200);
};
The visual part: during the shuffling state, each visible card gets a random CSS transform via inline styles:
const getShuffleTransform = (index: number) => {
if (deckState !== 'shuffling') return {};
const angle = (Math.random() - 0.5) * 15;
const tx = (Math.random() - 0.5) * 30;
const ty = (Math.random() - 0.5) * 20;
return {
transform: \`rotate(${angle}deg) translate(${tx}px, ${ty}px)\`,
transition: 'transform 0.4s ease-out'
};
};
Cards jitter for 400ms, then snap back to position when the deck state resets. Simple, and it reads clearly on mobile.
Touch handling
Most users are on phones. We added swipe-to-draw: swipe up on the deck fans the top card out.
const touchStart = useRef<{ x: number; y: number } | null>(null);
const onTouchStart = (e: React.TouchEvent) => {
touchStart.current = {
x: e.touches[0].clientX,
y: e.touches[0].clientY
};
};
const onTouchEnd = (e: React.TouchEvent) => {
if (!touchStart.current || deckState !== 'idle') return;
const dy = touchStart.current.y - e.changedTouches[0].clientY;
if (dy > 50) { // upward swipe threshold
drawCard();
}
touchStart.current = null;
};
50px threshold. Lower and you get accidental draws from scrolling. Higher and the gesture feels sluggish. We tested on three phones before settling on 50.
No swipe library. The built-in touch events cover this use case fine. Adding Hammer.js or similar would've been overkill for a single gesture direction.
Loading 78 card images
78 cards, each with a front illustration. That's roughly 4-5 MB if you load them all eagerly. We didn't want a blank loading screen, so:
// Only preload the card back (shared) + first 5 cards
const preloadImages = (cards: TarotCard[]) => {
const urls = [
'/cards/back.webp',
...cards.slice(0, 5).map(c => \`/cards/${c.id}.webp\`)
];
urls.forEach(src => {
const img = new Image();
img.src = src;
});
};
The rest load on demand when a card is drawn. Since only one card is face-up at a time, the user never sees a loading state. The drawn card's image starts fetching when deckState transitions to drawing, and the 600ms flip animation buys enough time for the image to arrive. On slow connections, we show a subtle skeleton placeholder inside the card face.
We converted everything to WebP. The original PNGs were 80-120 KB each. WebP brought them down to 25-40 KB. Total payload for all 78 cards dropped from ~7 MB to ~2.5 MB.
What Lovable helped with
We built this in Lovable. A few prompts that saved real time:
- "Create a card flip component with CSS 3D transforms, perspective on parent, backface-visibility hidden" got the basic structure right on first try. We tweaked the timing curve manually.
- "Add Fisher-Yates shuffle with scatter animation on each card" produced working code. The random transform values were too aggressive (cards flew off screen), but the structure was solid.
- "Lazy load card images, preload only the back and first 5" nailed it. No corrections needed.
Where Lovable struggled: anything involving the interaction between animation timing and state transitions. The state machine was something we designed on paper first and then implemented ourselves. Prompting for "don't allow taps during animation" kept producing isAnimating booleans that leaked, so we went with the explicit state machine approach.
The result
tarotas.com runs the card component across all 78 Major and Minor Arcana cards in 5 languages. The shuffle-draw-flip loop is the entire core interaction. On mobile it feels snappy: sub-second shuffle, 600ms flip, images ready before the card finishes turning.
If you're building something similar, the state machine is the part that matters most. Get that right and the animations are just styling on top.
Built at Inithouse, where we ship MVPs and see what sticks.
