For several weeks, the Blupoli home page has described a platform designed to grow beyond a single product. Until now that idea had one concrete playable expression: Blupoli Puzzles. The rest of the architecture — the Blog, the Devlog, a product registry, shared navigation and separate domains — showed how another product could eventually join without forcing us to rebuild everything around it. Blupoli Cards is the first real test of that promise. We are no longer talking about room for a second product. That product exists at cards.blupoli.com, and it starts with five playable solitaire games.
The launch collection includes Klondike, Spider, FreeCell, Pyramid and TriPeaks. They are familiar names, but they do not ask the player to think in the same way. Klondike mixes construction with discovery. Spider turns column space into a strategic resource. FreeCell exposes almost all information from the start. Pyramid is about availability and pairing. TriPeaks rewards chains and momentum. Together they give Cards a more useful starting identity than five near-identical variations of the same deal.
Why Cards is not simply another category inside Puzzles
The first design question was also the most important one: if Blupoli already has a large games product, why create another? The answer is less about technology than about product boundaries. Blupoli Puzzles brings together logic, deduction, strategy and related puzzle mechanics under one catalogue, one discovery model and one set of expectations. Solitaire shares some platform needs — sessions, persistence, accessibility, themes, future statistics — but it brings its own language and structures: decks, waste piles, foundations, free cells, tableau columns, deals, runs and rule variants.
We could have put all of that under Puzzles. It would have been easier in the short term because the navigation and hosting already existed. It would also have made every future decision harder to reason about. A Cards-specific feature would have to be justified inside the Puzzles information architecture, and Puzzles would slowly become a generic container for anything playable. Giving Cards its own product boundary lets it grow around card-game concepts without asking Puzzles to absorb them. At the same time, Cards is unmistakably part of Blupoli: it appears on the main home page, shares brand and platform navigation, links into Blog and Devlog, and follows the same browser-first approach.
Five games first, rather than a catalogue full of promises
A new games site can look impressive very quickly if it lists dozens of names and marks most of them as “coming soon.” We chose the opposite. The first Cards catalogue contains five entries because every one of those entries opens a real game. That follows the same direction we have been taking with Puzzles: the size of a catalogue matters less than the honesty of the playable surface. A small set of complete destinations teaches us more about the product than a large mock catalogue.
Those five games were also chosen because they stress different parts of the foundation. Klondike needs stock, waste, foundations and a seven-column tableau. Spider uses two decks and a much denser ten-column layout. FreeCell introduces temporary storage and open information. Pyramid depends on explicit covering relationships. TriPeaks uses a different irregular geometry and a rank relationship to the waste card. If one application can express those five shapes without each one feeling like a separate website, we have something worth extending.
Klondike: the unavoidable reference point
For many people, “solitaire” means Klondike even if they have never used the name. Seven tableau columns, hidden cards gradually exposed, a stock and waste pile, and four suit foundations form one of the most recognisable card-game layouts on a computer screen. That recognition makes Klondike a useful quality test. If card size, selection feedback or the overall rhythm feels wrong here, the product cannot hide behind novelty.
Our first version focuses on the central loop: uncover cards, move exposed cards according to tableau rules, open empty columns with Kings, draw from stock and waste, and build foundations from Ace upward by suit. The game also restores its local state, tracks moves, starts a clean new deal on request and offers a short hint when you need orientation. We are not claiming that this V1 implements every historical Klondike variation or every convenience feature found in a dedicated desktop client. The purpose is narrower and more useful: a coherent playable baseline that fits the rest of Cards and can be deepened without throwing away its model.
Spider: space becomes part of the puzzle
Spider changes the tempo immediately. Ten columns fill the table, and the work happens inside descending sequences rather than visible suit foundations. The first Cards version uses a one-suit, two-deck setup, giving the player the core structure of Spider while keeping the launch experience approachable. Complete King-to-Ace runs are removed, and the aim is to clear eight of them.
Spider is valuable to the product even beyond its rules because it forces us to confront density. Ten columns put pressure on every assumption about card width, horizontal space, touch targets and small-screen behaviour. A card size that is comfortable in Klondike can become impossible in Spider on a compact laptop. That makes Spider a useful design constraint: Cards has to behave like a collection that understands different table shapes rather than a single layout with renamed rules.
FreeCell: almost everything is visible, so planning matters more
FreeCell contributes a different kind of decision-making. Almost the entire deal is visible from the first moment. The uncertainty of face-down cards disappears, and in its place comes a resource-management problem. Four free cells can temporarily hold cards, while empty cascades create valuable working space. The foundations still grow by suit from Ace to King, but the route there feels very different from Klondike.
That contrast matters because it prevents the launch set from being five visual skins over one mechanic. In FreeCell, occupying a free cell can make the next few moves easier while reducing longer-term flexibility. The interface therefore has to make the distinction between cascades, cells and foundations obvious without relying on a long rules screen. The first version supports exposed-card moves, alternating-colour descending placement, four free cells and suit foundations. Later iterations can deepen multi-card sequence movement and advanced conveniences, but the strategic identity is already present.
Pyramid: the table becomes a dependency graph
Pyramid breaks away from the column metaphor completely. Cards overlap in a triangular structure, and only uncovered cards can participate in a move. The central rule is easy to explain: remove pairs whose ranks total thirteen, with Kings removable on their own. That simple rule produces a game where order and availability matter as much as arithmetic.
From an implementation perspective, Pyramid is useful because there is no single “top card of a stack” to query. The game needs to understand covering relationships between positions and update availability as lower cards disappear. Stock and waste provide another source of cards for possible pairs. Clearing all twenty-eight pyramid cards completes the game. In product terms, Pyramid proves that the Cards table cannot be hard-coded around vertical piles alone; the same visual system must be able to support a geometry driven by relationships.
TriPeaks: speed, chains and a different kind of flow
TriPeaks rounds out the first collection with something lighter and more rhythmic. Three overlapping peaks are gradually uncovered as lower cards disappear. You can play any exposed card that sits one rank above or below the waste card, regardless of suit. When no continuation is available, you draw from the stock and try to start another chain.
The pleasure comes from momentum. One move can expose another useful card, which extends the chain and opens more of the table. That makes TriPeaks a strong counterpoint to the slower spatial planning of Spider or FreeCell. It also gives the UI another irregular layout to handle. Three peaks eventually feed into a shared lower row, so the visual structure is neither a standard tableau nor a single pyramid. Having TriPeaks at launch makes it clear that Cards is intended as a product for multiple solitaire families, not “Klondike plus a few settings.”
One shared frame around five different mechanics
All five games use the same surrounding structure. Cards has its own header, a direct route back to the catalogue, links to Puzzles and the wider Blupoli platform, a game title and explanation, New Game and Hint actions, a status bar with move count, and a dedicated play table. Once you learn where those controls live, switching games does not require relearning the entire application.
The table itself remains mechanic-specific. Klondike exposes stock, waste, foundations and seven columns. Spider needs ten columns. FreeCell places temporary cells and foundations at the top. Pyramid and TriPeaks use positioned geometries. This is a principle we already value in Blupoli Puzzles: consistency is most helpful around the reasoning surface, not when it forces every board to look identical. Shared chrome lowers friction; specialised layouts preserve the information each game needs.
Continuity without requiring an account
Cards launches without a sign-in wall. That does not mean every visit has to lose the previous session. Each of the five games stores its current state locally in the browser, using a game-specific key. The structures needed to rebuild the table, the current move count and the relevant piles can be restored when you return. Starting a new game explicitly clears the previous saved deal.
This is intentionally local persistence. We are not describing cross-device sync or remote accounts as features that already exist. What exists today is useful continuity on the same device and browser. We prefer that clear boundary to talking about future infrastructure as if it were product. If a shared Blupoli account and synchronization layer arrives later, Cards will already have a real session model to connect to it rather than forcing the backend to define a concept nobody has tested yet.
Cards changes the main Blupoli home too
The launch is not confined to cards.blupoli.com. It changes blupoli.com because the platform now genuinely has two playable products. The home page had already been redesigned around a canonical product registry and an ecosystem visual that left space for something beyond Puzzles. Cards now fills that space with a real name, a real destination and real games.
The product catalogue renders Puzzles and Cards from the same source. The top navigation includes Cards. The shared footer points to both product domains. The hero provides direct routes into both. Copy that used to describe Puzzles as the first visible product has been revised so it no longer implies the platform still has only one. This is the moment where architecture stops being a diagram and becomes behaviour: adding the second product should require extending a system, not replacing a page built around an assumption of one.
A dedicated subdomain makes the product promise clearer
cards.blupoli.com is more than branding polish. It makes the product boundary visible. Inside Cards, the catalogue, language of the UI and future features can revolve around card games. Inside Puzzles, discovery can continue to revolve around logic and strategy. At blupoli.com, the platform can connect both products with editorial work without pretending they belong to one giant catalogue.
The separation gives future decisions room to diverge. Cards may need deal options, deck themes, solitaire families, undo history or card-specific statistics. Puzzles may continue investing in puzzle engines, onboarding and category-based discovery. Those are not contradictions. A useful platform shares identity, navigation, deployment patterns and quality practices where they help while letting domain-specific concepts stay where they belong.
Search foundations from the first release
Cards does not hide every game behind one JavaScript route. The home has a stable canonical URL, and every solitaire has its own page under /games/. The generated sitemap lists the home and all five games. robots.txt points search engines to that sitemap. Game pages include social metadata and VideoGame structured data. This is not an attempt to manufacture search traffic before the product has substance; it is simply a decision not to accumulate avoidable discovery debt on day one.
Stable routes also make the editorial layer more useful. This article can point directly to each game. The companion Cards architecture Devlog can explain the implementation and still send readers to the live product. Cards links back to both stories. That loop between product, Blog and Devlog is part of how we want Blupoli content to work: useful pages should explain and reinforce one another instead of existing as isolated endpoints.
What this first release intentionally does not try to solve
A useful V1 needs edges. Cards does not yet attempt to cover every historical rule variant of its five games. It does not have accounts, remote synchronization, deep statistics, daily challenges, elaborate animations, advanced drag and drop or a huge taxonomy of solitaire families. Some rules and movement conveniences can still be expanded, especially where desktop solitaire players expect richer sequence handling or deal options.
Those omissions are deliberate rather than hidden. The next useful work is to strengthen the common experience we can already observe: card legibility, touch behaviour, move feedback, resume reliability, responsive table sizing, keyboard accessibility and performance. Once those patterns are proven across several mechanics, we can decide which ones deserve shared infrastructure. Building a large abstraction before the games expose the real need would only make the architecture look mature while moving uncertainty somewhere harder to see.
The next step is depth, not merely another row of game cards
There are many obvious candidates for a future Cards catalogue: Yukon, Golf, Scorpion, Canfield, Forty Thieves and entire families of related variants. They can come later. The more interesting immediate work is making the first five better: smoother interactions, clearer legal-move feedback, stronger hints, accessible keyboard behaviour, touch-first refinements, meaningful statistics and animations that communicate state without turning every action into a delay.
Discovery will also become a real product problem as the catalogue grows. With five games, a simple grid is enough. With fifteen or twenty, we will need to decide how players browse: by family, expected duration, information visibility, deck count, difficulty or another useful dimension. We would rather learn those categories from a real collection than invent a taxonomy before we have enough games to know whether it helps anyone.
Why the second product matters more than its size
Cards is intentionally small compared with what it could become. That is exactly why it matters architecturally. The first product on a platform can benefit from hidden one-off assumptions: a route written directly into a template, a card designed only for one destination, a footer that really knows about a single subdomain. The second product removes that comfort. It forces the platform to prove that “products” was a real category and not just a nicer word for Puzzles.
The Blupoli home now has two playable destinations. The product registry contains two entries. The footer exposes two product domains. Hosting has three public surfaces: the main platform, Puzzles and Cards. Blog and Devlog can describe the same launch from different perspectives. Each one of those changes is small, but together they turn a design intention into a working system.
Two products do not have to grow at the same pace
Separating Puzzles and Cards also lets us accept a simple reality: each product can need a different cadence. Puzzles already has a broad catalogue, many logic families and shared infrastructure refined over months. Cards begins with five games and a much smaller foundation. Requiring both to have the same feature count, navigation depth or maturity on day one would confuse platform coherence with artificial symmetry.
We want the shared pieces to be the ones that genuinely deserve to be shared: Blupoli identity, product-to-product navigation, publication quality, accessibility principles, clear content discovery and a verifiable deployment process. Beyond that, each product can specialise. Cards can spend its next cycle on card interaction, rule variants, animation and solitaire-specific statistics while Puzzles keeps improving generation, onboarding or progress analytics. That independence reduces pressure to invent abstractions too early and makes it easier to judge every change by the problem it actually solves.
It also makes the main Blupoli home more honest. The page does not pretend that two products are at the same level of maturity; it presents them as two real destinations inside a platform that can support different rhythms. Cards does not need to look as large as Puzzles in order to justify itself. It needs a clear experience, its own direction and evidence that it can grow without forcing the rest of Blupoli to change with every card-game decision.
How to choose your first game
If you want the most familiar route in, start with Klondike. If you prefer planning with almost all information visible, try FreeCell. If long descending sequences and column management are the appeal, Spider changes the rhythm completely. Pyramid is a compact pairing game, while TriPeaks works well when you want a faster chain-driven session.
All five live at Blupoli Cards. If you are more interested in how a second product was added to the monorepo, Firebase Hosting, CI and shared product registry without being folded into Puzzles, read the technical Devlog. And if you want the earlier context for why the home was already structured for this moment, the article about turning the Blupoli home into a product platform explains the groundwork.
A platform becomes credible when growth stops being hypothetical
It is easy to say that an architecture is “ready for more products” while there is still only one. The claim becomes meaningful when the second one arrives and the existing system has to absorb it. Cards has already exposed several places where the platform had to become more honest: navigation needed a second product destination, the hero’s future node had to become a real node, the footer had to understand multiple domains, and the public copy had to stop describing Puzzles as though it were still the only visible product.
Those are healthy pressures. They make Blupoli less dependent on assumptions that happened to be true during the first phase. Cards is therefore two things at once: a place to play solitaire, and a practical test of whether the platform can grow without losing clarity. The games are the part you can click today. The architecture is what should make the sixth, tenth or twentieth addition easier to build without turning the whole project into a collection of exceptions.