House of Slabs

Technical team

Build a verifiable ripping system, not a thin commerce app.

This brief is for potential employees and external teams. It explains the product architecture, trust boundaries, critical workflows, and the quality bar expected before public launch.

  • Core shapeWeb + API + worker
  • AuthorityPostgres functions
  • ProofReplayable draws

01 / System shape

The system has clear service boundaries from day one.

Public web

Live waves, pack purchase, queue position, reveal, public proof, share pages, and post-reveal decisions.

Admin web

Inventory intake, wave publishing, manual review, RBAC approvals, support context, and exception handling.

API boundary

Hono command/query surface. Business actions call approved domain operations rather than writing tables directly.

Worker service

Outbox dispatch, queue processing, provider webhooks, retry scheduling, reconciliation, and staff alerts.

Core Postgres

System of record with Kysely reads, plain SQL migrations, critical functions, proof metadata, and audit trail.

Pricing indexer

Separate service/database for market observations, confidence scoring, buyback quote inputs, and future data APIs.

02 / Architecture rules

Keep trust-critical logic below the interface layer.

LayerOwnsRule
Experience

Public web, admin web, reveal UX, verifier pages

Never hide proof, state, or next action behind decoration.

Application

Commands, auth mapping, validation, provider orchestration

Keep provider-specific behavior behind typed adapters.

Domain

Wave rules, opening queue, draw algorithm, ledger, inventory lifecycle

Critical transitions are explicit functions with tests and audit events.

Persistence

Postgres functions, constraints, projections, S3 proof/provider archives

Runtime roles cannot directly mutate trust-critical tables.

Async

Outbox, SQS wakeups, retries, webhooks, reconciliation polling

Every external side effect is idempotent and recoverable.

Platform

ECS Fargate, Terraform-managed GitOps, S3 artifacts, environment config

Deployment should be reproducible, observable, and split by runtime boundary.

03 / Critical workflows

Each workflow has an invariant the code must protect.

Inventory to wave

  1. PSA cert captured
  2. Custody state set
  3. Candidate pool built
  4. Wave lock published

Only active available inventory can enter a wave; delivered cards remain history only.

Checkout to openings

  1. Credit hold first
  2. Stripe remainder
  3. Webhook ingest
  4. Openings queued

Duplicate webhooks cannot duplicate payments, ledger debits, or openings.

Opening to proof

  1. Queue lock
  2. Randomness request
  3. Deterministic selection
  4. Proof bundle stored

A paid opening produces at most one valid draw result, replayable forever.

Pulled card to outcome

  1. Reveal
  2. Deliver / buy back / decide later
  3. Deadline handling
  4. Inventory or shipment finalizes

Buyback acceptance credits store credit and resolves the pulled card atomically.

04 / Scope boundaries

The MVP is ambitious, but not everything belongs in release one.

MVP includes

  • Live waves with locked public pools
  • Verified email checkout and Stripe/store-credit tender
  • Open-time verifiable randomness and public replay
  • Delivery, store-credit buyback, and decide-later resolution

First release excludes

  • Cash withdrawals and user-to-user marketplace
  • Public pricing API and native mobile app
  • Kubernetes production deployment
  • Blockchain or on-chain randomness/proof

Gated before launch

  • Legal framing, jurisdictions, age policy, odds wording
  • Stripe approval, tax codes, accounting categories
  • Randomness, shipping, auth, fraud, and pricing providers
  • Hot-drop load targets and live support readiness

05 / Trust and failure model

The hard parts are money-like, physical, public, and async.

SurfaceEngineering requirementFailure rule
Draw proof

Versioned algorithm, randomness provider proof, pre-draw pool state, selected cards, proof hash.

Do not consume cards if randomness/provider work fails before the atomic result write.

Store credit

Immutable ledger entries, holds, debits, credits, source detail tables, reconciled balance projection.

No direct balance edits and no double spend across concurrent checkouts.

Inventory custody

Unique active PSA certs, owner/bin/status lifecycle, pulled-card decisions, exception states.

A draw cannot select unavailable, pulled, delivered, replaced, or removed inventory.

Provider payloads

Sanitized contract fixtures, typed errors, raw archive for critical Stripe/randomness/shipping/PSA data.

External retries must be idempotent and manually recoverable.

06 / How we build

Delivery is slice-based, but trust is reviewed end to end.

Database confidence

Real Postgres CI for migrations, SQL functions, constraints, permissions, and locking behavior.

Replay confidence

Deterministic draw/verifier tests cover old algorithm versions, depleted tiers, slot order, and proof hashes.

Provider confidence

Recorded contract fixtures and typed adapter errors for Stripe, randomness, shipping, PSA, Resend, and pricing.

Product confidence

Playwright covers browse, auth, checkout, queue, reveal, delivery, buyback, verifier, admin, and support flows.

  1. Small vertical slices: schema, domain function, UI state, tests, admin/support path.
  2. RFC before trust-critical changes: ledger, draw/proof, inventory lifecycle, RBAC, provider contracts.
  3. Every async workflow gets idempotency keys, retry policy, dead-letter posture, and reconciliation notes.
  4. Every public claim has a data source: no marketing copy that the system cannot prove or reconstruct.
  5. Design and engineering review the same states: loading, empty, held, failed, manual review, completed, audit.

07 / Team fit

We need builders who enjoy constraints, evidence, and operational detail.

Backend / database

Strong Postgres, SQL functions, transactions, row permissions, event modeling, and financial-style ledgers.

Frontend / product

Next.js, state-rich flows, accessible reveal UX, admin tools, proof pages, and high-signal operational UI.

Platform / integrations

Provider adapters, webhooks, queues, Terraform/AWS posture, observability, security, and incident recovery.

Preferred stackTypeScript, Next.js, Hono, Kysely, Postgres
Security postureRBAC, MFA admin, audited approvals
Launch barProof, payments, ledger, delivery tested