Verdict

Most logic-grid games break trust the moment a board can be brute-forced or guessed through. Verdict started from a stricter promise: every daily case had to be solvable by deduction alone while still working as a habit product people would come back to. That meant the product problem and the engine problem were the same one. Content cadence, archive design, hints, onboarding, and monetization all had to sit behind a generator that could prove a board deserved to ship.

Verdict is live on three platforms. By September 2026 it had passed 1,400 first-time iOS downloads, and registered players had solved more than 7,000 puzzles.

• 1,400+

  first-time iOS downloads

  Through September 22, 2026, excluding redownloads.

• 7,000+

  puzzles solved

  By registered players before September 23, 2026.

• 330+

  registered players

  Players with an account and at least one solved puzzle.

• 3

  live surfaces

  iOS, Android, and web all ship the same core product and entitlement model.

I owned the product and the implementation directly:

• Product shapeDefined the daily loop, archive model, hint philosophy, and the free-versus-Pro boundaries around the habit.
• Engine and backendBuilt the generator, exact solver gate, shared web and mobile engine package, API layer, and persistence model.
• Release and billingHandled App Store and Google Play submissions, RevenueCat and Stripe billing rails, and entitlement reconciliation.
• Post-launch instrumentationSet up analytics, store attribution, and operating dashboards so iteration could follow evidence instead of instinct.

The product only worked if a few hard decisions stayed intact:

• Exact-solver gateA puzzle could not publish unless the solver proved a unique solution, because “probably fine” breaks the whole promise.
• One engine everywhereThe same core logic shipped to mobile and web so surfaces could never disagree about a board or entitlement state.
• Dual billing railsRevenueCat on mobile and Stripe on the web stayed reconciled into one entitlement record instead of splitting the customer experience.
• Hints that teach, not spoilThe product teaches deduction techniques rather than exposing the answer, which keeps the learning loop aligned with the mechanic.

• Difficulty is a design system, not a clue countUniqueness is binary. A trustworthy Easy, Medium, or Hard ladder came from grading solver depth, not just sprinkling more clues around the board.
• Store channels behave differentlyApp Store search can surface a new app quickly on text relevance. Google Play needs installs, retention, and rating proof before it behaves the same way.
• The repair needs review tooRepeatedly, the adversarial pass on my own fixes found more defects in the repair than in the original bug, so review became part of the implementation loop.
• Instrumentation has to exist before the question arrivesPlatform-aware events and verified attribution are what turned post-launch behavior into usable product input instead of anecdotes.
• Let player data set the roadmapReturning-player data showed that discovery, not more game modes, was the constraint, so the roadmap moved from new modes to discovery.