karti de33a03524 Add the web app, seed data, and user-selectable theming
apps/web — React, Vite, Tailwind, shadcn-idiom components. Mobile Safari is a
first-class target, not an afterthought:

- Two navigation treatments rather than one compromise. A bottom tab bar on
  phones, because the top of a large phone is out of thumb reach; a persistent
  sidebar from lg upward, so an iPad in portrait gets it too.
- Safe-area insets throughout, so the tab bar clears the home indicator and the
  last row of a list is actually reachable.
- Inputs are pinned to a 16px minimum, which is the correct fix for Safari
  zooming on focus. user-scalable=no is not used: it breaks pinch-zoom for
  everyone and recent iOS ignores it anyway.
- The pipeline board becomes a stage picker on phones. An eight-column board
  scrolling horizontally on a 390px screen is technically responsive and
  practically useless.

Theming: users pick an accent and the whole interface re-tints. Accent values
live once, in @pig/core, and are written onto the root element at runtime —
there is no CSS copy to drift from the TypeScript. Preferences are stored
server-side so they follow a person between laptop and phone, mirrored into
localStorage only so the pre-paint script can avoid a white flash. Status
colours stay fixed regardless of accent: if "at risk" re-tinted to whatever
someone picked, the signal would be gone.

Seed data is public research, every record carrying a confidence grade and a
source URL. No email addresses are seeded or inferred — none are published, and
guessing them from a name and a domain is unreliable and rude. Authorship is
not promoted to employment: contributors, residency participants and alumni are
recorded as what the evidence actually shows, and a name that could not be
sourced at all is listed as unresolved rather than invented.

Three defects found and fixed by actually running it rather than assuming:

1. The seed was not idempotent. onConflictDoNothing() with no target is a no-op
   without a matching unique constraint, so a second run duplicated 27
   contacts. There is deliberately no unique index on (account, name) — two
   people at one company can share a name — so idempotency is enforced in the
   seed instead of by bending the schema.
2. /capacity scrolled sideways on a phone. Grid items default to
   min-width:auto and `truncate` sets nowrap, so a long title became
   unshrinkable content and widened the track. Fixed with min-w-0 on every
   truncating grid child.
3. The idle-capacity alert silently failed to fire at exactly 80% utilisation,
   losing a float comparison against a 0.2 threshold. Moved to 0.15, which is
   also a more sensible line for "worth attention".

The worked example is tuned to teach rather than to flatter: 70% sold at a 53%
markup lands at +6.7% margin with 20% still idle, so both the healthy number
and the alert are visible. Drop the sold share to 55% and the same block goes
underwater — that sensitivity is the argument for the product.

Verified in a real browser at 393px and 1440px, light and dark: zero horizontal
overflow on every route, zero console errors.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-12 19:16:43 -07:00

🐷 PIG — Prime Intellect Growth

An open-source, agent-native CRM for two-sided AI-compute companies.

License: Apache 2.0

Self-hostable. Auditable. Built for teams that buy compute on one side and sell it on the other.


Why this exists

A company that aggregates GPU capacity and resells it does not run one pipeline. It runs two, and its business is the spread between them.

Generic CRMs — Salesforce, HubSpot, Attio — model a single pipeline of deals against companies. They have no concept of inventory, no concept of a commitment you already bought and are paying for, and therefore no way to answer the question the business actually turns on:

Which contracted capacity is sold, to whom, at what margin — and what is idle right now?

PIG is built around that question. One table, allocations, joins a capacity_commitment (what you bought from a provider) to a demand_deal (what you sold to a customer). Revenue minus cost is margin per GPU-hour. Committed capacity with no allocation is money burning. Everything else in PIG is ordinary CRM plumbing that exists to keep that ledger honest.

Who it's for

PIG models three teams, because two-sided compute companies have three constituencies competing for the same scarce capacity:

Team Job to be done
Supply Source, qualify, price, and contract GPU capacity from providers
Demand Sell compute and post-training; renew and expand accounts
Research Consume capacity internally — real burn, no revenue

Research is a first-class tenant rather than an afterthought. Internal research burn competes with revenue for the same GPUs, and margin math that cannot see it is wrong.

The team set is configurable. PIG ships with these three because they match the structure of the company it was designed for, not because they are universal.

Agent-native, not agent-decorated

