# DERP

> A self-hosted ERP, PLM, and QMS that one company runs for itself — accounting, inventory, manufacturing, quality, and a storefront in one Django application.

Canonical page: [DERP](<https://devanmetz.com/portfolio/derp/>)

Project date: May 2026

Updated: 2026-10-14

Category: Business software

Status: Private software

Tags: Python, Django, PostgreSQL, Manufacturing

- **My work:** Design and implementation of every module
- **Stack:** Django 5.2 · PostgreSQL · Stripe Checkout
- **Scope:** One company per deployment

## In short

I designed and implemented DERP so one company can manage its accounting, inventory, manufacturing, product changes, quality records, and storefront in one application. Each company runs its own installation and database; the screenshots here show sample records from a disposable demo.

![An operational analytics dashboard showing revenue, cost, and working-capital figures above a revenue-versus-expenses chart and an inventory allocation chart.](<https://devanmetz.com/_astro/derp-dashboard.Ca3hNfAe_Z239wPv.webp>)

The operational dashboard, shown with data from a seeded demo installation.

## 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 

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 

### 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 

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 

### 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 

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 

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 

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 

### 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 

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 

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

![A bills-of-materials list showing a product SKU, its assembly recipe, released revision, component count, and cost rollup.](<https://devanmetz.com/_astro/derp-boms.CgUKM1jx_tIMoP.webp>)

Bill-of-materials records carry a released revision, component list, and costing rollup for each manufactured product.

![An engineering change order list with the change summary, type, priority, owner, and draft status.](<https://devanmetz.com/_astro/derp-changes.BAJaS-T5_NEroV.webp>)

Engineering change orders gate product, BOM, quality, supplier, and obsolescence changes behind approvals.

![A controlled-documents list with a document number, title, type, owner, status, and review date.](<https://devanmetz.com/_astro/derp-qms.__iaEbTT_L66oi.webp>)

Document control supports versioned procedures with review dates and approval states.

![A journal-entry list linking documents such as payments, invoices, manufacturing completions, and bills to accounting entries.](<https://devanmetz.com/_astro/derp-journal.7NjRVxg-_1yOUlF.webp>)

Posted business documents flow into double-entry accounting instead of a separate bookkeeping step.

## Related reading

- [Dean Android Agent](<https://devanmetz.com/portfolio/dean-android-agent/index.md>)
- [DevBot](<https://devanmetz.com/portfolio/devbot/index.md>)
- [Solar Cellular Trail Camera](<https://devanmetz.com/portfolio/solar-trail-camera/index.md>)