Solvr

Challenge

Building one puzzle game is relatively contained. Building a platform that can support multiple fundamentally different puzzle systems while still feeling like one product is significantly harder.

Each puzzle has its own rules, interactions, validation logic, hint behaviour, difficulty structure, completion conditions, and visual language. At the same time, shared systems such as authentication, progress, statistics, leaderboards, archives, navigation, themes, and responsive layouts need to behave consistently across all of them.

The core challenge became designing the product so that puzzle-specific complexity did not leak into every shared system.

Constraints

Solvr needed to work well for both signed-in and anonymous players, remain responsive across desktop and mobile layouts, and support games with very different interaction models.

Progress also needed to survive refreshes and intermittent network conditions without making normal gameplay dependent on constant server communication. Competitive features had to remain lightweight because Solvr is primarily a casual puzzle product rather than a high-stakes competitive platform.

Another constraint was maintaining a restrained, premium interface while still giving every puzzle enough visual identity to feel distinct.

Research

I analysed existing daily puzzle products and logic-game interfaces to understand how they handled recurring engagement, difficulty selection, streaks, archives, completion feedback, hints, and puzzle discovery.

I also reviewed Solvr's own interface as it expanded. This exposed increasing duplication across buttons, controls, game shells, typography, spacing, and interaction states, which led to a broader design-system audit and a move toward reusable components and tokens rather than styling each screen independently.

On the technical side, I evaluated where state needed to be server-authoritative and where client-side persistence was sufficient, particularly for puzzle progress and completion data.

Iterations

The architecture evolved substantially as more puzzle types and account features were added.

Early versions relied heavily on local browser state. Progress handling was later strengthened with server-backed storage so users could retain puzzle state across devices while still benefiting from fast local interaction.

Leaderboard behaviour was also refined. Instead of introducing a global competitive ranking, Solvr moved toward friends-only leaderboards based on first completions, with assisted solves distinguished from unassisted ones.

Individual puzzle interactions went through their own iterations as well. Trace received improvements to path rendering and rewind behaviour, while other games required puzzle-specific hint systems, validation logic, and visual feedback.

The UI has similarly moved from individual page styling toward a reusable product system with shared controls, tokens, motion patterns, and puzzle-specific accent colours.

Key Features

• Eight different logic puzzle types inside a single platform
• Three difficulty levels per puzzle
• Daily puzzle rotation
• Persistent puzzle progress
• User authentication and account progression
• Friend system
• Friends-only leaderboards
• Completion statistics and history
• Puzzle archives
• Hint and assistance systems
• Responsive desktop and mobile layouts
• Shared design system across otherwise different game interfaces
• Server-backed progress storage
• Automated testing for core functionality
• Deployment through Vercel with Supabase-backed infrastructure

Final Deliverable

Solvr is a functioning full-stack puzzle platform rather than an isolated game prototype. It brings multiple puzzle engines, account systems, social features, persistent progress, and a shared interface into one extensible product architecture.

The platform continues to evolve as I prepare it for broader public use and refine its visual system, puzzle interactions, progression, and supporting infrastructure.

Takeaway

Solvr taught me how quickly product complexity compounds once several individually simple systems begin interacting.

The most valuable work has often been outside the puzzle algorithms themselves: defining boundaries between shared and puzzle-specific code, designing reliable persistence, making state recoverable, creating reusable UI patterns, and deciding which systems genuinely need stronger backend enforcement.

It has also reinforced the importance of treating design systems and architecture as product infrastructure rather than cleanup work to be postponed until the end.