PIG is a first-class application for agents and for humans, and neither is a degraded view of the other.

  • An MCP server (apps/mcp) exposes the CRM over both stdio and Streamable HTTP. Any MCP client connects: Claude Code, Codex, prime-agent, or a Buzz workspace agent via its ACP bridge. Each team member points their own agent at PIG and works from the terminal.
  • Piggy, the in-app agent, drains a leased database queue rather than being called over HTTP — so work survives the agent being down, and every action it takes is recorded with an idempotency key.
  • Every agent-derived fact carries evidence. Enrichment writes to a facts table with a confidence score, a band (verified / probable / possible), a source URL, and a status. Strong signals apply automatically; weak ones become proposals a human approves. A CRM that lets an agent write unattributed claims into the record is a hallucination store, not a database.

The architectural rule

Intelligence never lives in the API.

The API does HTTP, auth, validation, and sync. All research, enrichment, scoring, and identity matching lives in the agent. They communicate through a table, never a direct call. This separation is borrowed from Comp AI CRM and it is the single most load-bearing decision in the codebase.

What makes it compute-native

  • inventory_listings mirrors the Prime Intellect availability API field-for-field — gpuType, socket, interconnectType, stockStatus, security (secure vs community cloud), prices.onDemand, provisioningTime. Sync is a straight mapping, not an ETL project.

  • capacity_commitments records what you bought: term, GPU-hours, cost per GPU-hour, floor and ceiling.

  • contracts is polymorphic over party and type — MSA, DPA, SLA, order form, capacity commitment — because the supply side negotiates heavyweight paper while the self-serve demand side runs on a reliability tier and a credits policy instead of a signed uptime guarantee.

  • Two real pipelines, with stages taken from how this market actually operates rather than invented:

    Demand:  qualification → legal → scoping → proposal → procurement
             → POC → deployment → expansion
    
    Supply:  sourced → qualifying → technical diligence → financial diligence
             → pricing → contracting → onboarding → live → renewal
    

    Note that legal sits second in the demand pipeline. MSA and DPA execution gates the deal rather than closing it. Most CRMs put contracts at the end and are wrong about it for this market.

Stack

Layer Choice
Web React + Vite + TypeScript, Tailwind, shadcn/ui, light + dark
API Hono + tRPC on Node 22+
Database PostgreSQL 16, Drizzle ORM
Auth Supabase (JWT verification only — PIG stores no passwords)
Agent Piggy — a worker draining a leased task queue
MCP @modelcontextprotocol/sdk — stdio + Streamable HTTP
Deploy Docker Compose behind any reverse proxy

Authorization comes from PIG's own users table, never from the mere existence of an auth account. An identity provider that PIG shares with another application must not grant access here.

Quick start

git clone <this-repo> pig && cd pig
npm install
cp .env.example .env        # then edit it
npm run db:migrate
npm run db:seed             # optional — public, sourced, confidence-graded
npm run dev:api             # :8920
npm run dev:web             # :5173

Connect an agent:

claude mcp add pig -- npx -y @pig/mcp          # stdio
# or point any MCP client at https://<your-host>/mcp

Repository layout

apps/
  web/        React + Vite front end
  api/        Hono + tRPC API, Supabase JWT verification
  mcp/        MCP server — stdio and Streamable HTTP
packages/
  db/         Drizzle schema, migrations, seed
  core/       Shared domain types and the ontology
  prime/      Typed client for the Prime Intellect compute API
docs/         Ontology, deployment, seed-data provenance
deploy/       Compose files and reverse-proxy snippets

Documentation

A note on seed data

PIG ships with a roster of publicly documented people so the application is legible on first run. Every record carries a confidence grade and a source URL. No email addresses are included or inferred. Records that could not be independently sourced are marked as such rather than quietly presented as fact, and people who are demonstrably not staff — alumni, residency participants — are labelled accordingly. See docs/seed-data.md.

If you are seeded here and would rather not be, open an issue and it will be removed.

Licence

Apache License 2.0 — see LICENSE and NOTICE.

S
Description
PIG - Prime Intellect Growth. An open-source, agent-native CRM for two-sided AI-compute companies.
Readme Apache-2.0 7.8 MiB
Languages
TypeScript 97.2%
JavaScript 1.1%
Shell 0.9%
CSS 0.4%
HTML 0.2%
Other 0.2%