The living database and website behind bigtech.sucks. Every score traces to a reproducible artifact.
Find a file
CLU 76e3e6c0f2 feat: the closed-source rule, and the board
Christian, 2026-10-29: 'Closed source software, you have no idea. And then all
we have is reputation. So you kind of start with one arm or two arms tied
behind your back.'

That is now arithmetic instead of an opinion.

- assessment.source_available: 1 = we can read the code, 0 = we cannot.
- Closed source cannot exceed 5 on ANY dimension without tier-1 or tier-2
  evidence of kind 'capture' or 'filing'. Reputation is tier 3, and tier 3 is
  not a measurement. The build fails if a closed-source score breaks the rule.
- Verifiability still caps at 3 with no reproducible build.

Practical ceiling for closed source: 86/100 in theory, if every dimension is
backed by a capture or a court filing. In practice it is a fight for a C.

- product.priority puts a human's ask ahead of a crawler's discovery.
- v_backlog orders by priority, then measured usage.
- migrate(): the database authors itself, so it must survive its own schema
  changes. Add columns, drop views, let schema.sql recreate them. Never drop
  and rebuild, which would destroy the self-authored roster.

On the board: Slack (closed, capped) and Kino (closed, capped, founders call
2026-10-30 17:00). Neither is scored. Neither gets a number until it has
evidence.
2026-10-29 15:23:31 -05:00
packages feat: the closed-source rule, and the board 2026-10-29 15:23:31 -05:00
.gitignore bigtech.sucks: living database + first assessment 2026-10-29 13:16:29 -05:00
package-lock.json bigtech.sucks: living database + first assessment 2026-10-29 13:16:29 -05:00
package.json feat: self-authoring ingest, relevance gate, and the Ranch Oath 2026-10-29 13:23:57 -05:00
README.md docs: document the living-database workflow and its enforced rules 2026-10-29 13:17:21 -05:00

bigtech.sucks — Draw the Line

V0.1 scaffold per master spec. A retro frontier game that scopes Big Tech exposure and sequences the off-ramp.

Structure

packages/
  core/     Render-agnostic game logic, seed data, scoring
  core/db/  The living database: schema, seeds, build + verify
  web/      React + Vite SPA (V1 funnel)
  server/   Minimal waitlist API (email + channel only)

The living database

The database is the source of truth. The site is a view over it. Nothing in the UI may hardcode a number that lives in bigtech.db.

npm run db:build     # rebuild the db, apply seeds, verify, regenerate the catalog
npm run db:verify    # run the instrument's own checks against the existing db

packages/core/db/bigtech.db is built, not committed. What is committed is the part that matters: db/schema.sql, db/seed/*.sql, and db/build.mjs.

The build refuses to pass if a score breaks the instrument's own rules:

  • dimension weights must sum to 100
  • every stored weighted_total must recompute from its scores
  • every grade must match its band
  • every score must carry a written rationale
  • no tier-4 claim may attach to a scored dimension
  • the reproducible-build caps are enforced, not documented: no reproducible build caps verifiability at 3, an experimental one at 6

A product with no assessment surfaces as unassessed. It is never given a guessed number. That is why the 43 legacy roster entries sit in the database as placeholders and exactly one product carries a real score.

Adding an assessment

  1. Write packages/core/db/seed/000N-<slug>.sql using the shape in 0001-signal.sql.
  2. Every score needs a rationale and at least three tier-1 or tier-2 evidence rows.
  3. npm run db:build. If it fails, the report is not ready to publish.

What the numbers mean

See the instrument spec. Scores are 0 to 100, and a weighted average is not the headline: the weakest dimension is, because a 90 with a 5 on local data exposure is a 90 that will leak.

Quick start

npm install
npm run build -w @bigtech-sucks/core
npm run dev          # web on :5173
npm run dev:server   # waitlist API on :3001

V1 flow

Welcome → Meet Red → Draw the Line → Overworld → Showdown → Homestead → Reveal (Binary Ranch) → Waitlist

Governance

  • Creative assets are candidates — director approval required before ship
  • Company name revealed only at homestead/reveal phase
  • §13 open decisions are not silently resolved (see packages/core/src/data/config.ts)
  • Client-side sovereignty report; server stores waitlist fields only

Roadmap

  • V1.5: Terminal/SSH render (Go + Charm)
  • V2: Concierge migration, journey chronicle, physical fulfillment (stubs in v2-stubs.ts)