Overview Link to section: Overview
I designed and implemented every module in DERP, an integrated ERP (enterprise resource planning, which connects day-to-day business records), PLM (product lifecycle management, which tracks product revisions and changes), and QMS (quality management system, which tracks procedures and quality work).
One organization runs it for itself. A single deployment holds one company’s data: accounting, inventory, sales, purchasing, manufacturing, product lifecycle management, quality management, a company website, and a storefront.
One company per installation Link to section: One company per installation
I started the application as a hosted multi-customer platform and restructured it into a self-hosted one. One database now represents one company with its own users, records, website, and Stripe configuration. There is no tenant routing (choosing a customer’s data from a shared installation) or per-customer schema (a separate database structure for each customer).
What it covers Link to section: What it covers
Business records and manufacturing Link to section: Business records and manufacturing
| Area | What it handles |
|---|---|
| Accounting | Double-entry ledger (each transaction has matching debit and credit entries), posted documents (finalized business records), payments, and trial balance (debit/credit totals), income statement (income and expenses), balance sheet (assets, liabilities, and equity), and general-ledger reports (account transaction details) |
| Inventory | Weighted-average costing (average unit cost weighted by quantities), warehouses, lots (batches), serials (individual item identifiers), a stock ledger (inventory movement record), and transfers between locations |
| Sales and purchasing | Customers, sales orders, invoices, vendors, purchase orders, bills, and their posted workflows |
| Manufacturing | Bills of materials, or BOMs (component lists for an assembly), with cost rollups (combined component costs) and manufacturing orders that consume components into finished stock |
| PLM | Product revisions, engineering BOMs, and approval-gated engineering change orders, or ECOs (requests to approve product changes), with effectivity (when a change applies) |
| QMS | Document control, exact-revision training evidence, inspections, non-conformances (recorded failures to meet requirements), CAPA (corrective and preventive action) with effectiveness verification, and scored risk controls |
| Website and storefront | A built-in website editor and public shop served by the same installation |
| Copilot and Agent Hub | AI assistance with a preview-and-confirm step before any database write |
Quality records Link to section: Quality records
My QMS document workflows follow ISO 9001 / ISO 13485 conventions (quality-management standards), including review dates, approval states, and training records tied to a specific document revision.
Architecture Link to section: Architecture
Application and navigation Link to section: Application and navigation
I built DERP with Django 5.2 LTS (a Python web framework with long-term support) and PostgreSQL (a relational database). The public website lives at the site root and the ERP interface lives under /derp/. An administrator creates accounts rather than using public signup.
The interface targets the same records from several angles:
- A workspace overview.
- An operational analytics dashboard.
- Per-module lists and detail pages.
Hosting and optional payments Link to section: Hosting and optional payments
Deployment follows standard Django practice: migrations (database structure updates), static collection (gathering website assets), and a Gunicorn process (the application’s web server). It can run on Railway or any host with PostgreSQL.
Stripe is optional. Without keys, checkout completes manually for development. With keys, the storefront creates Stripe Checkout Sessions (hosted payment sessions) directly in the hosting company’s Stripe account and fulfills paid orders into sales and accounting records.
Storefront and payments Link to section: Storefront and payments
I keep the storefront in the same application rather than a separate service. Paid checkouts are verified by Stripe webhook signature (proof that the payment notification came from Stripe), then written back as sales and accounting entries. That keeps the online shop inside the same ledger as the rest of the company’s business.
Copilot and Agent Hub Link to section: Copilot and Agent Hub
My Copilot keeps its API key (the credential for accessing the AI service) in the user’s browser. It requires a signed preview and explicit confirmation before it writes to the database.
Agent Hub stores reusable, user-owned prompts that a person opens and sends through the Copilot. It does not run unattended jobs.
Development workflow Link to section: Development workflow
Dependencies Link to section: Dependencies
I pin direct and transitive dependencies (packages I use and the packages they depend on) with hashes (file fingerprints). I regenerate them through a lock step with uv, the Python package-management tool.
Testing Link to section: Testing
The test suite runs against PostgreSQL through a dedicated test settings module. GitHub Actions (automated repository checks) runs migrations, static collection, and the full suite on PostgreSQL 18 with Python 3.11 and 3.13.
A separate SQLite (a file-based database) test setting exists for quick local runs.
Current state and demo imagery Link to section: Current state and demo imagery
DERP is private software. The repository is not public, and there is no public demo installation.
The screenshots on this page come from a disposable demo deployment seeded with sample records, not from a live company database. The figures, orders, and documents shown are demo data.
Build photos
