DEV Community

Jakub
Jakub

Posted on

Same Components, Different Worlds: Two Card Games from One Codebase

#webdev #react #buildinpublic #indiehackers

When I started building Party Challenges, I didn't plan to ship a second product from the same code. But about two weeks in, I noticed something. The card component, the deck selector, the game loop, the PWA setup... none of it cared what was on the card. A dare and a deep question look exactly the same to a React component.

So I built Here We Ask on top of the same foundation. Same card flip animation, same deck navigation, same offline-first architecture. Completely different product.

Here's what I learned shipping two products from one codebase, and why I think more indie builders should try this.

The shared layer

Both products are React SPAs built with Lovable (a vibe-coding tool I use for rapid prototyping). They share roughly 70% of their component tree:

  • Card component with flip animation and swipe gestures
  • Deck selector with category filtering
  • Game modes (Hot Seat, Timed, Classic)
  • PWA service worker for offline play
  • Daily content rotation logic
  • Premium gate and payment flow ($1.99/mo on both)

The key insight: if you build your components around behavior rather than content, reuse becomes trivial. A <GameCard> doesn't need to know if it's holding "I dare you to sing your last text out loud" or "What's a belief you held strongly five years ago that you've since changed?" It just renders text, handles swipe, tracks progress.

Where they diverge

The interesting part isn't the shared code. It's where the products have to be different.

Party Challenges is loud. Bright colors, bold typography, animations that feel like confetti. The "Date Night" deck here means flirty dares and physical challenges. The copy says things like "no boring moments." The whole vibe is Friday night energy.

Here We Ask is calm. Softer palette, more whitespace, slower transitions. The "Date Night" deck here means vulnerability prompts and relationship check-ins. The copy talks about "meaningful connections." Sunday morning energy.

Same component renders both. The theming layer does all the heavy lifting. I use a config object per product that controls:

// Simplified example
const productConfig = {
  theme: 'party' | 'calm',
  cardAnimation: 'bounce' | 'fade',
  deckOrder: [...],
  premiumDecks: [...],
  dailyContentPool: 'challenges' | 'questions',
  copyVariant: 'energetic' | 'reflective'
}
Enter fullscreen mode Exit fullscreen mode

One config swap, entirely different product feel.

What "Date Night" taught me about product positioning

This is my favorite example. Both products have a deck called "Date Night." In Party Challenges, it's cards like "feed each other blindfolded" and "recreate your first date but everything goes wrong on purpose." In Here We Ask, it's "what's something you've never told me but always wanted to?" and "where do you see us in five years, honestly?"

Same feature name. Same UI. Completely different emotional register.

When I show both to people, they often don't realize it's the same codebase. That's the goal. The tech should be invisible. Users don't care about your architecture. They care about whether the product fits their moment.

The portfolio math

Here's where it gets practical. Building the second product took maybe 30% of the effort of the first one. Most of that was content creation (writing 1,000+ questions vs. 1,000+ challenges) and the theming/copy work. The infrastructure, deployment, PWA setup, analytics, SEO patterns... all reused.

I run a portfolio of products at Inithouse. The idea is simple: build small, focused tools and see what sticks. Some of them are AI-powered, like Magical Song (personalized AI songs) or Pet Imagination (AI pet portraits). Others are content-driven, like Vibe Coderi (a Czech vibecoding portal). Each one is an experiment.

The card games taught me that portfolio building isn't just about launching separate products. It's about finding the shared bones across them. Every component you build well once is a component you never build again.

Practical takeaways for builders

Start with behavior, not content. If your component tree is organized around what happens (flip, swipe, filter, gate) rather than what says (dare, question, quote), you can reskin faster than you think.

Theme configs beat feature flags. I tried feature flags first. It got messy fast. A dedicated config object per product is cleaner and easier to reason about. You always know which product you're looking at in the code.

Content is the real work. The tech took weeks. The content took months. Writing 1,000 good party dares is a different skill than writing 1,000 good conversation starters. Don't underestimate this part.

Ship the second product before perfecting the first. I could have spent another month polishing Party Challenges. Instead I shipped Here We Ask while the architecture was fresh in my head. Both products improved faster because fixes in one often applied to both.

What's next

I'm looking at whether this pattern extends beyond card games. Verdict Buddy (AI conflict resolution) and Watching Agents (AI prediction platform) use completely different architectures, but some lower-level patterns (SEO hooks, analytics setup, PWA configs) keep showing up. There might be a shared toolkit hiding in there.

If you're building multiple products, or even thinking about it, I'd love to hear how you handle code reuse across them. Drop a comment or find me on Dev.to.

I'm Jakub, founder of Inithouse. We build a portfolio of small AI and web products, testing ideas fast and seeing what resonates. Party Challenges and Here We Ask are two of about a dozen experiments currently running.

Top comments (0)