Back
FlagshipProduct systems case study

First Revenue Game

A social execution product where commercial evidence—not activity inside the app—controls progression, backed by an authoritative Java/Spring workflow and recoverable event delivery.

Date

2026

Status

Configured runtime verified

Audience

Builders + operators

Scope

Independent build

Next.jsJava / SpringPostgreSQLKafkaOpenTelemetry
41
Vitest checks
35
Playwright passes
34
JUnit + Testcontainers
1
Configured golden path
First Revenue Game landing page explaining its mission-first revenue workflow
The promise stays narrow: move one monetizable skill toward a paid outcome, and count only evidence that leaves the product.
01Product constraint

Progress had to mean market evidence.

Solo builders can mistake planning, content, and community activity for commercial movement. I constrained the product to one active mission, one of three revenue paths, external proof, a small accountability pod, and an operator decision before XP or milestones change.

I owned the product direction, interaction model, Next.js shell, Spring workflow boundary, authorization, event reliability, observability, tests, and release evidence as one system.

Primary member

A solo builder turning an existing skill into a first paid audit, service, or concierge MVP.

Operator duty

Judge the submitted artifact, explain rejection, and unlock only milestones that the evidence supports.

02Member + operator loop

Recovery is a product feature

Reject, revise, approve—without stale state.

The operator reviews the same evidence the member submitted. Rejection reopens a clear path; resubmission clears the stale decision; approval derives progression from authoritative state.

  1. 01

    Receive one mission

    A commercially specific action stays central instead of becoming one item in a generic backlog.

  2. 02

    Submit external proof

    A link, outcome signal, and proof standard connect activity to observable market contact.

  3. 03

    Review exact evidence

    Submission locks the evidence while an operator accepts it or gives an actionable rejection note.

  4. 04

    Recover or progress

    Rejection reopens revision; approval unlocks only the XP and milestones the evidence supports.

Member proof locked in pending review state
Server-confirmed pending proof locks the exact evidence under review.
Operator proof review queue
The operator sees the artifact, outcome signal, note, and supported unlocks together.
03Migration architecture

One vertical slice, not a rewrite.

Configuring the backend changes the repository implementation, not the product-facing UI contract. Demo mode remains useful; configured mode proves authoritative backend ownership.

Current configured architecture from Next.js through Spring Boot, PostgreSQL, Redpanda, MinIO, and observability services
Demonstrated components only. Redis is not drawn until it owns an active workload.

  • Product shell

    Next.js

    Pages, interaction, session resolution, and the migration BFF preserve one product-facing contract.

  • Workflow authority

    Spring Boot

    Application, member, proof, pod, operator, billing-read, and artifact APIs own configured-mode rules.

  • Durable state

    PostgreSQL + Flyway

    Domain changes and their outbox intent commit together under versioned schema ownership.

  • Reliable facts

    Redpanda + projections

    Recovered delivery and event-ID idempotency keep replay from awarding progression twice.

04Trust + reliability

The backend earns its complexity.

Each infrastructure choice protects a visible product promise: the right person reviews the right proof, a successful command does not lose its event, and replay cannot double-award progress.

Identity crosses the BFF as a signed assertion.

Next.js sends a short-lived viewer claim with an internal token. Spring verifies it, applies route roles, and scopes resource queries to the authenticated owner.

Events cannot outrun the state they describe.

A transactional outbox closes the database/Kafka dual-write gap, reclaims interrupted work, retries with bounds, and exposes a dead-letter state.

Proof ownership comes before file access.

Spring resolves member or operator permission before issuing a five-minute MinIO URL, while cross-user requests retain a not-found boundary.

Grafana First Revenue Operations dashboard
The configured path closes on measured latency, errors, outbox state, and projected workflow events.
05Operational evidence

Observability is part of the feature.

  • Runs a real application-to-approval workflow against the configured services.
  • Waits for the transactional outbox to drain and confirms the BFF reads Spring-owned state.
  • Checks request, error, backlog, and projection metrics plus the provisioned Grafana dashboard.
  • Fails if secrets, signed assertions, generated applicant email, or private payload data appear in logs.
06Narrated walkthrough

Product loop to runtime proof in 87 seconds.

Inspect source
07Honest boundary

What this does not claim.

  1. 01No hosted production environment or production identity deployment is claimed.
  2. 02The recorded golden path uses link proof; file proof is verified separately through storage and permission tests.
  3. 03Redis is readiness-checked but intentionally absent from the active diagram because no current workload depends on it.
  4. 04Alert routing, SLO ownership, trace retention, scaling policy, and incident ownership remain production work.
EvidenceCase-study record

Configured runtime verified

What the work proves.

Help solo builders move one monetizable skill toward first revenue without rewarding planning theater, while ensuring that progression changes only when submitted proof supports it.

Role

  • Independent product direction, UX/UI, Next.js shell and BFF, Java/Spring domain workflow, event reliability, observability, testing, and release evidence

User

  • Solo builders pursuing a first paid outcome, and operators responsible for reviewing commercial evidence and unlocking supported progression.

Key decisions

  • Centered the member experience on one commercially specific mission, external evidence, and an explicit reject-revise-approve recovery loop.
  • Migrated the authoritative workflow one vertical slice at a time, preserving the Next.js product contract while Spring Boot took ownership in configured mode.
  • Signed short-lived viewer context across the BFF boundary and enforced role plus resource ownership inside the backend.
  • Committed workflow state and event intent atomically through a transactional outbox, then made projections idempotent by event ID.
  • Resolved proof ownership before issuing short-lived MinIO access and kept operational telemetry free of secrets and applicant data.

Verification

  • Forty-one Vitest tests and 35 passing Playwright checks cover the product shell, API contracts, responsive behavior, and member/operator workflow.
  • Thirty-four JUnit and Testcontainers tests exercise the backend against real PostgreSQL and Redpanda services.
  • The configured verifier proves application-to-approval state, BFF reads, outbox drain and recovery, custom metrics, Grafana provisioning, and log privacy.

Limitations

  • The configured runtime is verified locally; no hosted production environment or production end-user identity deployment is claimed.
  • The demonstrated golden path uses link proof. MinIO file handling is verified separately through permission and storage coverage.
  • Redis is readiness-checked but owns no product workload, and production SLOs, alert routing, retention, scaling, and incident ownership remain open.
MoreCurrent case studies

Explore the other current projects where product thinking is carried through interface, architecture, testing, and release.