Faktorio architecture,
read from the code.
27,422 lines of source, 287 parts described, 3 areas and 19 customer paths. Invoicing for self-employed contractors. Every line on this page comes from the model — open it and check any of them.
What the model holds.
The 3 heaviest areas of 3.
| Area | Screens | Actions | API | Records | What it covers |
|---|---|---|---|---|---|
| src | 142 | 0 | 0 | 2 | The React web app (faktorio-fe/src): invoice, contact, received-invoice and settings pages, in-browser PDF/QR/ISDOC and Czech tax XML generation, and… |
| src | 0 | 80 | 0 | 1 | The tRPC API Cloudflare Worker (faktorio-api/src): JWT auth, invoice/contact/received-invoice/API-token/push routers, email sending, CNB exchange… |
| Shared & root | 1 | 24 | 13 | 13 | Everything outside the two app sources: the Drizzle SQLite schema and migrations (faktorio-db), the Elysia public REST API worker with API-key auth… |
What a person walks through, step by step.
19 paths are described in the model; the longest 12 are here, with how many areas each one crosses.
Builds a Czech invoice from a client contact, the supplier profile and line items: suggests the next number, converts foreign currency at the CNB rate for the…
Renders invoices entirely in the browser: a Czech or English react-pdf document with the supplier logo and an SPD payment QR code, the ISDOC 6.0.2 XML e-invoice, and…
Exchanges credentials for a session JWT, then authenticates every tRPC call on the Worker by decoding that JWT from the Authorization header; a 401 anywhere logs the…
Lets a user's own software issue invoices and manage received invoices over the Elysia public API: every request carries X-API-KEY, which is looked up in user_api_tokens…
Maintains the address book of clients invoices are issued to: registry-assisted create and edit, CSV bulk import via upsert, and deletion that shows how many invoices…
Publishes an invoice on an unauthenticated /shared-invoice/:shareId page where the client can view, download the PDF or ISDOC and pay by QR, while the owner sees…
Captures the seller data printed on every invoice: company details prefilled from the Czech ARES or Slovak RPO registry, VAT-payer flag, logo and an ordered list of bank…
Creates a user account either with a PBKDF2-hashed password or passwordless through a verified Google ID token, then signs the new user straight in with a one-year JWT…
Changes an existing invoice in place: all line items are replaced, sums and the due date recomputed and the client billing snapshot refreshed from the contact.
Emails a one-hour, single-use reset link (answering success even for unknown emails to prevent enumeration) and lets the holder set a new password; the token is consumed…
Sends the invoice or a payment reminder from [email protected] with reply-to set to the supplier: the draft is prefilled in the client's language, every send creates…
Produces the three EPO XML filings for the Czech tax office from issued and received invoices of a period: the VAT control statement (KH1), the VAT return (DP3) and the…
What the product enforces on its own.
7 rules are described; each one watches a record and changes something else when it moves.
Each scheduled run turns every unpaid, uncancelled invoice due on or before tomorrow - overdue ones included, despite the 'today or tomorrow' comment - into one grouped…
Deleting an invoice - one at a time from the list or all invoices of a contact - removes its line items and its public share links through ON DELETE CASCADE foreign…
On invoice create and update the due date is not taken from the form: due_on is recomputed as issued_on plus due_in_days.
Whenever an invoice is created or updated its line items are summed server-side: subtotal, VAT base and amount per rate (21/15/12/10/0 %), grand total and…
When a web-push delivery to a stored subscription is rejected, that subscription is deleted so later runs stop targeting it.
The public API records a share event for every public view and for posted download events, and then refreshes the share's last_accessed_at. The tRPC sharedInvoiceEvent…
Deleting the users row cascades only to tables with a user_id foreign key: password reset tokens, API tokens, bank accounts, push subscriptions and share links (with…
The states records move through.
invoice · src
Invoice email delivery
Not sent → Sent → Reminder sent
3 states · 3 transitions
invoice_share · Shared & root
Invoice share link access
Active → Disabled → Expired
3 states · 2 transitions
password_reset_tokens · src
Password reset token
Pending → Used → Expired
3 states · 2 transitions
invoice · src
Invoice payment
Unpaid → Paid
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?
54% of this product's API surface is dark: built and paid for, but part of no described customer path and consumed by no screen.
7 OF 13 ENDPOINTS · READ FROM 19 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 invoice than on anything else.
84 INBOUND DEPENDENCIES · COMPUTED FROM THE REACH GRAPH, NOT ESTIMATED
Where did the engineering effort actually go?
The deepest engineering investment is “src” — 50% of the product's mass. “Shared & root” is compact and self-contained: the cheapest place to change.
144 VS 55 OBJECTS · CHANGE-COST RATING = SIZE × CROSS-DOMAIN COUPLING
Which customer experience breaks first?
The most fragile customer experience is “Public REST API integration”: it crosses 3 domains in 12 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 — faktorio-db — alone carries 13 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 →Warpdrive architecture →DroneOps Command architecture →Pronto architecture →