Warpdrive architecture,
read from the code.
118,121 lines of source, 2,142 parts described, 5 areas and 24 customer paths. An open-source Pipedrive alternative for sales teams. Every line on this page comes from the model — open it and check any of them.
What the model holds.
The 5 heaviest areas of 5.
| Area | Screens | Actions | API | Records | What it covers |
|---|---|---|---|---|---|
| features | 437 | 1,024 | 70 | 3 | The CRM domain, one folder per feature: deals and pipelines, leads, contacts, activities, email sync/send/tracking, CSV import, enrichment,… |
| app | 188 | 21 | 23 | 0 | Next.js App Router surface: authenticated app pages and layouts, settings screens, the import wizard, OAuth consent and the HTTP route handlers… |
| Shared & root | 20 | 92 | 0 | 69 | Platform core outside the feature folders: Drizzle schema and SQL migrations, the tRPC root and context, the websocket server, realtime publish/relay… |
| scripts | 0 | 74 | 0 | 0 | Operational scripts: demo and smoke-test data seeding and the build step that bundles the standalone worker, websocket, migrate and spam-sweep… |
| components | 63 | 0 | 0 | 0 | Shared React UI kit: dialogs, popovers, tabs, data-table cells, filter builders, skeletons and the app shell pieces reused across features. |
What a person walks through, step by step.
24 paths are described in the model; the longest 12 are here, with how many areas each one crosses.
Bulk-creates persons, organizations, deals, leads or activities from a CSV in four background phases: the file is uploaded to storage and confirmed, parsed into import…
Lets external AI clients act on the CRM as a user: OAuth discovery, optional dynamic client registration, PKCE authorization with an explicit consent screen, token…
Keeps open views live without polling: the client mints a 60-second single-use ticket, authenticates the socket, subscribes to channels it is authorized for, and…
Schedules an activity linked to a deal, lead, person or organization: creation validates references and custom fields, recomputes the parent deal's next-activity date,…
Closes an open deal: markWon/markLost set status and won/lost timestamps (lost with an optional non-archived preset reason and free-text comment), log the status change,…
Keeps each connected mailbox mirrored: the worker polls Gmail history from the stored cursor, applies new messages into threads/messages/attachments, auto-links them to…
Signs a workspace user in through Google OAuth2 with PKCE: the start route mints state/nonce/PKCE, the callback verifies the ID token against the Workspace domain,…
Sends mail from the user's own Gmail with exactly-once semantics: the send is recorded as an idempotent outbox attempt with a deterministic Message-ID, merge fields,…
Fills missing contact data from external providers (Apollo, GetProspect, RocketReach): a TTL-cached run fans out to every usable provider in parallel, merges answers…
Advances a deal through its pipeline: the board moves the card optimistically, the move action does an updatedAt compare-and-swap, validates the stage belongs to the…
Promotes a qualified lead into a deal in one transaction: the deal lands in the target pipeline's first stage carrying labels and custom fields, the lead's notes are…
Prospects new contacts at a company domain: a search-capable provider returns masked profiles badged as new or already held, selected profiles are revealed under…
What the product enforces on its own.
12 rules are described; each one watches a record and changes something else when it moves.
Whenever an activity is created, edited, completed, deleted or carried over from a lead, the parent deal row is locked and its nextActivityAt (earliest open due date)…
After an activity is created, the assignee gets an activity_assigned notification (not on self-assignment), and a pg-boss reminder is enqueued for a fixed lead time…
After a deal is moved to another stage or updated, a best-effort job outside the mutation notifies its followers except the actor (deal_followed_update), or followers…
A deal update writes one change_logs row per field present in the input whose value actually changed (scalars, labels, source channel, custom fields, person/org relink),…
When a deal update re-scopes its visibility group, notification rows are deleted for every recipient who can no longer see the deal, re-checking each recipient's current…
Every deal create, move, update, archive, delete, merge, duplicate or won/lost/reopen publishes a board event inside its transaction: the channel's version counter is…
Recording an open or click tracking event publishes a realtime update to the mailbox owner's channel and, outside the transaction, creates an email_open/email_click…
When sync stores a new inbound message, its thread is auto-linked to the sender's visible person and their open visible deal, an email_arrived realtime event is…
The states records move through.
Import Batches · features
Import batch status
Uploaded → Parsing → Mapping ready → Pending → Validating → Ready → Importing → Completed → Partial → Failed → Undoing → Undone
12 states · 17 transitions
Import Rows · features
Import row status
Pending → Valid → Invalid → Importing → Imported → Skipped duplicate → Failed
7 states · 8 transitions
Email Send Attempts · features
Outbound email send attempt status
Pending → Sending → Sent → Failed → Needs review
5 states · 9 transitions
Deals · features
Deal status
Open → Won → Lost
3 states · 6 transitions
Email Accounts · features
Mailbox connection status
Connected → Disconnected → Error
3 states · 7 transitions
Activities · features
Activity completion
Open → Done
2 states · 2 transitions
Answers nobody wrote down.
Computed from the model’s own connections, with the count behind each one.
How much of this product is built but unused?
26% of this product's API surface is dark: built and paid for, but part of no described customer path and consumed by no screen.
24 OF 93 ENDPOINTS · READ FROM 24 CUSTOMER PATHS DESCRIBED SO FAR
Where is it riskiest to make a change?
The riskiest place to change is “Shared & root”: more of the product depends on Deals than on anything else.
62 INBOUND DEPENDENCIES · COMPUTED FROM THE REACH GRAPH, NOT ESTIMATED
Where did the engineering effort actually go?
The deepest engineering investment is “features” — 73% of the product's mass. “components” is compact and self-contained: the cheapest place to change.
1570 VS 63 OBJECTS · CHANGE-COST RATING = SIZE × CROSS-DOMAIN COUPLING
Which customer experience breaks first?
The most fragile customer experience is “Import records from CSV”: it crosses 3 domains in 22 steps — the first place integration breaks.
INTEGRATION-TEST PRIORITY №1 · DOMAINS COUNTED PER PATH STEP
Does the product lean on any one part?
One subsystem — stats — alone carries 12 core objects. The product leans on it.
CONCENTRATION RISK · COUNTED FROM OWNERSHIP LINKS
Ask the model your own question →How these answers were scored →
About this model.
GitMir read the public repository and established what the product does: its areas, screens, actions, API routes, records, customer paths, status flows and rules, with every statement traceable to the source it came from. Nothing on this page is written by hand; it is the published model, as of 2026-09-23.
This page is a snapshot of the published model. On a connected repository the model is updated as commits land, so people and AI agents work from the product as it is now rather than as it was when somebody last wrote it down.
Yes — connect a repository and GitMir builds the same thing for it: features, rules, customer paths and how they connect, available to people on the screen and to coding agents over MCP.
Supabase Studio architecture →OpenAI Codex architecture →cal.com architecture →Atlas architecture →DroneOps Command architecture →Pronto architecture →Faktorio architecture →